activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "R Pankajakshan (JIRA)" <j...@apache.org>
Subject [jira] Created: (AMQ-2981) Connecting to broker using discovery protocol fails
Date Fri, 15 Oct 2010 12:56:40 GMT
Connecting to broker using discovery protocol fails
---------------------------------------------------

                 Key: AMQ-2981
                 URL: https://issues.apache.org/activemq/browse/AMQ-2981
             Project: ActiveMQ
          Issue Type: Bug
          Components: Broker
    Affects Versions: 5.4.1, 5.4.0
         Environment: embedded activemq in tomcat
spring jms for connection pooling and connections
            Reporter: R Pankajakshan


steps to reproduce

1. have a broker running on a port say '12345' and group say 'test' using activemq-core version
5.4.0 or 5.4.1
2.  use url 
discovery:(multicast://default?group=test)?reconnectDelay=1000&maxReconnectAttempts=30&useExponentialBackOff=false

to connect to the broker
3. the following exception occurs



Caused by: javax.jms.JMSException: Invalid connect parameters: {reconnectDelay=1000, maxReconnectAttempts=30,
useExponentialBackOff=false}
	at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:62)
	at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1298)
	at org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1382)
	at org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:309)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at org.springframework.jms.connection.SingleConnectionFactory$SharedConnectionInvocationHandler.invoke(SingleConnectionFactory.java:550)
	at $Proxy34.createSession(Unknown Source)
	at org.springframework.jms.support.JmsAccessor.createSession(JmsAccessor.java:196)
	at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:457)
	... 38 more
Caused by: java.io.IOException: Invalid connect parameters: {reconnectDelay=1000, maxReconnectAttempts=30,
useExponentialBackOff=false}
	at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:45)
	at org.apache.activemq.transport.failover.FailoverTransport.oneway(FailoverTransport.java:594)
	at org.apache.activemq.transport.TransportFilter.oneway(TransportFilter.java:85)
	at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
	at org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:81)
	at org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:86)
	at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1276)
	... 48 more
Caused by: java.lang.IllegalArgumentException: Invalid connect parameters: {reconnectDelay=1000,
maxReconnectAttempts=30, useExponentialBackOff=false}
	at org.apache.activemq.transport.TransportFactory.doCompositeConnect(TransportFactory.java:159)
	at org.apache.activemq.transport.TransportFactory.compositeConnect(TransportFactory.java:93)
	at org.apache.activemq.transport.failover.FailoverTransport.doReconnect(FailoverTransport.java:844)
	at org.apache.activemq.transport.failover.FailoverTransport$2.iterate(FailoverTransport.java:135)
	at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
	at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)


4. downgrading to amq 5.3.2 solves the problem

NOTE: a new functionality has been added to 5.4.0 

ref : http://activemq.apache.org/discovery-transport-reference.html

Applying parameters to discovered transports
>From 5.4, transport parameters in the URI will also be applied to discovered transports.
Therefore, transport parameters may also include parameters for the discovered transport.
For example, adding the connectionTimeout parameter to the URI will apply the parameter to
every discovered TCP transport, even though this parameter is not a Discovery transport option.


I think the above change has caused the problem








-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message