You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "John McCarthy (JIRA)" <ji...@apache.org> on 2010/07/24 00:34:51 UTC
[jira] Created: (AMQ-2849) Fanout: unable to apply parameters to
discovered brokers
Fanout: unable to apply parameters to discovered brokers
--------------------------------------------------------
Key: AMQ-2849
URL: https://issues.apache.org/activemq/browse/AMQ-2849
Project: ActiveMQ
Issue Type: Improvement
Components: Transport
Affects Versions: 5.3.2
Reporter: John McCarthy
There is currently no way to apply parameters to discovered brokers when using the fanout transport. The discovery transport allows this by calling {{DiscoveryTransport.setParameters(Map)}} in {{DiscoveryTransportFactory.createTransport(CompositeData)}}. For example, the following URI would apply a connection timeout of 3 seconds to all discovered TCP transport brokers,
{{discovery:(multicast://default)?connectionTimeout=3000}}
The corresponding fanout URI would not apply the connection timeout to discovered TCP brokers,
{{fanout:(multicast://default)?connectionTimeout=3000}}
This functionality is requested as discovered brokers may become unreachable. In those circumstances, the default 30 connection timeout for the TCP transport can cause a considerable delay.
The attached patch is a proposed solution where both transports that use the discovery transport, failover and fanout, have a common code path in {{DiscoveryTransportFactory}} for creating a discovery transport. This code path sets the parameters consistently for both transports. (Although it relies on a new static method in {{DiscoveryTansportFactory}} and {{TransportFactory}} objects do not have static methods, {{FanoutTransportFactory}} was already making a static call to {{DiscoveryAgentFactory}}). The patch also has two new test cases, one for apply parameters and another for a minor fix where {{DiscoveryTransport}} should cache the added URI after the parameters are applied so that the same URI is removed in {{onServiceRemove()}}.
This issue is created after discussion on the ActiveMQ Users discussion board,
[http://old.nabble.com/Applying-Parameters-to-Discovered-Brokers-td29239157.html]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-2849) Fanout: unable to apply parameters to
discovered brokers
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully resolved AMQ-2849.
-----------------------------
Assignee: Gary Tully
Fix Version/s: 5.4.0
Resolution: Fixed
patch applied with thanks, r979277
> Fanout: unable to apply parameters to discovered brokers
> --------------------------------------------------------
>
> Key: AMQ-2849
> URL: https://issues.apache.org/activemq/browse/AMQ-2849
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Transport
> Affects Versions: 5.3.2
> Reporter: John McCarthy
> Assignee: Gary Tully
> Priority: Minor
> Fix For: 5.4.0
>
> Attachments: FanoutTransportFactory_apply_DiscoveryTransport_params.patch
>
>
> There is currently no way to apply parameters to discovered brokers when using the fanout transport. The discovery transport allows this by calling {{DiscoveryTransport.setParameters(Map)}} in {{DiscoveryTransportFactory.createTransport(CompositeData)}}. For example, the following URI would apply a connection timeout of 3 seconds to all discovered TCP transport brokers,
> {{discovery:(multicast://default)?connectionTimeout=3000}}
> The corresponding fanout URI would not apply the connection timeout to discovered TCP brokers,
> {{fanout:(multicast://default)?connectionTimeout=3000}}
> This functionality is requested as discovered brokers may become unreachable. In those circumstances, the default 30 connection timeout for the TCP transport can cause a considerable delay.
> The attached patch is a proposed solution where both transports that use the discovery transport, failover and fanout, have a common code path in {{DiscoveryTransportFactory}} for creating a discovery transport. This code path sets the parameters consistently for both transports. (Although it relies on a new static method in {{DiscoveryTansportFactory}} and {{TransportFactory}} objects do not have static methods, {{FanoutTransportFactory}} was already making a static call to {{DiscoveryAgentFactory}}). The patch also has two new test cases, one for apply parameters and another for a minor fix where {{DiscoveryTransport}} should cache the added URI after the parameters are applied so that the same URI is removed in {{onServiceRemove()}}.
> This issue is created after discussion on the ActiveMQ Users discussion board,
> [http://old.nabble.com/Applying-Parameters-to-Discovered-Brokers-td29239157.html]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2849) Fanout: unable to apply parameters to
discovered brokers
Posted by "John McCarthy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John McCarthy updated AMQ-2849:
-------------------------------
Priority: Minor (was: Major)
> Fanout: unable to apply parameters to discovered brokers
> --------------------------------------------------------
>
> Key: AMQ-2849
> URL: https://issues.apache.org/activemq/browse/AMQ-2849
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Transport
> Affects Versions: 5.3.2
> Reporter: John McCarthy
> Priority: Minor
> Attachments: FanoutTransportFactory_apply_DiscoveryTransport_params.patch
>
>
> There is currently no way to apply parameters to discovered brokers when using the fanout transport. The discovery transport allows this by calling {{DiscoveryTransport.setParameters(Map)}} in {{DiscoveryTransportFactory.createTransport(CompositeData)}}. For example, the following URI would apply a connection timeout of 3 seconds to all discovered TCP transport brokers,
> {{discovery:(multicast://default)?connectionTimeout=3000}}
> The corresponding fanout URI would not apply the connection timeout to discovered TCP brokers,
> {{fanout:(multicast://default)?connectionTimeout=3000}}
> This functionality is requested as discovered brokers may become unreachable. In those circumstances, the default 30 connection timeout for the TCP transport can cause a considerable delay.
> The attached patch is a proposed solution where both transports that use the discovery transport, failover and fanout, have a common code path in {{DiscoveryTransportFactory}} for creating a discovery transport. This code path sets the parameters consistently for both transports. (Although it relies on a new static method in {{DiscoveryTansportFactory}} and {{TransportFactory}} objects do not have static methods, {{FanoutTransportFactory}} was already making a static call to {{DiscoveryAgentFactory}}). The patch also has two new test cases, one for apply parameters and another for a minor fix where {{DiscoveryTransport}} should cache the added URI after the parameters are applied so that the same URI is removed in {{onServiceRemove()}}.
> This issue is created after discussion on the ActiveMQ Users discussion board,
> [http://old.nabble.com/Applying-Parameters-to-Discovered-Brokers-td29239157.html]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2849) Fanout: unable to apply parameters to
discovered brokers
Posted by "John McCarthy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John McCarthy updated AMQ-2849:
-------------------------------
Attachment: FanoutTransportFactory_apply_DiscoveryTransport_params.patch
Proposed solution
> Fanout: unable to apply parameters to discovered brokers
> --------------------------------------------------------
>
> Key: AMQ-2849
> URL: https://issues.apache.org/activemq/browse/AMQ-2849
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Transport
> Affects Versions: 5.3.2
> Reporter: John McCarthy
> Attachments: FanoutTransportFactory_apply_DiscoveryTransport_params.patch
>
>
> There is currently no way to apply parameters to discovered brokers when using the fanout transport. The discovery transport allows this by calling {{DiscoveryTransport.setParameters(Map)}} in {{DiscoveryTransportFactory.createTransport(CompositeData)}}. For example, the following URI would apply a connection timeout of 3 seconds to all discovered TCP transport brokers,
> {{discovery:(multicast://default)?connectionTimeout=3000}}
> The corresponding fanout URI would not apply the connection timeout to discovered TCP brokers,
> {{fanout:(multicast://default)?connectionTimeout=3000}}
> This functionality is requested as discovered brokers may become unreachable. In those circumstances, the default 30 connection timeout for the TCP transport can cause a considerable delay.
> The attached patch is a proposed solution where both transports that use the discovery transport, failover and fanout, have a common code path in {{DiscoveryTransportFactory}} for creating a discovery transport. This code path sets the parameters consistently for both transports. (Although it relies on a new static method in {{DiscoveryTansportFactory}} and {{TransportFactory}} objects do not have static methods, {{FanoutTransportFactory}} was already making a static call to {{DiscoveryAgentFactory}}). The patch also has two new test cases, one for apply parameters and another for a minor fix where {{DiscoveryTransport}} should cache the added URI after the parameters are applied so that the same URI is removed in {{onServiceRemove()}}.
> This issue is created after discussion on the ActiveMQ Users discussion board,
> [http://old.nabble.com/Applying-Parameters-to-Discovered-Brokers-td29239157.html]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.