I think that is the correct approach. Compare FanoutTransportFactory.createTransport to some of the other transport factories, FailoverTransportFactory for example, it follows that pattern. Possibly open a jira issue and attach your patch and a test case to protect it.
On 22 July 2010 17:51, nondescript1 <jmsig...@gmail.com> wrote: > > Greetings. This is my first post, so let me say thank you up front for a > great tool in ActiveMQ and for any help you provide. > > Is there a correct way to apply transport parameters to discovered brokers? > > I'm trying to send a message using the fanout transport and the following > URI, > fanout:(multicast://default?maxReconnectAttempts=1)?minAckCount=1 > As you can see, I'm using multicast broker discovery. However, in certain > circumstances, I encounter connection timeout issues when sending the > message after the brokers are discovered. In these cases, the default > connectionTimeout of 30 seconds causes a considerable delay in my > application, and I would rather have a 3 second delay. Therefore, I would > like to apply the parameter connectionTimeout=3000 to any discovered > brokers. > > A colleague was able to accomplish this by modifying > FanoutTransportFactory.createTransport(URI) to call > transport.setParameters(parameters) on the DiscoveryTransport that the > FanoutTransport is wrapped in. Since DiscoveryTransport parameters are > applied to discovered services in > DiscoveryTransport.onServiceAdd(DiscoveryEvent), the following URI now has > the desired result of timing out after three seconds of not being able to > send a message to a discovered broker, > > fanout:(multicast://default?maxReconnectAttempts=1)?minAckCount=1&connectionTimeout=3000 > > However, this solution feels like a hack. Do you agree that this is not a > correct approach, and is there a best practice for doing this? > > Thank you again for your time and help. > -- > View this message in context: > http://old.nabble.com/Applying-Parameters-to-Discovered-Brokers-tp29239157p29239157.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > > -- http://blog.garytully.com Open Source Integration http://fusesource.com