Why try to capture "Exception" instead of "java.net.ConnectException"? I
saw a similar problem when working on JMS on RabbitMQ. I coded the error
handler there to trap "ConnectException" and log/print that "Is RabbitMQ
running?" so the person running it could go "Doh! I forgot to start
Rabbit." Then, when other error conditions pop-up, they aren't getting
improperly masked/handled by the wide sweeping "Exception".


On Tue, Jul 9, 2013 at 10:24 AM, Gary Russell <notifications@github.com>wrote:

> In
> spring-xd-dirt/src/main/java/org/springframework/xd/dirt/launcher/AbstractContainerLauncher.java:
>
> > +	public void setApplicationEventPublisher(ApplicationEventPublisher eventPublisher) {
> > +		this.eventPublisher = eventPublisher;
> > +	}
> > +
> > +	@Override
> > +	public Container launch(ContainerOptions options) {
> > +		try {
> > +			String id = this.generateId();
> > +			DefaultContainer container = new DefaultContainer(id);
> > +			container.start();
> > +			this.logContainerInfo(logger, container, options);
> > +			container.addListener(new ShutdownListener(container));
> > +			this.eventPublisher.publishEvent(new ContainerStartedEvent(container));
> > +			return container;
> > +		}
> > +		catch (BeanCreationException e) {
>
> If Rabbit's not running, we don't get a BCE, we get
>
> org.springframework.amqp.AmqpConnectException: java.net.ConnectException:
> Connection refused
>
> so this catch block is never executed.
>
> The container continues to run (and in fact seems to work OK, once Rabbit
> is restarted). However, we don't get the logContainerInfo nor is the
> shutdown listener registered, nor do we get the ContainerStartedEvent.
>
> The Container object returned by this method (null in the case of a
> non-running Rabbit) is discarded anyway (in Container.main(), launch() is
> invoked without assigning its result to a variable).
>
> So, we can "fix" it by catching Exception so the container fails to start
> but it seems like we're not that far away from being able to recover from a
> down broker. Seems like we could go ahead and let the other be executed
> even if the broker is down.
>
> Or, maybe for now, we can let the container fail to initialize and, as
> discussed before, add a RetryTemplate to the Container.main().
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/SpringSource/spring-xd/pull/95/files#r5092589>
> .
>



-- 
Greg Turnquist | Senior Software Engineer | Pivotal
Mobile: +1 321-759-1143 | Skype: gregturn | gturnquist@gopivotal.com

goPivotal.com <http://www.gopivotal.com/>