Applying Parameters to Discovered Brokers

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Applying Parameters to Discovered Brokers

nondescript1
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.
Reply | Threaded
Open this post in threaded view
|

Re: Applying Parameters to Discovered Brokers

gtully
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Applying Parameters to Discovered Brokers

nondescript1
A call hierarchy on the DiscoveryTransport constructor reveals that it is instantiated in FanoutTransportFactory and DiscoveryTransportFactory, which extends FailoverTransportFactory.  In DiscoveryTransportFactory, the parameters are applied to the DiscoveryTransport.  Wouldn't it be better to have both fanout and failover factories call DiscoveryTransportFactory to ensure the discovery transport is created correctly?  In that case, DiscoveryTransportFactory would no longer extend FailoverTransportFactory.  

Unfortunately, this would probably break using the discovery transport directly, right?  So, it's probably better to simply add transport.setParameters(parameters) and IntrospectionSupport.setProperties(transport, parameters) to FanoutTransportFactory.

I'll look to open a jira issue and will create a test case.  Thanks.

Gary Tully wrote
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.

--
http://blog.garytully.com

Open Source Integration
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: Applying Parameters to Discovered Brokers

nondescript1
Filed AMQ-2849 for this issue.