[jira] [Comment Edited] (AMQ-8437) Destination policy not applied when multiple policies with wildcard exist
[
https://issues.apache.org/jira/browse/AMQ-8437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17511721#comment-17511721
]
ruffp edited comment on AMQ-8437 at 3/24/22, 9:30 AM:
--
Hi,
I think by default ActiveMQ uses the dot ('.') as path separator. The policy
feature is working well in our instance using the dots instead slashes ('/').
[~rohanc] did you add the plugin at the end
of your activemq.xml ?
see: [https://stackoverflow.com/a/24057006/628006]
was (Author: ruffp):
Hi,
I think by default ActiveMQ uses the dot (.) as path separator. The policy
feature is working well in our instance using the dots instead slashes (/).
[~rohanc] did you add the plugin at the end
of your activemq.xml ?
see: [https://stackoverflow.com/a/24057006/628006]
> Destination policy not applied when multiple policies with wildcard exist
> -
>
> Key: AMQ-8437
> URL: https://issues.apache.org/jira/browse/AMQ-8437
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.16.0, 5.16.3
> Environment: centos 7; activeMQ version 5.16.3
>Reporter: Rohan Chauhan
>Priority: Major
>
> I am setting up deadLetterStrategy for undelivered messages but the
> individualDeadLetterStrategy doesn't get applied if I use a wildcard. I was
> expecting DLQ.app/events/foo to be created, for a queue named app/events/foo,
> and undelivered messages moved into it. Unfortunately the individual DLQ is
> not created and undelivered messages end up in default DLQ i.e. ActiveMQ.DLQ.
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
> useQueueForQueueMessages="true"/>
>
>
>
>
> {code}
>
> The individualDeadLetterStrategy works fine when I don't use wildcard.
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
> useQueueForQueueMessages="true"/>
>
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (AMQ-8437) Destination policy not applied when multiple policies with wildcard exist
[
https://issues.apache.org/jira/browse/AMQ-8437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17511721#comment-17511721
]
ruffp edited comment on AMQ-8437 at 3/24/22, 9:27 AM:
--
Hi,
I think by default ActiveMQ uses the dot (.) as path separator. The policy
feature is working well in our instance using the dots instead slashes (/).
[~rohanc] did you add the plugin at the end
of your activemq.xml ?
see: [https://stackoverflow.com/a/24057006/628006]
was (Author: ruffp):
Hi,
I think by default ActiveMQ uses the dot (.) as path separator. The policy
feature is working well in our instance using the dots instead slashes (/).
[~rohanc] did you add the plugin at the end
of your activemq.xml ?
see: https://stackoverflow.com/a/24057006/628006
> Destination policy not applied when multiple policies with wildcard exist
> -
>
> Key: AMQ-8437
> URL: https://issues.apache.org/jira/browse/AMQ-8437
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.16.0, 5.16.3
> Environment: centos 7; activeMQ version 5.16.3
>Reporter: Rohan Chauhan
>Priority: Major
>
> I am setting up deadLetterStrategy for undelivered messages but the
> individualDeadLetterStrategy doesn't get applied if I use a wildcard. I was
> expecting DLQ.app/events/foo to be created, for a queue named app/events/foo,
> and undelivered messages moved into it. Unfortunately the individual DLQ is
> not created and undelivered messages end up in default DLQ i.e. ActiveMQ.DLQ.
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
> useQueueForQueueMessages="true"/>
>
>
>
>
> {code}
>
> The individualDeadLetterStrategy works fine when I don't use wildcard.
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
> useQueueForQueueMessages="true"/>
>
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (AMQ-8437) Destination policy not applied when multiple policies with wildcard exist
[
https://issues.apache.org/jira/browse/AMQ-8437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17511721#comment-17511721
]
ruffp commented on AMQ-8437:
Hi,
I think by default ActiveMQ uses the dot (.) as path separator. The policy
feature is working well in our instance using the dots instead slashes (/).
[~rohanc] did you add the plugin at the end
of your activemq.xml ?
see: https://stackoverflow.com/a/24057006/628006
> Destination policy not applied when multiple policies with wildcard exist
> -
>
> Key: AMQ-8437
> URL: https://issues.apache.org/jira/browse/AMQ-8437
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.16.0, 5.16.3
> Environment: centos 7; activeMQ version 5.16.3
>Reporter: Rohan Chauhan
>Priority: Major
>
> I am setting up deadLetterStrategy for undelivered messages but the
> individualDeadLetterStrategy doesn't get applied if I use a wildcard. I was
> expecting DLQ.app/events/foo to be created, for a queue named app/events/foo,
> and undelivered messages moved into it. Unfortunately the individual DLQ is
> not created and undelivered messages end up in default DLQ i.e. ActiveMQ.DLQ.
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
> useQueueForQueueMessages="true"/>
>
>
>
>
> {code}
>
> The individualDeadLetterStrategy works fine when I don't use wildcard.
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
> useQueueForQueueMessages="true"/>
>
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (AMQ-6079) Replace log4j.properties with log4j.xml
[
https://issues.apache.org/jira/browse/AMQ-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17218170#comment-17218170
]
ruffp commented on AMQ-6079:
One good reason would be to be able to use the \{{TimeBasedRollingPolicy}}
which seems not supported through the log4j.properties. Reference:
[https://stackoverflow.com/a/5187007/628006]
We currently rely on the not recommended
[DailyRollingFileAppender|https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/DailyRollingFileAppender.html]
which shows synchronization issues and we do not have any other alternative to
make a reliable daily audit log (from a custom AMQ plugin).
> Replace log4j.properties with log4j.xml
> ---
>
> Key: AMQ-6079
> URL: https://issues.apache.org/jira/browse/AMQ-6079
> Project: ActiveMQ
> Issue Type: Improvement
>Reporter: Laure Lussac
>Priority: Minor
>
> Certain log4j features are not configurable via the log4j.properties file.
> For this reason, it could be converted to a XML file to configure log4j.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (AMQ-6596) Out Of Memory error reported on ActiveMQ client during openwire unmarshalling
[
https://issues.apache.org/jira/browse/AMQ-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080250#comment-16080250
]
ruffp edited comment on AMQ-6596 at 7/10/17 12:27 PM:
--
... and if I "dd" your packet.raw with:
{{dd if=packet.raw > /dev/tcp/localhost/61616 }}
I get the OOME everytime (Tested with AMQ 5.10.2).
I think this is more an issue in OpenWire protocol than specific to ActiveMQ.
was (Author: ruffp):
... and if I "dd" your packet.raw with:
{{dd if=packet.raw > /dev/tcp/localhost/61616 }}
I get the OOME everytime.
I think this is more an issue in OpenWire protocol than specific to ActiveMQ.
> Out Of Memory error reported on ActiveMQ client during openwire unmarshalling
> -
>
> Key: AMQ-6596
> URL: https://issues.apache.org/jira/browse/AMQ-6596
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, JMS client, Transport
>Affects Versions: 5.13.0, 5.13.5, 5.14.3
> Environment: SUSE Linux Enterprise Server 11 (x86_64), VERSION = 11,
> PATCHLEVEL = 3. Java Runtime: IBM Corporation 1.7.0
>Reporter: Konstantinos Pistopoulos
>Priority: Critical
> Attachments: packet.raw
>
>
> ActiveMQ crashes during a vulnerability scanning using Qualys vulnerability
> scanner.
> {code}
> 2017-02-10 14:30:18,631 [0.1:55345@61616] WARN Transport
> - Transport Connection to: tcp://127.0.0.1:55345 failed:
> java.io.IOException: Unexpected error occurred: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> This OOM error is caused due to an attempt to initialize a huge byte array of
> 2131230728 bytes size. The problem still occurs even if we define the
> maxFrameSize to 100MB.
> It seems that the first comparison with the maxFrameSize is successful
> (method unmarshal) but in the later evaluation of dataIn.readInt() in method
> looseUnmarshalByteSequence, a huge value is evaluated (2131230728 bytes)
> {code}
> @Override
> public Object unmarshal(DataInput dis) throws IOException {
> DataInput dataIn = dis;
> if (!sizePrefixDisabled) {
> int size = dis.readInt();
> if (size > maxFrameSize) {
> throw IOExceptionSupport.createFrameSizeException(size,
> maxFrameSize);
> }
> // int size = dis.readInt();
> // byte[] data = new byte[size];
> // dis.readFully(data);
> // bytesIn.restart(data);
> // dataIn = bytesIn;
> }
> return doUnmarshal(dataIn);
> }
> {code}
> {code}
> protected ByteSequence looseUnmarshalByteSequence(DataInput dataIn)
> throws IOException {
> ByteSequence rc = null;
> if (dataIn.readBoolean()) {
> int size = dataIn.readInt();
> byte[] t = new byte[size];
> dataIn.readFully(t);
> rc = new ByteSequence(t, 0, size);
> }
> return rc;
> }
> {code}
> Relevant parts of the thread dump can be found below:
> {code}
> WARNING : OutOfMemoryError possibly caused by 2131230728 bytes requested for
> object of class 081A5700 from memory space 'Flat' id=080B1898
> {code}
> {code}
> Thread Name
> ActiveMQ Transport: tcp:///10.4.240.10:55345@61616
> State
> Runnable
> Java Stack
> at
> org/apache/activemq/openwire/v12/BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
>
> at
> org/apache/activemq/openwire/v12/WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
>
> at
> org/apache/activemq/openwire/OpenWireFormat.doUnmarshal(OpenWireFormat.java:367(Compiled
> Code))
> at
> org/apache/activemq/openwire/OpenWireFormat.unmarshal(OpenWireFormat.java:278(Compiled
> Code))
> at
> org/apache/activemq/transport/tcp/TcpTransport.readCommand(TcpTransport.java:240(Compiled
> Code))
> at
> org/apache/activemq/transport/tcp/TcpTransport.doRun(TcpTransport.java:232(Compiled
> Code))
> at org/apache/activemq/transport/tcp/TcpTransport.run(TcpTransport.java:215)
> at java/lang/Thread.run(Thread.java:863)
> {code}
> The definition of the transportConnector without the definition of the
> maxFrameSize is the following :
> {code}
>
>
>
> {code}
> The definition of the transportConnector after the definition of the
> maxFrameSize :
> {code}
>
>uri="tcp://0.0.0.0:61616?wireFormat.maxFrameSize=104857600"/>
>
> {code}
> We have reproduced this with versions 5.13.0, 5.13.5 and 5.14.3 but this
> problem is probably related to other versions too.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (AMQ-6596) Out Of Memory error reported on ActiveMQ client during openwire unmarshalling
[
https://issues.apache.org/jira/browse/AMQ-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080250#comment-16080250
]
ruffp edited comment on AMQ-6596 at 7/10/17 12:25 PM:
--
... and if I "dd" your packet with:
{{dd if=packet.raw > /dev/tcp/localhost/61616 }}
I get the OOME everytime.
I think this is more an issue in OpenWire protocol than specific to ActiveMQ.
was (Author: ruffp):
... dnd if I "dd" your packet with:
{{dd if=packet.raw > /dev/tcp/localhost/61616 }}
I get the OOME everytime.
I think this is more an issue in OpenWire protocol than specific to ActiveMQ.
> Out Of Memory error reported on ActiveMQ client during openwire unmarshalling
> -
>
> Key: AMQ-6596
> URL: https://issues.apache.org/jira/browse/AMQ-6596
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, JMS client, Transport
>Affects Versions: 5.13.0, 5.13.5, 5.14.3
> Environment: SUSE Linux Enterprise Server 11 (x86_64), VERSION = 11,
> PATCHLEVEL = 3. Java Runtime: IBM Corporation 1.7.0
>Reporter: Konstantinos Pistopoulos
>Priority: Critical
> Attachments: packet.raw
>
>
> ActiveMQ crashes during a vulnerability scanning using Qualys vulnerability
> scanner.
> {code}
> 2017-02-10 14:30:18,631 [0.1:55345@61616] WARN Transport
> - Transport Connection to: tcp://127.0.0.1:55345 failed:
> java.io.IOException: Unexpected error occurred: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> This OOM error is caused due to an attempt to initialize a huge byte array of
> 2131230728 bytes size. The problem still occurs even if we define the
> maxFrameSize to 100MB.
> It seems that the first comparison with the maxFrameSize is successful
> (method unmarshal) but in the later evaluation of dataIn.readInt() in method
> looseUnmarshalByteSequence, a huge value is evaluated (2131230728 bytes)
> {code}
> @Override
> public Object unmarshal(DataInput dis) throws IOException {
> DataInput dataIn = dis;
> if (!sizePrefixDisabled) {
> int size = dis.readInt();
> if (size > maxFrameSize) {
> throw IOExceptionSupport.createFrameSizeException(size,
> maxFrameSize);
> }
> // int size = dis.readInt();
> // byte[] data = new byte[size];
> // dis.readFully(data);
> // bytesIn.restart(data);
> // dataIn = bytesIn;
> }
> return doUnmarshal(dataIn);
> }
> {code}
> {code}
> protected ByteSequence looseUnmarshalByteSequence(DataInput dataIn)
> throws IOException {
> ByteSequence rc = null;
> if (dataIn.readBoolean()) {
> int size = dataIn.readInt();
> byte[] t = new byte[size];
> dataIn.readFully(t);
> rc = new ByteSequence(t, 0, size);
> }
> return rc;
> }
> {code}
> Relevant parts of the thread dump can be found below:
> {code}
> WARNING : OutOfMemoryError possibly caused by 2131230728 bytes requested for
> object of class 081A5700 from memory space 'Flat' id=080B1898
> {code}
> {code}
> Thread Name
> ActiveMQ Transport: tcp:///10.4.240.10:55345@61616
> State
> Runnable
> Java Stack
> at
> org/apache/activemq/openwire/v12/BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
>
> at
> org/apache/activemq/openwire/v12/WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
>
> at
> org/apache/activemq/openwire/OpenWireFormat.doUnmarshal(OpenWireFormat.java:367(Compiled
> Code))
> at
> org/apache/activemq/openwire/OpenWireFormat.unmarshal(OpenWireFormat.java:278(Compiled
> Code))
> at
> org/apache/activemq/transport/tcp/TcpTransport.readCommand(TcpTransport.java:240(Compiled
> Code))
> at
> org/apache/activemq/transport/tcp/TcpTransport.doRun(TcpTransport.java:232(Compiled
> Code))
> at org/apache/activemq/transport/tcp/TcpTransport.run(TcpTransport.java:215)
> at java/lang/Thread.run(Thread.java:863)
> {code}
> The definition of the transportConnector without the definition of the
> maxFrameSize is the following :
> {code}
>
>
>
> {code}
> The definition of the transportConnector after the definition of the
> maxFrameSize :
> {code}
>
>uri="tcp://0.0.0.0:61616?wireFormat.maxFrameSize=104857600"/>
>
> {code}
> We have reproduced this with versions 5.13.0, 5.13.5 and 5.14.3 but this
> problem is probably related to other versions too.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (AMQ-6596) Out Of Memory error reported on ActiveMQ client during openwire unmarshalling
[
https://issues.apache.org/jira/browse/AMQ-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080250#comment-16080250
]
ruffp commented on AMQ-6596:
... dnd if I "dd" your packet with:
{{dd if=packet.raw > /dev/tcp/localhost/61616 }}
I get the OOME everytime.
I think this is more an issue in OpenWire protocol than specific to ActiveMQ.
> Out Of Memory error reported on ActiveMQ client during openwire unmarshalling
> -
>
> Key: AMQ-6596
> URL: https://issues.apache.org/jira/browse/AMQ-6596
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, JMS client, Transport
>Affects Versions: 5.13.0, 5.13.5, 5.14.3
> Environment: SUSE Linux Enterprise Server 11 (x86_64), VERSION = 11,
> PATCHLEVEL = 3. Java Runtime: IBM Corporation 1.7.0
>Reporter: Konstantinos Pistopoulos
>Priority: Critical
> Attachments: packet.raw
>
>
> ActiveMQ crashes during a vulnerability scanning using Qualys vulnerability
> scanner.
> {code}
> 2017-02-10 14:30:18,631 [0.1:55345@61616] WARN Transport
> - Transport Connection to: tcp://127.0.0.1:55345 failed:
> java.io.IOException: Unexpected error occurred: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> This OOM error is caused due to an attempt to initialize a huge byte array of
> 2131230728 bytes size. The problem still occurs even if we define the
> maxFrameSize to 100MB.
> It seems that the first comparison with the maxFrameSize is successful
> (method unmarshal) but in the later evaluation of dataIn.readInt() in method
> looseUnmarshalByteSequence, a huge value is evaluated (2131230728 bytes)
> {code}
> @Override
> public Object unmarshal(DataInput dis) throws IOException {
> DataInput dataIn = dis;
> if (!sizePrefixDisabled) {
> int size = dis.readInt();
> if (size > maxFrameSize) {
> throw IOExceptionSupport.createFrameSizeException(size,
> maxFrameSize);
> }
> // int size = dis.readInt();
> // byte[] data = new byte[size];
> // dis.readFully(data);
> // bytesIn.restart(data);
> // dataIn = bytesIn;
> }
> return doUnmarshal(dataIn);
> }
> {code}
> {code}
> protected ByteSequence looseUnmarshalByteSequence(DataInput dataIn)
> throws IOException {
> ByteSequence rc = null;
> if (dataIn.readBoolean()) {
> int size = dataIn.readInt();
> byte[] t = new byte[size];
> dataIn.readFully(t);
> rc = new ByteSequence(t, 0, size);
> }
> return rc;
> }
> {code}
> Relevant parts of the thread dump can be found below:
> {code}
> WARNING : OutOfMemoryError possibly caused by 2131230728 bytes requested for
> object of class 081A5700 from memory space 'Flat' id=080B1898
> {code}
> {code}
> Thread Name
> ActiveMQ Transport: tcp:///10.4.240.10:55345@61616
> State
> Runnable
> Java Stack
> at
> org/apache/activemq/openwire/v12/BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
>
> at
> org/apache/activemq/openwire/v12/WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
>
> at
> org/apache/activemq/openwire/OpenWireFormat.doUnmarshal(OpenWireFormat.java:367(Compiled
> Code))
> at
> org/apache/activemq/openwire/OpenWireFormat.unmarshal(OpenWireFormat.java:278(Compiled
> Code))
> at
> org/apache/activemq/transport/tcp/TcpTransport.readCommand(TcpTransport.java:240(Compiled
> Code))
> at
> org/apache/activemq/transport/tcp/TcpTransport.doRun(TcpTransport.java:232(Compiled
> Code))
> at org/apache/activemq/transport/tcp/TcpTransport.run(TcpTransport.java:215)
> at java/lang/Thread.run(Thread.java:863)
> {code}
> The definition of the transportConnector without the definition of the
> maxFrameSize is the following :
> {code}
>
>
>
> {code}
> The definition of the transportConnector after the definition of the
> maxFrameSize :
> {code}
>
>uri="tcp://0.0.0.0:61616?wireFormat.maxFrameSize=104857600"/>
>
> {code}
> We have reproduced this with versions 5.13.0, 5.13.5 and 5.14.3 but this
> problem is probably related to other versions too.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (AMQ-6596) Out Of Memory error reported on ActiveMQ client during openwire unmarshalling
[
https://issues.apache.org/jira/browse/AMQ-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080250#comment-16080250
]
ruffp edited comment on AMQ-6596 at 7/10/17 12:25 PM:
--
... and if I "dd" your packet.raw with:
{{dd if=packet.raw > /dev/tcp/localhost/61616 }}
I get the OOME everytime.
I think this is more an issue in OpenWire protocol than specific to ActiveMQ.
was (Author: ruffp):
... and if I "dd" your packet with:
{{dd if=packet.raw > /dev/tcp/localhost/61616 }}
I get the OOME everytime.
I think this is more an issue in OpenWire protocol than specific to ActiveMQ.
> Out Of Memory error reported on ActiveMQ client during openwire unmarshalling
> -
>
> Key: AMQ-6596
> URL: https://issues.apache.org/jira/browse/AMQ-6596
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, JMS client, Transport
>Affects Versions: 5.13.0, 5.13.5, 5.14.3
> Environment: SUSE Linux Enterprise Server 11 (x86_64), VERSION = 11,
> PATCHLEVEL = 3. Java Runtime: IBM Corporation 1.7.0
>Reporter: Konstantinos Pistopoulos
>Priority: Critical
> Attachments: packet.raw
>
>
> ActiveMQ crashes during a vulnerability scanning using Qualys vulnerability
> scanner.
> {code}
> 2017-02-10 14:30:18,631 [0.1:55345@61616] WARN Transport
> - Transport Connection to: tcp://127.0.0.1:55345 failed:
> java.io.IOException: Unexpected error occurred: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> This OOM error is caused due to an attempt to initialize a huge byte array of
> 2131230728 bytes size. The problem still occurs even if we define the
> maxFrameSize to 100MB.
> It seems that the first comparison with the maxFrameSize is successful
> (method unmarshal) but in the later evaluation of dataIn.readInt() in method
> looseUnmarshalByteSequence, a huge value is evaluated (2131230728 bytes)
> {code}
> @Override
> public Object unmarshal(DataInput dis) throws IOException {
> DataInput dataIn = dis;
> if (!sizePrefixDisabled) {
> int size = dis.readInt();
> if (size > maxFrameSize) {
> throw IOExceptionSupport.createFrameSizeException(size,
> maxFrameSize);
> }
> // int size = dis.readInt();
> // byte[] data = new byte[size];
> // dis.readFully(data);
> // bytesIn.restart(data);
> // dataIn = bytesIn;
> }
> return doUnmarshal(dataIn);
> }
> {code}
> {code}
> protected ByteSequence looseUnmarshalByteSequence(DataInput dataIn)
> throws IOException {
> ByteSequence rc = null;
> if (dataIn.readBoolean()) {
> int size = dataIn.readInt();
> byte[] t = new byte[size];
> dataIn.readFully(t);
> rc = new ByteSequence(t, 0, size);
> }
> return rc;
> }
> {code}
> Relevant parts of the thread dump can be found below:
> {code}
> WARNING : OutOfMemoryError possibly caused by 2131230728 bytes requested for
> object of class 081A5700 from memory space 'Flat' id=080B1898
> {code}
> {code}
> Thread Name
> ActiveMQ Transport: tcp:///10.4.240.10:55345@61616
> State
> Runnable
> Java Stack
> at
> org/apache/activemq/openwire/v12/BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:638)
>
> at
> org/apache/activemq/openwire/v12/WireFormatInfoMarshaller.looseUnmarshal(WireFormatInfoMarshaller.java:132)
>
> at
> org/apache/activemq/openwire/OpenWireFormat.doUnmarshal(OpenWireFormat.java:367(Compiled
> Code))
> at
> org/apache/activemq/openwire/OpenWireFormat.unmarshal(OpenWireFormat.java:278(Compiled
> Code))
> at
> org/apache/activemq/transport/tcp/TcpTransport.readCommand(TcpTransport.java:240(Compiled
> Code))
> at
> org/apache/activemq/transport/tcp/TcpTransport.doRun(TcpTransport.java:232(Compiled
> Code))
> at org/apache/activemq/transport/tcp/TcpTransport.run(TcpTransport.java:215)
> at java/lang/Thread.run(Thread.java:863)
> {code}
> The definition of the transportConnector without the definition of the
> maxFrameSize is the following :
> {code}
>
>
>
> {code}
> The definition of the transportConnector after the definition of the
> maxFrameSize :
> {code}
>
>uri="tcp://0.0.0.0:61616?wireFormat.maxFrameSize=104857600"/>
>
> {code}
> We have reproduced this with versions 5.13.0, 5.13.5 and 5.14.3 but this
> problem is probably related to other versions too.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (AMQ-6596) Out Of Memory error reported on ActiveMQ client during openwire unmarshalling
[
https://issues.apache.org/jira/browse/AMQ-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080233#comment-16080233
]
ruffp commented on AMQ-6596:
We noticed the same behavior by sending arbitrary data to the openwire port in
our ActiveMQ 5.10.2.
Not sure if this is related to the same bug, but executing the following bash
script on the same machine:
{code}
#!/bin/bash
if [ -t 0 ]; then stty -echo -icanon -icrnl time 0 min 0; fi
count=0
keypress=''
while [ "x$keypress" = "x" ]; do
let count+=1
echo -ne $count'\r'
keypress="`cat -v`"
dd if=/dev/urandom bs=1 count=120 > /dev/tcp/localhost/61616
done
if [ -t 0 ]; then stty sane; fi
echo "You pressed '$keypress' after $count loop iterations"
exit 0
{code}
makes the OutOfMemoryError happens few times even the data are smaller (try
with bs=100 instead).
By executing this script on the latest ActiveMQ 5.14.5 I get the same results.
Here's a extract of the logs:
{noformat}
INFO | jvm 1| 2017/07/10 10:27:30 | WARN | Transport Connection to:
tcp://127.0.0.1:0 failed: java.io.IOException: Unknown data type: -11
INFO | jvm 1| 2017/07/10 10:27:30 | WARN | Transport Connection to:
tcp://127.0.0.1:1 failed: java.io.IOException: Frame size of 1611 MB larger
than max allowed 100 MB
INFO | jvm 1| 2017/07/10 10:27:30 | WARN | Transport Connection to:
tcp://127.0.0.1:3 failed: java.io.IOException: Unknown data type: -46
INFO | jvm 1| 2017/07/10 10:27:30 | WARN | Transport Connection to:
tcp://127.0.0.1:2 failed: java.io.IOException: Frame size of 361 MB larger
than max allowed 100 MB
INFO | jvm 1| 2017/07/10 10:27:30 | WARN | Transport Connection to:
tcp://127.0.0.1:5 failed: java.io.IOException: Frame size of 1271 MB larger
than max allowed 100 MB
INFO | jvm 1| 2017/07/10 10:27:30 | WARN | Transport Connection to:
tcp://127.0.0.1:4 failed: java.io.UTFDataFormatException: malformed input
around byte 0
INFO | jvm 1| 2017/07/10 10:27:30 | WARN | Transport Connection to:
tcp://127.0.0.1:7 failed: java.io.IOException: Unexpected error occured:
java.lang.OutOfMemoryError: Java heap space
INFO | jvm 1| 2017/07/10 10:27:30 | WARN | Transport Connection to:
tcp://127.0.0.1:53624 failed: java.io.IOException: Frame size of 467 MB larger
than max allowed 100 MB
INFO | jvm 1| 2017/07/10 10:27:30 | WARN | Transport Connection to:
tcp://127.0.0.1:6 failed: java.io.IOException: Frame size of 1382 MB larger
than max allowed 100 MB
INFO | jvm 1| 2017/07/10 10:27:30 | WARN | Transport Connection to:
tcp://127.0.0.1:55548 failed: java.io.EOFException
INFO | jvm 1| 2017/07/10 10:27:30 | WARN | Transport Connection to:
tcp://127.0.0.1:55543 failed: java.io.IOException: Unknown data type: -110
INFO | jvm 1| 2017/07/10 10:27:30 | WARN | Transport Connection to:
tcp://127.0.0.1:55539 failed: java.io.IOException: Unknown data type: -62
INFO | jvm 1| 2017/07/10 10:27:30 | WARN | Transport Connection to:
tcp://127.0.0.1:55542 failed: java.io.IOException: Unknown data type: -24
{noformat}
When our vulnerabiliy scanner (I don't know which one it was) created such
requests, our ActiveMQ has blocked unexpectedly.
> Out Of Memory error reported on ActiveMQ client during openwire unmarshalling
> -
>
> Key: AMQ-6596
> URL: https://issues.apache.org/jira/browse/AMQ-6596
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, JMS client, Transport
>Affects Versions: 5.13.0, 5.13.5, 5.14.3
> Environment: SUSE Linux Enterprise Server 11 (x86_64), VERSION = 11,
> PATCHLEVEL = 3. Java Runtime: IBM Corporation 1.7.0
>Reporter: Konstantinos Pistopoulos
>Priority: Critical
> Attachments: packet.raw
>
>
> ActiveMQ crashes during a vulnerability scanning using Qualys vulnerability
> scanner.
> {code}
> 2017-02-10 14:30:18,631 [0.1:55345@61616] WARN Transport
> - Transport Connection to: tcp://127.0.0.1:55345 failed:
> java.io.IOException: Unexpected error occurred: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> This OOM error is caused due to an attempt to initialize a huge byte array of
> 2131230728 bytes size. The problem still occurs even if we define the
> maxFrameSize to 100MB.
> It seems that the first comparison with the maxFrameSize is successful
> (method unmarshal) but in the later evaluation of dataIn.readInt() in method
> looseUnmarshalByteSequence, a huge value is evaluated (2131230728 bytes)
> {code}
> @Override
> public Object unmarshal(DataInput dis) throws IOException {
> DataInput dataIn = dis;
> if (!sizePrefixDisabled) {
> int size = dis.readInt();
> if (size > maxFrameSize) {
>
[jira] [Commented] (AMQ-5605) High CPU load when using failover transport in network connector
[
https://issues.apache.org/jira/browse/AMQ-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263740#comment-15263740
]
ruffp commented on AMQ-5605:
Does this bug affect the version 5.10.2 of ActiveMQ? Because we have a similar
problem qith 100% CPU usage and nothing special in logs.
Our ActiveMQ was working fine until we introduce the Network Connector with
{{masterslave:(tcp://host1, tcp://host2)}}
> High CPU load when using failover transport in network connector
>
>
> Key: AMQ-5605
> URL: https://issues.apache.org/jira/browse/AMQ-5605
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.11.0, 5.11.1
> Environment: Ubuntu 14.04, SuSE Enterprise 11.3
>Reporter: Lars Neumann
> Labels: failover
> Fix For: 5.12.0, 5.11.3
>
>
> I've got a configuration with two master/slave setups consisting of 3
> ActiveMQ instances each. They are deployed on three servers, with one
> ActiveMQ instance from each master/slave setup on every server. They are
> using the leveldb and zookeeper. Everything works fine.
> Now I've got the strange behaviour that when I add a network connector to
> each ActiveMQ instance like this:
> {code}
> networkConnector name="toMasterSlave02" dynamicOnly="true"
> uri="masterslave:(tcp://host1:61617,tcp://host2:61617,tcp://host3:61617)"
> {code}
> When you now restart the master of the master/slave setup that is targeted by
> the above network connector the cpu load on the current master goes and stays
> up at 100%, i.e. it uses one CPU per configured transportConnector.
> Now the explanation, mostly copied from
> http://activemq.2283324.n4.nabble.com/High-CPU-load-with-network-connector-failover-transport-tp4691798.html
> {quote}
> When one of the brokers is restarted, the other broker uses ~400% CPU. The
> cause is the FailoverTransport reconnectTask spinning, and nothing is
> stopping the task.
> Reverting this fix made for AMQ-5315, while it does reintroduce the
> NullPointerException, does handle failover properly without spinning:
> https://git1-us-west.apache.org/repos/asf/activemq/repo?p=activemq.git;a=commitdiff;h=c391321d1b5b59542d847717654b0d4dba54cf2f
>
>
> The reason it works after reverting that change is the NullPointerException
> is caught, -> serviceLocalException() ->
> ServiceSupport.dispose(getControllingService()); with the fix made in
> AMQ-5315, the dispose() call is never made.
> {quote}
> Sorry, but I've got no clue how to provide a unit test for this. Maybe
> someone else can help.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5605) High CPU load when using failover transport in network connector
[
https://issues.apache.org/jira/browse/AMQ-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263740#comment-15263740
]
ruffp edited comment on AMQ-5605 at 4/29/16 8:34 AM:
-
Does this bug affect the version 5.10.2 of ActiveMQ? Because we have a similar
problem with 100% CPU usage and nothing special in logs.
Our ActiveMQ was working fine until we introduce the Network Connector with
{{masterslave:(tcp://host1, tcp://host2)}}
was (Author: ruffp):
Does this bug affect the version 5.10.2 of ActiveMQ? Because we have a similar
problem qith 100% CPU usage and nothing special in logs.
Our ActiveMQ was working fine until we introduce the Network Connector with
{{masterslave:(tcp://host1, tcp://host2)}}
> High CPU load when using failover transport in network connector
>
>
> Key: AMQ-5605
> URL: https://issues.apache.org/jira/browse/AMQ-5605
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.11.0, 5.11.1
> Environment: Ubuntu 14.04, SuSE Enterprise 11.3
>Reporter: Lars Neumann
> Labels: failover
> Fix For: 5.12.0, 5.11.3
>
>
> I've got a configuration with two master/slave setups consisting of 3
> ActiveMQ instances each. They are deployed on three servers, with one
> ActiveMQ instance from each master/slave setup on every server. They are
> using the leveldb and zookeeper. Everything works fine.
> Now I've got the strange behaviour that when I add a network connector to
> each ActiveMQ instance like this:
> {code}
> networkConnector name="toMasterSlave02" dynamicOnly="true"
> uri="masterslave:(tcp://host1:61617,tcp://host2:61617,tcp://host3:61617)"
> {code}
> When you now restart the master of the master/slave setup that is targeted by
> the above network connector the cpu load on the current master goes and stays
> up at 100%, i.e. it uses one CPU per configured transportConnector.
> Now the explanation, mostly copied from
> http://activemq.2283324.n4.nabble.com/High-CPU-load-with-network-connector-failover-transport-tp4691798.html
> {quote}
> When one of the brokers is restarted, the other broker uses ~400% CPU. The
> cause is the FailoverTransport reconnectTask spinning, and nothing is
> stopping the task.
> Reverting this fix made for AMQ-5315, while it does reintroduce the
> NullPointerException, does handle failover properly without spinning:
> https://git1-us-west.apache.org/repos/asf/activemq/repo?p=activemq.git;a=commitdiff;h=c391321d1b5b59542d847717654b0d4dba54cf2f
>
>
> The reason it works after reverting that change is the NullPointerException
> is caught, -> serviceLocalException() ->
> ServiceSupport.dispose(getControllingService()); with the fix made in
> AMQ-5315, the dispose() call is never made.
> {quote}
> Sorry, but I've got no clue how to provide a unit test for this. Maybe
> someone else can help.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5742) Destination dispatched count statistic not reflecting redelivery/redispatch
[ https://issues.apache.org/jira/browse/AMQ-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15167190#comment-15167190 ] ruffp commented on AMQ-5742: [~gtully] Because it seems the message queue counters are sometimes desynchronized on our AMQ, is it possible that bug is also present in version 5.10.2? > Destination dispatched count statistic not reflecting redelivery/redispatch > --- > > Key: AMQ-5742 > URL: https://issues.apache.org/jira/browse/AMQ-5742 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: dispatchedCount, jmx, statistics > Fix For: 5.11.2, 5.12.0 > > > Tracking down in intermittent failure of > org.apache.activemq.network.DemandForwardingBridgeTest.testSendThenAddConsumer > the problem turned out to be a decrement of the dispatched count when the > consumer was removed. > So before the removal, most of the time, the stat was 1, and the test passed. > But if the removal was complete, the dispatched count was decremented in > error by the unacked message count. This is wrong. The dispatched stat needs > to reflect what happened :-) Otherwise it tracks the dequeue count. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
