You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by nondescript1 <jm...@gmail.com> on 2010/07/22 18:51:01 UTC

Applying Parameters to Discovered Brokers

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.


Re: Applying Parameters to Discovered Brokers

Posted by nondescript1 <jm...@gmail.com>.
Filed  https://issues.apache.org/activemq/browse/AMQ-2849 AMQ-2849  for this
issue.
    
-- 
View this message in context: http://old.nabble.com/Applying-Parameters-to-Discovered-Brokers-tp29239157p29249888.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: Applying Parameters to Discovered Brokers

Posted by nondescript1 <jm...@gmail.com>.
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
> 
> 

-- 
View this message in context: http://old.nabble.com/Applying-Parameters-to-Discovered-Brokers-tp29239157p29248723.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: Applying Parameters to Discovered Brokers

Posted by Gary Tully <ga...@gmail.com>.
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 <jm...@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