[jira] [Commented] (ARTEMIS-151) TransportConfiguration does not check the name in equals
[ https://issues.apache.org/jira/browse/ARTEMIS-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715353#comment-14715353 ] clebert suconic commented on ARTEMIS-151: - that configuration object is just a representation of the file. I don't think this should be fixed. TransportConfiguration does not check the name in equals Key: ARTEMIS-151 URL: https://issues.apache.org/jira/browse/ARTEMIS-151 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Jeff Mesnil Configuration#setAcceptorConfigurations takes a Set of TransportConfiguration. These objects does not check their name in their equals() method and it is not possible to have 2 acceptors with the same set of parameters but different names (we need that case in our app server to represent HTTP / HTTPS acceptors that are handled differently by our web stack). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-202) IP address to hostname resolving
[ https://issues.apache.org/jira/browse/ARTEMIS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715359#comment-14715359 ] clebert suconic commented on ARTEMIS-202: - well.. I will actually close this.. if you provide more information just reopen it. IP address to hostname resolving Key: ARTEMIS-202 URL: https://issues.apache.org/jira/browse/ARTEMIS-202 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 1.0.0 Reporter: Martin Styk IP addresses are automatically resolved to hostnames. Server is bind to the IP address which have record in file /etc/hosts. Client is able to do lookup for connection factory, but can not establish connection because field host in connector doesn`t contain IP address but is resolved to hostname according to /etc/hosts. Artemis shouldn`t try to resolve IP address automatically, since it`s unexpected behavior. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-202) IP address to hostname resolving
[ https://issues.apache.org/jira/browse/ARTEMIS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715357#comment-14715357 ] clebert suconic commented on ARTEMIS-202: - what we are supposed to do here? We don't resolve the IP... NIO does..we just connect to whatever information you provide on the socket.. I have no idea on what you're asking here I'm considering rejecting this unless you provide more information. IP address to hostname resolving Key: ARTEMIS-202 URL: https://issues.apache.org/jira/browse/ARTEMIS-202 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 1.0.0 Reporter: Martin Styk IP addresses are automatically resolved to hostnames. Server is bind to the IP address which have record in file /etc/hosts. Client is able to do lookup for connection factory, but can not establish connection because field host in connector doesn`t contain IP address but is resolved to hostname according to /etc/hosts. Artemis shouldn`t try to resolve IP address automatically, since it`s unexpected behavior. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ARTEMIS-202) IP address to hostname resolving
[ https://issues.apache.org/jira/browse/ARTEMIS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-202. --- Resolution: Invalid IP address to hostname resolving Key: ARTEMIS-202 URL: https://issues.apache.org/jira/browse/ARTEMIS-202 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 1.0.0 Reporter: Martin Styk IP addresses are automatically resolved to hostnames. Server is bind to the IP address which have record in file /etc/hosts. Client is able to do lookup for connection factory, but can not establish connection because field host in connector doesn`t contain IP address but is resolved to hostname according to /etc/hosts. Artemis shouldn`t try to resolve IP address automatically, since it`s unexpected behavior. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5948) connection.start hangs with tcp transport wrong username / password
[ https://issues.apache.org/jira/browse/AMQ-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Castaldo D'Ursi updated AMQ-5948: - Description: Hi, I am trying to connect to an ActiveMq Broker version 5.11.1 , using the ActiveMQConnectionFactory. On the client side I tried both client version 5.11.2 and 5.12.0 On server side, authentication is enabled. If I supply wrong username and password, the call to connection.start() hangs . Debugging the code, I see it hangs in org.apache.activemq.transport.FutureResponse.getResult(). (this is indirectly called by syncSendPacket in the ensureConnectionInfoSent method in ActiveMQConnection) On server side, i see the error message: INFO | Stopping tcp://127.0.0.1:53846 because Failed with SecurityException: User name [null] or password is invalid. It looks like client side is waiting indefinitely for an answer that will never arrive was: Hi, I am trying to connect to an ActiveMq Broker version 5.11.1 , using the ActiveMQConnectionFactory. On the client side I tried both client version 5.11.2 and 5.12.0 On server side, authentication is enabled. If I supply wrong username and password, the call to connection.start() hangs . Debugging the code, I see it hangs in org.apache.activemq.transport.FutureResponse.getResult(). (this is indirectly called by syncSendPacket in the ensureConnectionInfoSent method in ActiveMQConnectionFactory) On server side, i see the error message: INFO | Stopping tcp://127.0.0.1:53846 because Failed with SecurityException: User name [null] or password is invalid. It looks like client side is waiting indefinitely for an answer that will never arrive connection.start hangs with tcp transport wrong username / password --- Key: AMQ-5948 URL: https://issues.apache.org/jira/browse/AMQ-5948 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.12.0 Reporter: Antonio Castaldo D'Ursi Hi, I am trying to connect to an ActiveMq Broker version 5.11.1 , using the ActiveMQConnectionFactory. On the client side I tried both client version 5.11.2 and 5.12.0 On server side, authentication is enabled. If I supply wrong username and password, the call to connection.start() hangs . Debugging the code, I see it hangs in org.apache.activemq.transport.FutureResponse.getResult(). (this is indirectly called by syncSendPacket in the ensureConnectionInfoSent method in ActiveMQConnection) On server side, i see the error message: INFO | Stopping tcp://127.0.0.1:53846 because Failed with SecurityException: User name [null] or password is invalid. It looks like client side is waiting indefinitely for an answer that will never arrive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-212) Unable to parse IPv6 address
[
https://issues.apache.org/jira/browse/ARTEMIS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-212:
--
Assignee: Justin Bertram
Unable to parse IPv6 address
Key: ARTEMIS-212
URL: https://issues.apache.org/jira/browse/ARTEMIS-212
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff Mesnil
Assignee: Justin Bertram
In our test suite, we have tests failing when using IPv6:
{noformat}
Caused by: java.io.InvalidObjectException: URLDecoder: Illegal hex characters
in escape (%) pattern - For input string: et
at
org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.readExternal(ActiveMQConnectionFactory.java:117)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1308)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:59)
at
org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:232)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This issue can be reproduced by using URLDecoder to decode an URL with IPv6
address such as http://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5948) connection.start hangs with tcp transport wrong username / password
[ https://issues.apache.org/jira/browse/AMQ-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14714477#comment-14714477 ] Antonio Castaldo D'Ursi commented on AMQ-5948: -- You're right. I created a unit test with an embedded broker and it worked. What's strange is that now also the original code is working. And the unit test is working also connecting to the real broker. Maybe it was a runtime problem on the server side? I'll let you know if it happens again connection.start hangs with tcp transport wrong username / password --- Key: AMQ-5948 URL: https://issues.apache.org/jira/browse/AMQ-5948 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.12.0 Reporter: Antonio Castaldo D'Ursi Hi, I am trying to connect to an ActiveMq Broker version 5.11.1 , using the ActiveMQConnectionFactory. On the client side I tried both client version 5.11.2 and 5.12.0 On server side, authentication is enabled. If I supply wrong username and password, the call to connection.start() hangs . Debugging the code, I see it hangs in org.apache.activemq.transport.FutureResponse.getResult(). (this is indirectly called by syncSendPacket in the ensureConnectionInfoSent method in ActiveMQConnection) On server side, i see the error message: INFO | Stopping tcp://127.0.0.1:53846 because Failed with SecurityException: User name [null] or password is invalid. It looks like client side is waiting indefinitely for an answer that will never arrive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-4264) ActiveMQ dying with exception detected missing/corrupt journal files
[ https://issues.apache.org/jira/browse/AMQ-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715254#comment-14715254 ] Arthur Naseef commented on AMQ-4264: Hey Tim - can you provide a link to a public version of that KahaDB-Recovery.html Fuse documentation? I get a generic RedHat product documentation page with that link. ActiveMQ dying with exception detected missing/corrupt journal files Key: AMQ-4264 URL: https://issues.apache.org/jira/browse/AMQ-4264 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.6.0 Environment: linux Reporter: Bhanu Hi, Yesterday, our ActiveMQ broker suddenly died with the exception pasted below. It failed to come up on repeated attempts and we could only bring it back after clearing the kahadb data and redo files. We havent seen this issue in the past. Can you suggest some pointers here on why this would have happened suddenly? Is this a known issue which is going to be fixed in future versions ? ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in URL [file:/prod/tools/base/etc/config/activemq/amq_prod_broker_config.xml]: Invocation of init method failed; nested exception is java.io.IOException: Detected missing/corrupt journal files. 124512 messages affected. java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in URL [file:/prod/tools/base/etc/config/activemq/amq_prod_broker_config.xml]: Invocation of init method failed; nested exception is java.io.IOException: Detected missing/corrupt journal files. 124512 messages affected. at org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:98) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57) at org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:148) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57) at org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:90) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.activemq.console.Main.runTaskClass(Main.java:257) at org.apache.activemq.console.Main.main(Main.java:111) Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in URL [file:/prod/tools/base/etc/config/activemq/amq_prod_broker_config.xml]: Invocation of init method failed; nested exception is java.io.IOException: Detected missing/corrupt journal files. 124512 messages affected. at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1420) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.init(ResourceXmlApplicationContext.java:64) at
[jira] [Created] (AMQ-5949) org.apache.activemq.network.jms.OutboundQueueBridge does not provide guaranteed message forwarding
Ben Nisbet created AMQ-5949: --- Summary: org.apache.activemq.network.jms.OutboundQueueBridge does not provide guaranteed message forwarding Key: AMQ-5949 URL: https://issues.apache.org/jira/browse/AMQ-5949 Project: ActiveMQ Issue Type: Improvement Components: Connector Affects Versions: 5.10.2 Environment: WebLogic 10.3.6, JRockit JDK 1.6 Reporter: Ben Nisbet Fix For: 5.10.3 When using an OutboundQueueBridge associated with a SimpleJmsQueueConnector bean I have observed the default ReconnectionPolicy.maxSendRetries value of 10 to result in message loss if the connection to destination server is unreliable. (messages that are not delivered to destination within maxSendRetries are still acknowledged as having been consumed by processing of later messages) Is it possible for the DestinationBridge onMessage() implementation to interpret a ReconnectionPolicy.maxSendRetries property value of -1 as infinity? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (AMQ-5946) Tomcat 7.0.62 complains of memory leak when web app is stopped or reloaded
[ https://issues.apache.org/jira/browse/AMQ-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-5946. - Resolution: Not A Problem The connection executor would be stopped if the connection close method were called. Tomcat 7.0.62 complains of memory leak when web app is stopped or reloaded -- Key: AMQ-5946 URL: https://issues.apache.org/jira/browse/AMQ-5946 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.10.2 Environment: Tomcat 7.0.62 , ActiveMQ 5.10.2 , Spring 4.1.2 Reporter: Nandini R We are using failover protocol to connect to broker. Url is as : failover:(tcp://localhost:61616)?startupMaxReconnectAttempts=2initialReconnectDelay=6maxReconnectAttempts=2 Suppose I start web application with AMQ not running and then stop web application , I get below logs in tomcat SEVERE: The web application [] appears to have started a thread name d [ActiveMQ Connection Executor: unconnected] but has failed to stop it. This is very likely to create a memory leak. Aug 25, 2015 11:27:59 AM org.apache.catalina.loader.WebappClassLoader clearRefer encesThreads SEVERE: The web application [] appears to have started a thread name d [ActiveMQ Task-1] but has failed to stop it. This is very likely to create a m emory leak. I can see these 2 threads in thread dump. How do I close these on stopping web application ? On webapp shutdown I am shutting down message containers and closing spring context. I am not facing any issues if active MQ is running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-213) Fix WireFormatNegotiationTest
[ https://issues.apache.org/jira/browse/ARTEMIS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-213: Summary: Fix WireFormatNegotiationTest (was: Fix WireFormatNegoTest) Fix WireFormatNegotiationTest - Key: ARTEMIS-213 URL: https://issues.apache.org/jira/browse/ARTEMIS-213 Project: ActiveMQ Artemis Issue Type: Sub-task Components: OpenWire Affects Versions: 1.0.0 Reporter: Howard Gao Assignee: Howard Gao Fix For: 1.1.0 Client can negotiate a working wireformat version with broker. If a client requests a earlier version of wireformat the broker should respect it. e.g. if a client request: tcp://localhost:61616?wireFormat.version=1 The server should confirm that the version to be used is 1. Test: WireformatNegociationTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5878) Upgrade Jackson 2.6.0
[ https://issues.apache.org/jira/browse/AMQ-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715549#comment-14715549 ] ASF subversion and git services commented on AMQ-5878: -- Commit 950dc926776b6f4a2006647ecbf1a15f18dd7564 in activemq's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=950dc92 ] AMQ-5878 Update Jackson deps. Upgrade Jackson 2.6.0 - Key: AMQ-5878 URL: https://issues.apache.org/jira/browse/AMQ-5878 Project: ActiveMQ Issue Type: Improvement Reporter: Andrea Cosentino Priority: Minor I think it can be useful to upgrade Jackson to the latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ARTEMIS-212) Unable to parse IPv6 address
[
https://issues.apache.org/jira/browse/ARTEMIS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715571#comment-14715571
]
Justin Bertram edited comment on ARTEMIS-212 at 8/26/15 9:40 PM:
-
Maybe I'm thick, but I can't reproduce this. Here's the quick unit test I
wrote:
{code}
ConnectionFactoryParser parser = new ConnectionFactoryParser();
ActiveMQConnectionFactory factory = parser.newObject(new
URI(tcp://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah), null);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream outStream = new ObjectOutputStream(baos);
outStream.writeObject(factory);
outStream.close();
baos.close();
ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
ObjectInputStream in = new ObjectInputStream(bais);
factory = (ActiveMQConnectionFactory) in.readObject();
in.close();
bais.close();
{code}
If I try to use http://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah; as
the URI string then I get {{java.lang.NullPointerException: Schema http not
found}}.
Any thoughts on how I can reproduce this in a unit test?
was (Author: jbertram):
Maybe I'm thick, but I can't reproduce this. Here's the quick unit test I
wrote:
{code}
ActiveMQConnectionFactory factory = parser.newObject(new
URI(tcp://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah), null);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream outStream = new ObjectOutputStream(baos);
outStream.writeObject(factory);
outStream.close();
baos.close();
ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
ObjectInputStream in = new ObjectInputStream(bais);
factory = (ActiveMQConnectionFactory) in.readObject();
in.close();
bais.close();
{code}
If I try to use http://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah; as
the URI string then I get {{java.lang.NullPointerException: Schema http not
found}}.
Any thoughts on how I can reproduce this in a unit test?
Unable to parse IPv6 address
Key: ARTEMIS-212
URL: https://issues.apache.org/jira/browse/ARTEMIS-212
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff Mesnil
Assignee: Justin Bertram
In our test suite, we have tests failing when using IPv6:
{noformat}
Caused by: java.io.InvalidObjectException: URLDecoder: Illegal hex characters
in escape (%) pattern - For input string: et
at
org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.readExternal(ActiveMQConnectionFactory.java:117)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1308)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:59)
at
org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:232)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This issue can be reproduced by using URLDecoder to decode an URL with IPv6
address such as http://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-212) Unable to parse IPv6 address
[
https://issues.apache.org/jira/browse/ARTEMIS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715571#comment-14715571
]
Justin Bertram commented on ARTEMIS-212:
Maybe I'm thick, but I can't reproduce this. Here's the quick unit test I
wrote:
{code}
ActiveMQConnectionFactory factory = parser.newObject(new
URI(tcp://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah), null);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream outStream = new ObjectOutputStream(baos);
outStream.writeObject(factory);
outStream.close();
baos.close();
ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
ObjectInputStream in = new ObjectInputStream(bais);
factory = (ActiveMQConnectionFactory) in.readObject();
in.close();
bais.close();
{code}
If I try to use http://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah; as
the URI string then I get {{java.lang.NullPointerException: Schema http not
found}}.
Any thoughts on how I can reproduce this in a unit test?
Unable to parse IPv6 address
Key: ARTEMIS-212
URL: https://issues.apache.org/jira/browse/ARTEMIS-212
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff Mesnil
Assignee: Justin Bertram
In our test suite, we have tests failing when using IPv6:
{noformat}
Caused by: java.io.InvalidObjectException: URLDecoder: Illegal hex characters
in escape (%) pattern - For input string: et
at
org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.readExternal(ActiveMQConnectionFactory.java:117)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1308)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:59)
at
org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:232)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This issue can be reproduced by using URLDecoder to decode an URL with IPv6
address such as http://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMQ-5878) Upgrade Jackson 2.6.0
[ https://issues.apache.org/jira/browse/AMQ-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-5878. --- Resolution: Fixed Fix Version/s: 5.13.0 Fixed on master. Upgrade Jackson 2.6.0 - Key: AMQ-5878 URL: https://issues.apache.org/jira/browse/AMQ-5878 Project: ActiveMQ Issue Type: Improvement Reporter: Andrea Cosentino Priority: Minor Fix For: 5.13.0 I think it can be useful to upgrade Jackson to the latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-212) Unable to parse IPv6 address
[
https://issues.apache.org/jira/browse/ARTEMIS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715689#comment-14715689
]
clebert suconic commented on ARTEMIS-212:
-
the HTTP schema is probably because of the application server integration
layer.. not Artemis code.
[~jmelby] can you confirm this as a non artemis issue and either close this
issue or provide a failing test?
Unable to parse IPv6 address
Key: ARTEMIS-212
URL: https://issues.apache.org/jira/browse/ARTEMIS-212
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff Mesnil
Assignee: Justin Bertram
In our test suite, we have tests failing when using IPv6:
{noformat}
Caused by: java.io.InvalidObjectException: URLDecoder: Illegal hex characters
in escape (%) pattern - For input string: et
at
org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.readExternal(ActiveMQConnectionFactory.java:117)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1308)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:59)
at
org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
at
org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:232)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This issue can be reproduced by using URLDecoder to decode an URL with IPv6
address such as http://[fe80::baf6:b1ff:fe12:daf7%en0]:80?foo=barbaz=blah;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQ-5947) Use replicated levelDB store，broker cannot elect a master
angus.aqlu created AMQ-5947:
---
Summary: Use replicated levelDB store，broker cannot elect a master
Key: AMQ-5947
URL: https://issues.apache.org/jira/browse/AMQ-5947
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.10.2
Environment: java version 1.7.0_55
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
Centos 6.5
Reporter: angus.aqlu
I used replicated levelDB store, Configured as follows:
{code:xml}
replicatedLevelDB directory=/amq_data/leveldb replicas=3
bind=tcp://0.0.0.0:0 zkAddress=192.168.1.105:2181
zkPath=/activemq/leveldb-stores hostname=192.168.1.101 weight=1/
{code}
And I have 3 replicas(192.168.1.101、192.168.1.102、192.168.1.103), and then
each start 3 nodes, it's working properly!
But when I started the iptables of zookeeper(192.168.1.105)，simulate
network interruption. I got many NoRouteToHostException with 3 broker, and
the master borker was shutdown.
When I run service iptables stop on zookeeper(192.168.1.105) ，the remaining
two nodes do not have to re elect the master broker, Is this a bug?
thanks a lot!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5408) jaasDualAuthenticationPlugin with client authentication not working for networkConnector
[ https://issues.apache.org/jira/browse/AMQ-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712878#comment-14712878 ] Torsten Mielke commented on AMQ-5408: - Is this the same bug as AMQ-5943, which we fixed two days ago? jaasDualAuthenticationPlugin with client authentication not working for networkConnector Key: AMQ-5408 URL: https://issues.apache.org/jira/browse/AMQ-5408 Project: ActiveMQ Issue Type: Bug Components: Transport Affects Versions: 5.10.0 Environment: Windows, Java 1.7 Reporter: Henrik Karlsson Attachments: conf.zip When using jaasDualAuthentication with username/password for tcp connections and certification authentication for ssl, this works just fine then connection as a client. But when I try to setup a network connector over ssl with certification authentication it fails to connect with this error: java.lang.SecurityException: User name [null] or password is invalid. I also tried with nio+ssl with the same result If I change to jaasCertificateAuthentication it works for ssl connections but the non ssl fails (as expected) When I use nio+ssl with jaasCertificateAuthentication this also fails with this error: java.lang.SecurityException: Unable to authenticate transport without SSL certificate. But after failing 3 times it finally connects successfully on the 4:th attempt. So it seems that jaasDualAuthentication doesn't work with Certificate Authentication. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (AMQ-5409) With prefetch 0, Spring Default Message Listener Shutdown never ends
[
https://issues.apache.org/jira/browse/AMQ-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wawan closed AMQ-5409.
--
Resolution: Fixed
With prefetch 0, Spring Default Message Listener Shutdown never ends
Key: AMQ-5409
URL: https://issues.apache.org/jira/browse/AMQ-5409
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.1, 5.10.0
Environment: Ubuntu 13.10 64Bits
Reporter: Wawan
Attachments: PrefetchTest.java, SimpleMessageListener.java,
testPrefetch_0_Deadlock.appctx.xml,
testPrefetch_0_WithTransactionManager.appctx.xml, testPrefetch_1.appctx.xml,
testprefetch.tgz
When prefetch is set to 0, the shutdown of a Spring Default Message Listener
never ends. We think there is a deadlock.
This does not occur when prefetch is 1 or when we set a TransactionManager in
the Spring Default Message Listener.
DeadLock :
jmsContainer-4@2020 prio=5 tid=0x14 nid=NA waiting
java.lang.Thread.State: WAITING
at java.lang.Object.wait(Object.java:-1)
at java.lang.Object.wait(Object.java:485)
at
org.apache.activemq.SimplePriorityMessageDispatchChannel.dequeue(SimplePriorityMessageDispatchChannel.java:90)
at
org.apache.activemq.ActiveMQMessageConsumer.dequeue(ActiveMQMessageConsumer.java:478)
at
org.apache.activemq.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:629)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveMessage(AbstractPollingMessageListenerContainer.java:430)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:310)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1102)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:996)
at java.lang.Thread.run(Thread.java:662)
Thread-0@594 prio=5 tid=0xb nid=NA waiting
java.lang.Thread.State: WAITING
at java.lang.Object.wait(Object.java:-1)
at java.lang.Object.wait(Object.java:485)
at
org.springframework.jms.listener.DefaultMessageListenerContainer.doShutdown(DefaultMessageListenerContainer.java:543)
at
org.springframework.jms.listener.AbstractJmsListeningContainer.shutdown(AbstractJmsListeningContainer.java:237)
at
com.testprefetch.PrefetchTest.startAndStopContainer(PrefetchTest.java:43)
at
com.testprefetch.PrefetchTest.testStopDMLCPrefetch0(PrefetchTest.java:15)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
This could be related with method
org.apache.activemq.ActiveMQMessageConsumer#receive(long) :
if (info.getPrefetchSize() == 0) {
md = dequeue(-1); // We let the broker let us know when we
timeout.
} else {
md = dequeue(timeout);
}
Issue present in versions :
ActiveMQ 5.9.1, 5.10.0
Springframework 3.2.8.RELEASE, 4.0.5.RELEASE
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5831) Revisit topic statistics
[ https://issues.apache.org/jira/browse/AMQ-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712904#comment-14712904 ] ASF subversion and git services commented on AMQ-5831: -- Commit ee54f09303f52d2753ce9ac8e64008e3e60c2eab in activemq's branch refs/heads/master from [~dejanb] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=ee54f09 ] https://issues.apache.org/jira/browse/AMQ-5831 - revisit topic subscriptions Revisit topic statistics Key: AMQ-5831 URL: https://issues.apache.org/jira/browse/AMQ-5831 Project: ActiveMQ Issue Type: Improvement Affects Versions: 5.11.0 Reporter: Dejan Bosanac Currently, topic statistics can be confusing especially if you're using wildcard subscribers. In that case, inflight count and dequeue count is never updated when message is acked, so users can think that messages are not consumed. Statistics are primarily developed for queues and then adapted for topics, which is why is some of them doesn't make sense in this use case. To me, it'd make sense to keep only enqueue/dequeue properties on the topic, so that we can see general behaviour of the topic. Then every consumer, should keep it's own enqueue, dequeue, inflight (enqueue-dequeue) counts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5941) The ra.xml resourceadapter-class class 'org.apache.activemq.ra.ActiveMQResourceAdapter' should implement java.io.Serializable but does not.
[ https://issues.apache.org/jira/browse/AMQ-5941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712676#comment-14712676 ] Ben Nisbet commented on AMQ-5941: - [~cshannon] We are introducing JMS as part of an enhancement to a live application currently running on JRockit 1.6 therefore we are restricted to latest compatible ActiveMQ version. (v5.10.x) If it is still possible for the change to be implemented in that branch then I can re-test. The ra.xml resourceadapter-class class 'org.apache.activemq.ra.ActiveMQResourceAdapter' should implement java.io.Serializable but does not. - Key: AMQ-5941 URL: https://issues.apache.org/jira/browse/AMQ-5941 Project: ActiveMQ Issue Type: Improvement Components: Connector Affects Versions: 5.10.2 Environment: WebLogic 10.3.6, JRockit JDK 1.6 Reporter: Ben Nisbet Assignee: Christopher L. Shannon Priority: Minor Fix For: 5.13.0 WebLogic server requires ResourceAdapter class to implement Serializable in addition to conformance with JavaBeans spec: The ra.xml resourceadapter-class class 'org.apache.activemq.ra.ActiveMQResourceAdapter' should implement java.io.Serializable but does not. Is there an internal implementation constraint preventing implementation of Serializable for class org.apache.activemq.ra.ActiveMQResourceAdapter in next release? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5944) Update commons-pool2 to handle OSGi classloading issue
[ https://issues.apache.org/jira/browse/AMQ-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712952#comment-14712952 ] Krzysztof Sobkowiak commented on AMQ-5944: -- I have described the problem and provided a purr request with fix in AMQ-5861 Update commons-pool2 to handle OSGi classloading issue -- Key: AMQ-5944 URL: https://issues.apache.org/jira/browse/AMQ-5944 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.12.0 Environment: Karaf3 Reporter: Martin Lichtin Fix For: 5.12.1, 5.13.0 As mentioned in http://activemq.2283324.n4.nabble.com/OSGi-ClassNotFoundException-when-trying-to-upgrade-from-5-11-1-to-5-12-0-td4701124.html there's a classloading issue with commons-pool2. It's apparently been fixed in more recent versions: POOL-289 POOL-292 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5944) Update commons-pool2 to handle OSGi classloading issue
[ https://issues.apache.org/jira/browse/AMQ-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712952#comment-14712952 ] Krzysztof Sobkowiak edited comment on AMQ-5944 at 8/26/15 11:19 AM: I have described the problem and provided a pull request with fix in AMQ-5861 was (Author: sobkowiak): I have described the problem and provided a purr request with fix in AMQ-5861 Update commons-pool2 to handle OSGi classloading issue -- Key: AMQ-5944 URL: https://issues.apache.org/jira/browse/AMQ-5944 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.12.0 Environment: Karaf3 Reporter: Martin Lichtin Fix For: 5.12.1, 5.13.0 As mentioned in http://activemq.2283324.n4.nabble.com/OSGi-ClassNotFoundException-when-trying-to-upgrade-from-5-11-1-to-5-12-0-td4701124.html there's a classloading issue with commons-pool2. It's apparently been fixed in more recent versions: POOL-289 POOL-292 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-213) Wireformat Negotiation doesn't not working
Howard Gao created ARTEMIS-213: -- Summary: Wireformat Negotiation doesn't not working Key: ARTEMIS-213 URL: https://issues.apache.org/jira/browse/ARTEMIS-213 Project: ActiveMQ Artemis Issue Type: Sub-task Components: OpenWire Affects Versions: 1.0.0 Reporter: Howard Gao Assignee: Howard Gao Fix For: 1.1.0 Client can negotiate a working wireformat version with broker. If a client requests a earlier version of wireformat the broker should respect it. e.g. if a client request: tcp://localhost:61616?wireFormat.version=1 The server should confirm that the version to be used is 1. Test: WireformatNegociationTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ARTEMIS-208) Fix BrokerInfo Issue
[ https://issues.apache.org/jira/browse/ARTEMIS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Howard Gao closed ARTEMIS-208. -- Resolution: Fixed See Clebert's PR. Fix BrokerInfo Issue Key: ARTEMIS-208 URL: https://issues.apache.org/jira/browse/ARTEMIS-208 Project: ActiveMQ Artemis Issue Type: Sub-task Components: OpenWire Affects Versions: 1.0.0 Reporter: Howard Gao Assignee: Howard Gao Fix For: 1.1.0 When a client opens a connection to broker, the broker should send back a BrokerInfo command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-214) exception when sending 10k message
Andy Taylor created ARTEMIS-214:
---
Summary: exception when sending 10k message
Key: ARTEMIS-214
URL: https://issues.apache.org/jira/browse/ARTEMIS-214
Project: ActiveMQ Artemis
Issue Type: Bug
Components: AMQP
Reporter: Andy Taylor
if you send a 10kb message using the qpid jms client the server throws an
exception:
java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:267)
at
org.apache.qpid.proton.codec.DecoderImpl.readRaw(DecoderImpl.java:945)
at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:169)
at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:121)
at
org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:39)
at
org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885)
at
org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:647)
at
org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:577)
at
org.apache.qpid.proton.jms.EncodedMessage.decode(EncodedMessage.java:46)
at
org.apache.qpid.proton.jms.JMSMappingInboundTransformer.transform(JMSMappingInboundTransformer.java:40)
at
org.apache.activemq.artemis.core.protocol.proton.converter.ProtonMessageConverter.inboundJMSType(ProtonMessageConverter.java:61)
at
org.apache.activemq.artemis.core.protocol.proton.converter.ProtonMessageConverter.inbound(ProtonMessageConverter.java:47)
at
org.apache.activemq.artemis.core.protocol.proton.plug.ProtonSessionIntegrationCallback.serverSend(ProtonSessionIntegrationCallback.java:269)
at
org.proton.plug.context.server.ProtonServerReceiverContext.onMessage(ProtonServerReceiverContext.java:131)
at
org.proton.plug.context.AbstractConnectionContext$LocalListener.onDelivery(AbstractConnectionContext.java:277)
at org.proton.plug.handler.Events.dispatch(Events.java:104)
at
org.proton.plug.handler.impl.ProtonHandlerImpl.dispatch(ProtonHandlerImpl.java:399)
at
org.proton.plug.handler.impl.ProtonHandlerImpl.flush(ProtonHandlerImpl.java:298)
at
org.proton.plug.handler.impl.ProtonHandlerImpl.inputBuffer(ProtonHandlerImpl.java:178)
at
org.proton.plug.context.AbstractConnectionContext.inputBuffer(AbstractConnectionContext.java:72)
at
org.apache.activemq.artemis.core.protocol.proton.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:142)
at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
at java.lang.Thread.run(Thread.java:745)
the following code will show it
try
{
ctx = new InitialContext(properties);
connection = ((ConnectionFactory)
ctx.lookup(connection)).createConnection();
session = connection.createSession(false,
Session.CLIENT_ACKNOWLEDGE);
producer = session.createProducer((Destination)
ctx.lookup(address));
if (!options.persistent)
{
producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
}
else
{
producer.setDeliveryMode(DeliveryMode.PERSISTENT);
}
connection.start();
TextMessage message =
session.createTextMessage(options.messageText);
producer.send(message);
producer.close();
session.close();
connection.close();
}
catch (NamingException | JMSException e)
{
e.printStackTrace();
}
private static String createMessage(int
[jira] [Resolved] (AMQ-5831) Revisit topic statistics
[ https://issues.apache.org/jira/browse/AMQ-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dejan Bosanac resolved AMQ-5831. Resolution: Fixed Assignee: Dejan Bosanac Fix Version/s: 5.13.0 Fixed. After the work on [AMQ-5837], we now track dispatched messages which made it easier to implement statistic semantics similar to queues. I also changed semantics of durable subscribers to increment dequeue count on each ack. Revisit topic statistics Key: AMQ-5831 URL: https://issues.apache.org/jira/browse/AMQ-5831 Project: ActiveMQ Issue Type: Improvement Affects Versions: 5.11.0 Reporter: Dejan Bosanac Assignee: Dejan Bosanac Fix For: 5.13.0 Currently, topic statistics can be confusing especially if you're using wildcard subscribers. In that case, inflight count and dequeue count is never updated when message is acked, so users can think that messages are not consumed. Statistics are primarily developed for queues and then adapted for topics, which is why is some of them doesn't make sense in this use case. To me, it'd make sense to keep only enqueue/dequeue properties on the topic, so that we can see general behaviour of the topic. Then every consumer, should keep it's own enqueue, dequeue, inflight (enqueue-dequeue) counts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-213) Fix WireFormatTest
[ https://issues.apache.org/jira/browse/ARTEMIS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-213: Summary: Fix WireFormatTest (was: Wireformat Negotiation doesn't not working) I don't think the wire format negotiation is broken. The issue is that the test itself will start a new ActiveMQ server and use some activemq5 exclusive things. The test is broken... I am doing some work with wireFormat because of KeepAlive, so leave this one with me.. I will rewrite the test to fit Artemis. Fix WireFormatTest -- Key: ARTEMIS-213 URL: https://issues.apache.org/jira/browse/ARTEMIS-213 Project: ActiveMQ Artemis Issue Type: Sub-task Components: OpenWire Affects Versions: 1.0.0 Reporter: Howard Gao Assignee: Howard Gao Fix For: 1.1.0 Client can negotiate a working wireformat version with broker. If a client requests a earlier version of wireformat the broker should respect it. e.g. if a client request: tcp://localhost:61616?wireFormat.version=1 The server should confirm that the version to be used is 1. Test: WireformatNegociationTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-213) Fix WireFormatNegoTest
[ https://issues.apache.org/jira/browse/ARTEMIS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-213: Summary: Fix WireFormatNegoTest (was: Fix WireFormatTest) Fix WireFormatNegoTest -- Key: ARTEMIS-213 URL: https://issues.apache.org/jira/browse/ARTEMIS-213 Project: ActiveMQ Artemis Issue Type: Sub-task Components: OpenWire Affects Versions: 1.0.0 Reporter: Howard Gao Assignee: Howard Gao Fix For: 1.1.0 Client can negotiate a working wireformat version with broker. If a client requests a earlier version of wireformat the broker should respect it. e.g. if a client request: tcp://localhost:61616?wireFormat.version=1 The server should confirm that the version to be used is 1. Test: WireformatNegociationTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5936) No option to throttle a producer which sends messages in a batch
[ https://issues.apache.org/jira/browse/AMQ-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Selvakumar updated AMQ-5936: -- Affects Version/s: (was: 5.10.0) 5.8.0 No option to throttle a producer which sends messages in a batch Key: AMQ-5936 URL: https://issues.apache.org/jira/browse/AMQ-5936 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.8.0 Reporter: James Selvakumar Priority: Critical I couldn't find any option to throttle a producer which sends messages in batches (using JMS transaction with a batch size 1) to a queue using TCP (openwire?) protocol. As a result, the queue is flooded with messages. The producer however, is stopped when the *storeUsage* limit is reached. P.S * I raised this issue in the [Mailing List|http://activemq.2283324.n4.nabble.com/What-is-the-correct-way-to-throttle-ActiveMQ-producers-who-send-persistent-messages-in-batches-to-a--tp4701204.html] but didn't get any convincing answer which prompted me to file this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (AMQ-5936) No option to throttle a producer which sends messages in a batch
[ https://issues.apache.org/jira/browse/AMQ-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Selvakumar closed AMQ-5936. - Resolution: Implemented Fix Version/s: 5.9.0 I have tested and found this to be working as expected i.e PFC is applied out of the box even for async/batch sends. I tested this with the following versions: * 5.9.0 * 5.10.0 * 5.12.0 No option to throttle a producer which sends messages in a batch Key: AMQ-5936 URL: https://issues.apache.org/jira/browse/AMQ-5936 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.8.0 Reporter: James Selvakumar Priority: Critical Fix For: 5.9.0 I couldn't find any option to throttle a producer which sends messages in batches (using JMS transaction with a batch size 1) to a queue using TCP (openwire?) protocol. As a result, the queue is flooded with messages. The producer however, is stopped when the *storeUsage* limit is reached. P.S * I raised this issue in the [Mailing List|http://activemq.2283324.n4.nabble.com/What-is-the-correct-way-to-throttle-ActiveMQ-producers-who-send-persistent-messages-in-batches-to-a--tp4701204.html] but didn't get any convincing answer which prompted me to file this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5948) connection.start hangs with tcp transport wrong username / password
Antonio Castaldo D'Ursi created AMQ-5948: Summary: connection.start hangs with tcp transport wrong username / password Key: AMQ-5948 URL: https://issues.apache.org/jira/browse/AMQ-5948 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.12.0 Reporter: Antonio Castaldo D'Ursi Hi, I am trying to connect to an ActiveMq Broker version 5.11.1 , using the ActiveMQConnectionFactory. On the client side I tried both client version 5.11.2 and 5.12.0 On server side, authentication is enabled. If I supply wrong username and password, the call to connection.start() hangs . Debugging the code, I see it hangs in org.apache.activemq.transport.FutureResponse.getResult(). (this is indirectly called by syncSendPacket in the ensureConnectionInfoSent method in ActiveMQConnectionFactory) On server side, i see the error message: INFO | Stopping tcp://127.0.0.1:53846 because Failed with SecurityException: User name [null] or password is invalid. It looks like client side is waiting indefinitely for an answer that will never arrive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5948) connection.start hangs with tcp transport wrong username / password
[ https://issues.apache.org/jira/browse/AMQ-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14714158#comment-14714158 ] Timothy Bish commented on AMQ-5948: --- Would surprise me that this is the case given that we have tests for this very scenario. I'd recommend you create a unit test that encapsulates your broker and client configuration to reproduce the problem. connection.start hangs with tcp transport wrong username / password --- Key: AMQ-5948 URL: https://issues.apache.org/jira/browse/AMQ-5948 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.12.0 Reporter: Antonio Castaldo D'Ursi Hi, I am trying to connect to an ActiveMq Broker version 5.11.1 , using the ActiveMQConnectionFactory. On the client side I tried both client version 5.11.2 and 5.12.0 On server side, authentication is enabled. If I supply wrong username and password, the call to connection.start() hangs . Debugging the code, I see it hangs in org.apache.activemq.transport.FutureResponse.getResult(). (this is indirectly called by syncSendPacket in the ensureConnectionInfoSent method in ActiveMQConnectionFactory) On server side, i see the error message: INFO | Stopping tcp://127.0.0.1:53846 because Failed with SecurityException: User name [null] or password is invalid. It looks like client side is waiting indefinitely for an answer that will never arrive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
