[jira] [Commented] (ARTEMIS-1930) Durable subscription deleted even without durable-subscription-name (STOMP)
[
https://issues.apache.org/jira/browse/ARTEMIS-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516690#comment-16516690
]
Lionel Cons commented on ARTEMIS-1930:
--
See the attached file: the first part subscribes (durably), then messages are
sent, then another client subscribes but do not receive any messages.
> Durable subscription deleted even without durable-subscription-name (STOMP)
> ---
>
> Key: ARTEMIS-1930
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1930
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
> Attachments: ARTEMIS-1930.text
>
>
> The STOMP documentation contains:
> {quote}
> To delete a durable subscription the client-id header must be set on the
> CONNECT frame and the durable-subscription-name must be set on the
> UNSUBSCRIBE frame. The values for these headers should match what was set on
> the SUBSCRIBE frame to delete the corresponding durable subscription.
> {quote}
> This is not what happens in practice.
> By specifying the subscription {{id}} (see
> https://stomp.github.io/stomp-specification-1.2.html#SUBSCRIBE_id_Header) the
> {{UNSUBSCRIBE}} frame does delete the durable subscription even without the
> {{durable-subscription-name}} header.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1930) Durable subscription deleted even without durable-subscription-name (STOMP)
[
https://issues.apache.org/jira/browse/ARTEMIS-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lionel Cons updated ARTEMIS-1930:
-
Attachment: ARTEMIS-1930.text
> Durable subscription deleted even without durable-subscription-name (STOMP)
> ---
>
> Key: ARTEMIS-1930
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1930
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
> Attachments: ARTEMIS-1930.text
>
>
> The STOMP documentation contains:
> {quote}
> To delete a durable subscription the client-id header must be set on the
> CONNECT frame and the durable-subscription-name must be set on the
> UNSUBSCRIBE frame. The values for these headers should match what was set on
> the SUBSCRIBE frame to delete the corresponding durable subscription.
> {quote}
> This is not what happens in practice.
> By specifying the subscription {{id}} (see
> https://stomp.github.io/stomp-specification-1.2.html#SUBSCRIBE_id_Header) the
> {{UNSUBSCRIBE}} frame does delete the durable subscription even without the
> {{durable-subscription-name}} header.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1939) Remove space from parameter annotations name in ActiveMQServerControl
[
https://issues.apache.org/jira/browse/ARTEMIS-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516677#comment-16516677
]
ASF GitHub Bot commented on ARTEMIS-1939:
-
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2146
@clebertsuconic its a point that if its changing a public exposed api which
jmx is then is the change back compatible. As existing users will/could have
code hooked in for monitoring or other reasons
> Remove space from parameter annotations name in ActiveMQServerControl
> -
>
> Key: ARTEMIS-1939
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1939
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.6.1
>Reporter: Shailendra Kumar singh
>Priority: Major
> Fix For: 2.7.0, 2.6.2
>
> Attachments: Console_JMX_error.png
>
>
> Some operations in ActiveMQServerControl have space in Parameter annotations
> name which breaks webconsole with below error
> {code:java}
> Error: Syntax Error: Token 'Number' is an unexpected token at column 13 of
> the expression [entity.Page Number] starting at [Number].
> Stack trace:
> Error: Syntax Error: Token 'Number' is an unexpected token at column 13 of
> the expression [entity.Page Number] starting at [Number].
> {code}
> Attached screen-shot
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1918) RemotingConnectionImpl contains unused private clientID field used by toString()
[ https://issues.apache.org/jira/browse/ARTEMIS-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-1918: - Issue Type: Task (was: Bug) > RemotingConnectionImpl contains unused private clientID field used by > toString() > > > Key: ARTEMIS-1918 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1918 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker >Affects Versions: 2.6.1 >Reporter: Johan Stenberg >Priority: Minor > Fix For: 2.7.0 > > > The > [RemotingConnectionImpl|https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/RemotingConnectionImpl.java#L79] > declares a private field clientID that is never set but used by the > toString() method. The base class > [AbstractRemotingConnection|https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/spi/core/protocol/AbstractRemotingConnection.java#L47] > already declares a private field clientId with appropriate setters. Setting > the cliendID value via this setter on the RemotingConnectionImpl is not > reflected by it's string representation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1918) RemotingConnectionImpl contains unused private clientID field used by toString()
[ https://issues.apache.org/jira/browse/ARTEMIS-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-1918. Resolution: Fixed Fix Version/s: 2.7.0 > RemotingConnectionImpl contains unused private clientID field used by > toString() > > > Key: ARTEMIS-1918 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1918 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker >Affects Versions: 2.6.1 >Reporter: Johan Stenberg >Priority: Minor > Fix For: 2.7.0 > > > The > [RemotingConnectionImpl|https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/RemotingConnectionImpl.java#L79] > declares a private field clientID that is never set but used by the > toString() method. The base class > [AbstractRemotingConnection|https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/spi/core/protocol/AbstractRemotingConnection.java#L47] > already declares a private field clientId with appropriate setters. Setting > the cliendID value via this setter on the RemotingConnectionImpl is not > reflected by it's string representation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1926) Refactor SSLSupport
[
https://issues.apache.org/jira/browse/ARTEMIS-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated ARTEMIS-1926:
-
Fix Version/s: 2.7.0
Issue Type: Task (was: Improvement)
> Refactor SSLSupport
> ---
>
> Key: ARTEMIS-1926
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1926
> Project: ActiveMQ Artemis
> Issue Type: Task
>Affects Versions: 2.6.1
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.7.0
>
>
> {{org.apache.activemq.artemis.core.remoting.impl.ssl.SSLSupport}} has
> ballooned in recent months with several additional options. These new
> options have required additional constructors and the existing constructors
> were already a bit clumsy to use because for simple use-cases they required
> passing in multiple default values. This class can be greatly simplified by
> adding properties, giving those properties reasonable defaults, and removing
> most of the static methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1917) Support logging HTTP access
[ https://issues.apache.org/jira/browse/ARTEMIS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-1917: - Fix Version/s: 2.7.0 > Support logging HTTP access > --- > > Key: ARTEMIS-1917 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1917 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.7.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1926) Refactor SSLSupport
[
https://issues.apache.org/jira/browse/ARTEMIS-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic closed ARTEMIS-1926.
Resolution: Fixed
> Refactor SSLSupport
> ---
>
> Key: ARTEMIS-1926
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1926
> Project: ActiveMQ Artemis
> Issue Type: Task
>Affects Versions: 2.6.1
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.7.0
>
>
> {{org.apache.activemq.artemis.core.remoting.impl.ssl.SSLSupport}} has
> ballooned in recent months with several additional options. These new
> options have required additional constructors and the existing constructors
> were already a bit clumsy to use because for simple use-cases they required
> passing in multiple default values. This class can be greatly simplified by
> adding properties, giving those properties reasonable defaults, and removing
> most of the static methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1917) Support logging HTTP access
[ https://issues.apache.org/jira/browse/ARTEMIS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516636#comment-16516636 ] ASF GitHub Bot commented on ARTEMIS-1917: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2129 > Support logging HTTP access > --- > > Key: ARTEMIS-1917 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1917 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (ARTEMIS-1916) Remove Jmx ArtemisRMIServerSocketFactory
[ https://issues.apache.org/jira/browse/ARTEMIS-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic reopened ARTEMIS-1916: -- > Remove Jmx ArtemisRMIServerSocketFactory > > > Key: ARTEMIS-1916 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1916 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.6.1 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.7.0 > > > The ArtemisRMIServerSocketFactory doesn't do anything special, instead the > existence of this impl class causes jmx client failed to connect (for reason > not known, probably not fully implemented the functionality). It turns out > just fine to use JDK's impl. This class is not necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1916) Remove Jmx ArtemisRMIServerSocketFactory
[ https://issues.apache.org/jira/browse/ARTEMIS-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-1916: - Fix Version/s: (was: 2.6.2) 2.7.0 > Remove Jmx ArtemisRMIServerSocketFactory > > > Key: ARTEMIS-1916 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1916 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.6.1 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.7.0 > > > The ArtemisRMIServerSocketFactory doesn't do anything special, instead the > existence of this impl class causes jmx client failed to connect (for reason > not known, probably not fully implemented the functionality). It turns out > just fine to use JDK's impl. This class is not necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1943) Removing core specific attributes from broker
[ https://issues.apache.org/jira/browse/ARTEMIS-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-1943. Resolution: Fixed > Removing core specific attributes from broker > - > > Key: ARTEMIS-1943 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1943 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.0, 2.6.1 >Reporter: clebert suconic >Assignee: Justin Bertram >Priority: Major > Fix For: 2.7.0, 2.6.2 > > > some properties were added in top of ARTEMIS-1819.. this is reverting those > changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ARTEMIS-1928) Message redistribution + AMQP causes NPE
[
https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516485#comment-16516485
]
Simon Chalmers edited comment on ARTEMIS-1928 at 6/19/18 12:19 AM:
---
Using the 2.6.2 release from here:
https://github.com/apache/activemq-artemis/releases/tag/2.6.2
Same NPE thrown:
{noformat}
2018-06-19 00:16:50,403 WARN [org.apache.activemq.artemis.core.server]
AMQ222151: removing consumer which did not handle a message,
consumer=ServerConsumerImpl [id=0, filter=null, binding=LocalQueueBinding
[address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks,
queue=QueueImpl[name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::serverUUID=41d444d1-7353-11e8-aacc-0204cf8299ac],
temp=false]@3bc2334a, filter=null,
name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks,
clusterName=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks41d444d1-7353-11e8-aacc-0204cf8299ac]],
message=Reference[191]:NON-RELIABLE:LargeServerMessage[messageID=191,durable=false,userID=null,priority=0,
timestamp=0,expiration=0, durable=false,
address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks,
properties=TypedProperties[_AMQ_LARGE_SIZE=258279]]@1904620054:
java.lang.IllegalStateException: Can't deliver message
java.lang.NullPointerException
at
org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:652)
[artemis-amqp-protocol-2.6.2.jar:]
at
org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1106)
[artemis-server-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:464)
[artemis-server-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:2938)
[artemis-server-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2406)
[artemis-server-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.core.server.impl.QueueImpl.access$2000(QueueImpl.java:107)
[artemis-server-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:3211)
[artemis-server-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
[artemis-commons-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
[artemis-commons-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
[artemis-commons-2.6.2.jar:2.6.2]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[rt.jar:1.8.0_171]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[rt.jar:1.8.0_171]
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
[artemis-commons-2.6.2.jar:2.6.2]
Caused by: java.lang.NullPointerException
at
org.apache.activemq.artemis.core.message.impl.CoreMessage.internalWritableBuffer(CoreMessage.java:360)
[artemis-core-client-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.core.message.impl.CoreMessage.getBodyBuffer(CoreMessage.java:353)
[artemis-core-client-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.convertBody(CoreAmqpConverter.java:384)
[artemis-amqp-protocol-2.6.2.jar:]
at
org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:126)
[artemis-amqp-protocol-2.6.2.jar:]
at
org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.checkAMQP(CoreAmqpConverter.java:106)
[artemis-amqp-protocol-2.6.2.jar:]
at
org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.deliverMessage(ProtonServerSenderContext.java:681)
[artemis-amqp-protocol-2.6.2.jar:]
at
org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:643)
[artemis-amqp-protocol-2.6.2.jar:]
... 12 more
2018-06-19 00:16:50,425 WARN [org.apache.activemq.artemis.core.server]
AMQ222151: removing consumer which did not handle a message,
consumer=ServerConsumerImpl [id=1, filter=null, binding=LocalQueueBinding
[jira] [Commented] (ARTEMIS-1928) Message redistribution + AMQP causes NPE
[ https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516485#comment-16516485 ] Simon Chalmers commented on ARTEMIS-1928: - Using the 2.6.2 release from here: https://github.com/apache/activemq-artemis/releases/tag/2.6.2 Same NPE thrown: 2018-06-19 00:16:50,403 WARN [org.apache.activemq.artemis.core.server] AMQ222151: removing consumer which did not handle a message, consumer=ServerConsumerImpl [id=0, filter=null, binding=LocalQueueBinding [address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks, queue=QueueImpl[name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=41d444d1-7353-11e8-aacc-0204cf8299ac], temp=false]@3bc2334a, filter=null, name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks, clusterName=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks41d444d1-7353-11e8-aacc-0204cf8299ac]], message=Reference[191]:NON-RELIABLE:LargeServerMessage[messageID=191,durable=false,userID=null,priority=0, timestamp=0,expiration=0, durable=false, address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks, properties=TypedProperties[_AMQ_LARGE_SIZE=258279]]@1904620054: java.lang.IllegalStateException: Can't deliver message java.lang.NullPointerException at org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:652) [artemis-amqp-protocol-2.6.2.jar:] at org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1106) [artemis-server-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:464) [artemis-server-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:2938) [artemis-server-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2406) [artemis-server-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.core.server.impl.QueueImpl.access$2000(QueueImpl.java:107) [artemis-server-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:3211) [artemis-server-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.6.2.jar:2.6.2] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171] at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.6.2.jar:2.6.2] Caused by: java.lang.NullPointerException at org.apache.activemq.artemis.core.message.impl.CoreMessage.internalWritableBuffer(CoreMessage.java:360) [artemis-core-client-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.core.message.impl.CoreMessage.getBodyBuffer(CoreMessage.java:353) [artemis-core-client-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.convertBody(CoreAmqpConverter.java:384) [artemis-amqp-protocol-2.6.2.jar:] at org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:126) [artemis-amqp-protocol-2.6.2.jar:] at org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.checkAMQP(CoreAmqpConverter.java:106) [artemis-amqp-protocol-2.6.2.jar:] at org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.deliverMessage(ProtonServerSenderContext.java:681) [artemis-amqp-protocol-2.6.2.jar:] at org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:643) [artemis-amqp-protocol-2.6.2.jar:] ... 12 more 2018-06-19 00:16:50,425 WARN [org.apache.activemq.artemis.core.server] AMQ222151: removing consumer which did not handle a message, consumer=ServerConsumerImpl [id=1, filter=null, binding=LocalQueueBinding [address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
[jira] [Updated] (ARTEMIS-1920) AMQP throws NPE if connection happens after a cluster restart
[ https://issues.apache.org/jira/browse/ARTEMIS-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-1920: - Affects Version/s: 2.6.0 2.6.1 Fix Version/s: 2.6.2 2.7.0 > AMQP throws NPE if connection happens after a cluster restart > - > > Key: ARTEMIS-1920 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1920 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.0, 2.6.1 >Reporter: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1935) Openwire connection logs failures on close for open sessions
[ https://issues.apache.org/jira/browse/ARTEMIS-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-1935. > Openwire connection logs failures on close for open sessions > > > Key: ARTEMIS-1935 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1935 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.6.1 >Reporter: Benjamin Graf >Priority: Major > Fix For: 2.7.0, 2.6.2 > > > Openwire implementation acts different to core protocoll and ActiveMQ > OpenWire implementation. Actually only internal sessions are automatically > closed with connection. This causes the same urgly warning messages as > resolved in ARTEMIS-1768. According to the JavaDoc of ActiveMQConnection it > should close all open sessions not only internal ones. This would avoid the > warning log messages at all. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1920) AMQP throws NPE if connection happens after a cluster restart
[ https://issues.apache.org/jira/browse/ARTEMIS-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-1920. Resolution: Fixed > AMQP throws NPE if connection happens after a cluster restart > - > > Key: ARTEMIS-1920 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1920 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.0, 2.6.1 >Reporter: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1900) Race condition in STOMP auto-create causing errors (AMQ339016+AMQ119017)
[
https://issues.apache.org/jira/browse/ARTEMIS-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic closed ARTEMIS-1900.
> Race condition in STOMP auto-create causing errors (AMQ339016+AMQ119017)
>
>
> Key: ARTEMIS-1900
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1900
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: STOMP
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.7.0, 2.6.2
>
> Attachments: ARTEMIS-1900.pl
>
>
> When stress testing Artemis (latest snapshot) using STOMP, I sometimes see
> subscription creation errors (AMQ339016). This is not reproducible so this is
> probably a concurrency issue.
> The STOMP client receives an {{ERROR}} frame that contains in its {{message}}
> header:
> {code}
> AMQ339016 Error creating subscription xyz
> {code}
> and in its body:
> {code}
> AMQ119017: Queue abc does not exist.
> {code}
> Also, this error is only sent to the client and not logged by the broker.
> IMHO, every time the broker reports a fatal client error (i.e. STOMP
> {{ERROR}} frame) it should also log this as a warning on its side. Let me
> know if this is specific to this case or if I should log a separate Jira
> issue to track this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1819) Missing fields on listAllConsumersAsJSON, listConsumersAsJSON and listConnectionsAsJSON
[ https://issues.apache.org/jira/browse/ARTEMIS-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516313#comment-16516313 ] clebert suconic commented on ARTEMIS-1819: -- Instead of reopening. I opened a new Jira on the next release... > Missing fields on listAllConsumersAsJSON, listConsumersAsJSON and > listConnectionsAsJSON > --- > > Key: ARTEMIS-1819 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1819 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.5.0 >Reporter: Ingo Weiss >Priority: Minor > Labels: regresion > Fix For: 2.6.0 > > > This is a regression against 1.5.5. Some fields are missing. On > listConsumersAsJSON and listAllConsumersAsJSON the fields are > destinationName, destinationType and durable. listConnectionsAsJSON is > missing clientID. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1917) Support logging HTTP access
[ https://issues.apache.org/jira/browse/ARTEMIS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516312#comment-16516312 ] ASF GitHub Bot commented on ARTEMIS-1917: - Github user jbertram commented on the issue: https://github.com/apache/activemq-artemis/pull/2129 This is just a way to enable logs for HTTP access. The logging is done on local disk, and there is no way to access the log from a remote client. > Support logging HTTP access > --- > > Key: ARTEMIS-1917 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1917 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1893) subscription queues for non-durable subscriptions are not deleted when AMQP links are detached
[
https://issues.apache.org/jira/browse/ARTEMIS-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated ARTEMIS-1893:
-
Affects Version/s: 2.6.0
2.6.1
Fix Version/s: 2.6.2
2.7.0
> subscription queues for non-durable subscriptions are not deleted when AMQP
> links are detached
> --
>
> Key: ARTEMIS-1893
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1893
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.5.0, 2.6.0, 2.6.1
>Reporter: Keith Wall
>Priority: Major
> Fix For: 2.7.0, 2.6.2
>
> Attachments: artemis1893.py
>
>
> If an AMQP 1.0 peer attaches a link that will expire on {{link-detach}}, and
> then later detaches the link with a {{closed=false}}, as it makes no sense
> for the link ever to be attached again, the Broker ought to treat this as if
> {{closed=true}} and free any resources associated with the link and respond
> with a {{detach closed=true}}. This currently does not happen.
> This defect was exposed when testing EnMasse (with a standard address space).
> The application (using the Qpid JMS Client) had created non-durable topic
> subscriptions and was then disconnected ungracefully. The queues backing the
> subscription were seen to leak on the Broker.
> The protocol trace between Qpid Dispatch and the Broker follows ({{->}} =
> Dispatch to Broker):
> {noformat}
> [0x7f6acc051b10]:4 -> @attach(18)
> [name="qpid-jms:receiver:ID:ac75e7c3-e850-4a23-bb4f-4220dffa1dac:1:1:1:footopic2",
> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [address="footopic2", durable=0,
> expiry-policy=:"link-detach", timeout=0, dynamic=false,
> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> :"amqp:released:list", :"amqp:modified:list"],
> capabilities=@PN_SYMBOL[:topic]], target=@target(41) [durable=0, timeout=0,
> dynamic=false], initial-delivery-count=0, max-message-size=0]
> [0x7f6acc051b10]:4 <- @attach(18)
> [name="qpid-jms:receiver:ID:ac75e7c3-e850-4a23-bb4f-4220dffa1dac:1:1:1:footopic2",
> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [address="footopic2", durable=0,
> expiry-policy=:"link-detach", timeout=0, dynamic=false,
> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> :"amqp:released:list", :"amqp:modified:list"],
> capabilities=@PN_SYMBOL[:topic]], target=@target(41) [durable=0, timeout=0,
> dynamic=false], initial-delivery-count=0, max-message-size=0]
> [0x7f6acc051b10]:4 -> @detach(22) [handle=0, closed=false, error=@error(29)
> [condition=:"qd:routed-link-lost", description="Connectivity to the peer
> container was lost"]]
> [0x7f6acc051b10]:4 <- @detach(22) [handle=0, closed=false]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1819) Missing fields on listAllConsumersAsJSON, listConsumersAsJSON and listConnectionsAsJSON
[ https://issues.apache.org/jira/browse/ARTEMIS-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-1819. Resolution: Fixed > Missing fields on listAllConsumersAsJSON, listConsumersAsJSON and > listConnectionsAsJSON > --- > > Key: ARTEMIS-1819 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1819 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.5.0 >Reporter: Ingo Weiss >Priority: Minor > Labels: regresion > Fix For: 2.6.0 > > > This is a regression against 1.5.5. Some fields are missing. On > listConsumersAsJSON and listAllConsumersAsJSON the fields are > destinationName, destinationType and durable. listConnectionsAsJSON is > missing clientID. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1893) subscription queues for non-durable subscriptions are not deleted when AMQP links are detached
[
https://issues.apache.org/jira/browse/ARTEMIS-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic closed ARTEMIS-1893.
Resolution: Fixed
> subscription queues for non-durable subscriptions are not deleted when AMQP
> links are detached
> --
>
> Key: ARTEMIS-1893
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1893
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.5.0, 2.6.0, 2.6.1
>Reporter: Keith Wall
>Priority: Major
> Fix For: 2.7.0, 2.6.2
>
> Attachments: artemis1893.py
>
>
> If an AMQP 1.0 peer attaches a link that will expire on {{link-detach}}, and
> then later detaches the link with a {{closed=false}}, as it makes no sense
> for the link ever to be attached again, the Broker ought to treat this as if
> {{closed=true}} and free any resources associated with the link and respond
> with a {{detach closed=true}}. This currently does not happen.
> This defect was exposed when testing EnMasse (with a standard address space).
> The application (using the Qpid JMS Client) had created non-durable topic
> subscriptions and was then disconnected ungracefully. The queues backing the
> subscription were seen to leak on the Broker.
> The protocol trace between Qpid Dispatch and the Broker follows ({{->}} =
> Dispatch to Broker):
> {noformat}
> [0x7f6acc051b10]:4 -> @attach(18)
> [name="qpid-jms:receiver:ID:ac75e7c3-e850-4a23-bb4f-4220dffa1dac:1:1:1:footopic2",
> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [address="footopic2", durable=0,
> expiry-policy=:"link-detach", timeout=0, dynamic=false,
> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> :"amqp:released:list", :"amqp:modified:list"],
> capabilities=@PN_SYMBOL[:topic]], target=@target(41) [durable=0, timeout=0,
> dynamic=false], initial-delivery-count=0, max-message-size=0]
> [0x7f6acc051b10]:4 <- @attach(18)
> [name="qpid-jms:receiver:ID:ac75e7c3-e850-4a23-bb4f-4220dffa1dac:1:1:1:footopic2",
> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [address="footopic2", durable=0,
> expiry-policy=:"link-detach", timeout=0, dynamic=false,
> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> :"amqp:released:list", :"amqp:modified:list"],
> capabilities=@PN_SYMBOL[:topic]], target=@target(41) [durable=0, timeout=0,
> dynamic=false], initial-delivery-count=0, max-message-size=0]
> [0x7f6acc051b10]:4 -> @detach(22) [handle=0, closed=false, error=@error(29)
> [condition=:"qd:routed-link-lost", description="Connectivity to the peer
> container was lost"]]
> [0x7f6acc051b10]:4 <- @detach(22) [handle=0, closed=false]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1927) Server is not disconnecting clients on connection reset by peer
[ https://issues.apache.org/jira/browse/ARTEMIS-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-1927. Resolution: Fixed > Server is not disconnecting clients on connection reset by peer > --- > > Key: ARTEMIS-1927 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1927 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.1 > Environment: This is specific to windows. if you close a connection > by CTRL-C a disconnect is not sent some times. > > The server could treat the exception thrown by netty accordingly. >Reporter: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1939) Remove space from parameter annotations name in ActiveMQServerControl
[
https://issues.apache.org/jira/browse/ARTEMIS-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic closed ARTEMIS-1939.
Resolution: Fixed
> Remove space from parameter annotations name in ActiveMQServerControl
> -
>
> Key: ARTEMIS-1939
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1939
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.6.1
>Reporter: Shailendra Kumar singh
>Priority: Major
> Fix For: 2.7.0, 2.6.2
>
> Attachments: Console_JMX_error.png
>
>
> Some operations in ActiveMQServerControl have space in Parameter annotations
> name which breaks webconsole with below error
> {code:java}
> Error: Syntax Error: Token 'Number' is an unexpected token at column 13 of
> the expression [entity.Page Number] starting at [Number].
> Stack trace:
> Error: Syntax Error: Token 'Number' is an unexpected token at column 13 of
> the expression [entity.Page Number] starting at [Number].
> {code}
> Attached screen-shot
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1939) Remove space from parameter annotations name in ActiveMQServerControl
[
https://issues.apache.org/jira/browse/ARTEMIS-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated ARTEMIS-1939:
-
Fix Version/s: 2.6.2
2.7.0
> Remove space from parameter annotations name in ActiveMQServerControl
> -
>
> Key: ARTEMIS-1939
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1939
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.6.1
>Reporter: Shailendra Kumar singh
>Priority: Major
> Fix For: 2.7.0, 2.6.2
>
> Attachments: Console_JMX_error.png
>
>
> Some operations in ActiveMQServerControl have space in Parameter annotations
> name which breaks webconsole with below error
> {code:java}
> Error: Syntax Error: Token 'Number' is an unexpected token at column 13 of
> the expression [entity.Page Number] starting at [Number].
> Stack trace:
> Error: Syntax Error: Token 'Number' is an unexpected token at column 13 of
> the expression [entity.Page Number] starting at [Number].
> {code}
> Attached screen-shot
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1934) the broker sends duplicate AMQP connection data in certain conditions
[ https://issues.apache.org/jira/browse/ARTEMIS-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-1934. Resolution: Fixed > the broker sends duplicate AMQP connection data in certain conditions > - > > Key: ARTEMIS-1934 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1934 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.5.0, 2.6.0, 2.6.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 2.7.0, 2.6.2 > > > The broker can write out some connection data twice in certain circumstances, > corrupting the connection data, due to the way it handles the proton-j > transport output and sending it out to Netty. It fails to 'pop' the correct > amount of data from the proton transport that was actually transmitted, > under-accounting the amount, which results in some of the data being sent a > second time the next time output is generated and sent. > The underlying bug has been present for quite some time, but other changes > from 2.6.0 onward change broker behaviour in ways that make it much more > likely to actually occur during real world usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1934) the broker sends duplicate AMQP connection data in certain conditions
[ https://issues.apache.org/jira/browse/ARTEMIS-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic updated ARTEMIS-1934: - Fix Version/s: 2.7.0 > the broker sends duplicate AMQP connection data in certain conditions > - > > Key: ARTEMIS-1934 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1934 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.5.0, 2.6.0, 2.6.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 2.7.0, 2.6.2 > > > The broker can write out some connection data twice in certain circumstances, > corrupting the connection data, due to the way it handles the proton-j > transport output and sending it out to Netty. It fails to 'pop' the correct > amount of data from the proton transport that was actually transmitted, > under-accounting the amount, which results in some of the data being sent a > second time the next time output is generated and sent. > The underlying bug has been present for quite some time, but other changes > from 2.6.0 onward change broker behaviour in ways that make it much more > likely to actually occur during real world usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (ARTEMIS-1934) the broker sends duplicate AMQP connection data in certain conditions
[ https://issues.apache.org/jira/browse/ARTEMIS-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic reopened ARTEMIS-1934: -- > the broker sends duplicate AMQP connection data in certain conditions > - > > Key: ARTEMIS-1934 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1934 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.5.0, 2.6.0, 2.6.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 2.7.0, 2.6.2 > > > The broker can write out some connection data twice in certain circumstances, > corrupting the connection data, due to the way it handles the proton-j > transport output and sending it out to Netty. It fails to 'pop' the correct > amount of data from the proton transport that was actually transmitted, > under-accounting the amount, which results in some of the data being sent a > second time the next time output is generated and sent. > The underlying bug has been present for quite some time, but other changes > from 2.6.0 onward change broker behaviour in ways that make it much more > likely to actually occur during real world usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1942) LDAP Configuration is missing
[ https://issues.apache.org/jira/browse/ARTEMIS-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-1942. Resolution: Fixed > LDAP Configuration is missing > - > > Key: ARTEMIS-1942 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1942 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.0 >Reporter: clebert suconic >Assignee: Gary Tully >Priority: Major > Fix For: 2.7.0, 2.6.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (ARTEMIS-1940) premature release of pooled buffers during send can cause AMQP connection failures
[
https://issues.apache.org/jira/browse/ARTEMIS-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic reopened ARTEMIS-1940:
--
> premature release of pooled buffers during send can cause AMQP connection
> failures
> --
>
> Key: ARTEMIS-1940
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1940
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.6.0, 2.6.1
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 2.7.0, 2.6.2
>
>
> When sending messages over AMQP connections to consumers, in certain cases
> the broker can prematurely release a pooled buffer before the message send
> process has completed using it. When attempt is made to send more data for
> the message later on the process fails since the buffer is no longer valid,
> per stacktrace below.
> The issue is that the broker assumes the send is entirely complete after
> pumping the proton transport, but there are cases where that may not yet be
> the case, perhaps leading to this issue. Most sends are not affected by the
> issue at all, but some such as for redelivered messages can be due to their
> use of pooled buffers.
> To address the issue for now, cases where the pooled buffers are being used
> should revert to the older copying send methods of proton, while the
> remainder continue to use the newer send methods that directly use the
> provided buffer (which is often just going to be the one created when the
> message arrived at the broker).
> {noformat}
> Thread-1 (activemq-netty-threads)] 18:49:34,857 WARN
> [org.apache.activemq.artemis.core.server] AMQ18: Server disconnecting:
> Error decoding buffer: io.netty.util.IllegalReferenceCountException: refCnt: 0
> at
> io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1417)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at io.netty.buffer.PooledHeapByteBuf.array(PooledHeapByteBuf.java:318)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.util.NettyReadable.get(NettyReadable.java:211)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.qpid.proton.codec.WritableBuffer$ByteBufferWrapper.put(WritableBuffer.java:140)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.FrameWriter.writeFrame(FrameWriter.java:180)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeFrame(TransportImpl.java:1075)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWorkSender(TransportImpl.java:599)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWork(TransportImpl.java:518)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeInto(TransportImpl.java:347)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.pending(TransportOutputAdaptor.java:59)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.head(TransportOutputAdaptor.java:80)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.SaslImpl$SwitchingSaslTransportWrapper.head(SaslImpl.java:820)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.HandshakeSniffingTransportWrapper.head(HandshakeSniffingTransportWrapper.java:151)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.head(TransportImpl.java:1533)
> [proton-j-0.27.1.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flushBytes(ProtonHandler.java:212)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:516)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:307)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.inputBuffer(ProtonHandler.java:272)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.inputBuffer(AMQPConnectionContext.java:158)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:147)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
>
[jira] [Closed] (ARTEMIS-1940) premature release of pooled buffers during send can cause AMQP connection failures
[
https://issues.apache.org/jira/browse/ARTEMIS-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic closed ARTEMIS-1940.
Resolution: Fixed
> premature release of pooled buffers during send can cause AMQP connection
> failures
> --
>
> Key: ARTEMIS-1940
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1940
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.6.0, 2.6.1
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 2.7.0, 2.6.2
>
>
> When sending messages over AMQP connections to consumers, in certain cases
> the broker can prematurely release a pooled buffer before the message send
> process has completed using it. When attempt is made to send more data for
> the message later on the process fails since the buffer is no longer valid,
> per stacktrace below.
> The issue is that the broker assumes the send is entirely complete after
> pumping the proton transport, but there are cases where that may not yet be
> the case, perhaps leading to this issue. Most sends are not affected by the
> issue at all, but some such as for redelivered messages can be due to their
> use of pooled buffers.
> To address the issue for now, cases where the pooled buffers are being used
> should revert to the older copying send methods of proton, while the
> remainder continue to use the newer send methods that directly use the
> provided buffer (which is often just going to be the one created when the
> message arrived at the broker).
> {noformat}
> Thread-1 (activemq-netty-threads)] 18:49:34,857 WARN
> [org.apache.activemq.artemis.core.server] AMQ18: Server disconnecting:
> Error decoding buffer: io.netty.util.IllegalReferenceCountException: refCnt: 0
> at
> io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1417)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at io.netty.buffer.PooledHeapByteBuf.array(PooledHeapByteBuf.java:318)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.util.NettyReadable.get(NettyReadable.java:211)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.qpid.proton.codec.WritableBuffer$ByteBufferWrapper.put(WritableBuffer.java:140)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.FrameWriter.writeFrame(FrameWriter.java:180)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeFrame(TransportImpl.java:1075)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWorkSender(TransportImpl.java:599)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWork(TransportImpl.java:518)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeInto(TransportImpl.java:347)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.pending(TransportOutputAdaptor.java:59)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.head(TransportOutputAdaptor.java:80)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.SaslImpl$SwitchingSaslTransportWrapper.head(SaslImpl.java:820)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.HandshakeSniffingTransportWrapper.head(HandshakeSniffingTransportWrapper.java:151)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.head(TransportImpl.java:1533)
> [proton-j-0.27.1.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flushBytes(ProtonHandler.java:212)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:516)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:307)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.inputBuffer(ProtonHandler.java:272)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.inputBuffer(AMQPConnectionContext.java:158)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:147)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
>
[jira] [Closed] (ARTEMIS-1934) the broker sends duplicate AMQP connection data in certain conditions
[ https://issues.apache.org/jira/browse/ARTEMIS-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-1934. Resolution: Fixed > the broker sends duplicate AMQP connection data in certain conditions > - > > Key: ARTEMIS-1934 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1934 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.5.0, 2.6.0, 2.6.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 2.6.2 > > > The broker can write out some connection data twice in certain circumstances, > corrupting the connection data, due to the way it handles the proton-j > transport output and sending it out to Netty. It fails to 'pop' the correct > amount of data from the proton transport that was actually transmitted, > under-accounting the amount, which results in some of the data being sent a > second time the next time output is generated and sent. > The underlying bug has been present for quite some time, but other changes > from 2.6.0 onward change broker behaviour in ways that make it much more > likely to actually occur during real world usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1940) premature release of pooled buffers during send can cause AMQP connection failures
[
https://issues.apache.org/jira/browse/ARTEMIS-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated ARTEMIS-1940:
-
Fix Version/s: 2.7.0
> premature release of pooled buffers during send can cause AMQP connection
> failures
> --
>
> Key: ARTEMIS-1940
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1940
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.6.0, 2.6.1
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 2.7.0, 2.6.2
>
>
> When sending messages over AMQP connections to consumers, in certain cases
> the broker can prematurely release a pooled buffer before the message send
> process has completed using it. When attempt is made to send more data for
> the message later on the process fails since the buffer is no longer valid,
> per stacktrace below.
> The issue is that the broker assumes the send is entirely complete after
> pumping the proton transport, but there are cases where that may not yet be
> the case, perhaps leading to this issue. Most sends are not affected by the
> issue at all, but some such as for redelivered messages can be due to their
> use of pooled buffers.
> To address the issue for now, cases where the pooled buffers are being used
> should revert to the older copying send methods of proton, while the
> remainder continue to use the newer send methods that directly use the
> provided buffer (which is often just going to be the one created when the
> message arrived at the broker).
> {noformat}
> Thread-1 (activemq-netty-threads)] 18:49:34,857 WARN
> [org.apache.activemq.artemis.core.server] AMQ18: Server disconnecting:
> Error decoding buffer: io.netty.util.IllegalReferenceCountException: refCnt: 0
> at
> io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1417)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at io.netty.buffer.PooledHeapByteBuf.array(PooledHeapByteBuf.java:318)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.util.NettyReadable.get(NettyReadable.java:211)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.qpid.proton.codec.WritableBuffer$ByteBufferWrapper.put(WritableBuffer.java:140)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.FrameWriter.writeFrame(FrameWriter.java:180)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeFrame(TransportImpl.java:1075)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWorkSender(TransportImpl.java:599)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWork(TransportImpl.java:518)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeInto(TransportImpl.java:347)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.pending(TransportOutputAdaptor.java:59)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.head(TransportOutputAdaptor.java:80)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.SaslImpl$SwitchingSaslTransportWrapper.head(SaslImpl.java:820)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.HandshakeSniffingTransportWrapper.head(HandshakeSniffingTransportWrapper.java:151)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.head(TransportImpl.java:1533)
> [proton-j-0.27.1.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flushBytes(ProtonHandler.java:212)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:516)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:307)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.inputBuffer(ProtonHandler.java:272)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.inputBuffer(AMQPConnectionContext.java:158)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:147)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
>
[jira] [Closed] (ARTEMIS-1940) premature release of pooled buffers during send can cause AMQP connection failures
[
https://issues.apache.org/jira/browse/ARTEMIS-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic closed ARTEMIS-1940.
Resolution: Fixed
> premature release of pooled buffers during send can cause AMQP connection
> failures
> --
>
> Key: ARTEMIS-1940
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1940
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.6.0, 2.6.1
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 2.6.2
>
>
> When sending messages over AMQP connections to consumers, in certain cases
> the broker can prematurely release a pooled buffer before the message send
> process has completed using it. When attempt is made to send more data for
> the message later on the process fails since the buffer is no longer valid,
> per stacktrace below.
> The issue is that the broker assumes the send is entirely complete after
> pumping the proton transport, but there are cases where that may not yet be
> the case, perhaps leading to this issue. Most sends are not affected by the
> issue at all, but some such as for redelivered messages can be due to their
> use of pooled buffers.
> To address the issue for now, cases where the pooled buffers are being used
> should revert to the older copying send methods of proton, while the
> remainder continue to use the newer send methods that directly use the
> provided buffer (which is often just going to be the one created when the
> message arrived at the broker).
> {noformat}
> Thread-1 (activemq-netty-threads)] 18:49:34,857 WARN
> [org.apache.activemq.artemis.core.server] AMQ18: Server disconnecting:
> Error decoding buffer: io.netty.util.IllegalReferenceCountException: refCnt: 0
> at
> io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1417)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at io.netty.buffer.PooledHeapByteBuf.array(PooledHeapByteBuf.java:318)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.util.NettyReadable.get(NettyReadable.java:211)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.qpid.proton.codec.WritableBuffer$ByteBufferWrapper.put(WritableBuffer.java:140)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.FrameWriter.writeFrame(FrameWriter.java:180)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeFrame(TransportImpl.java:1075)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWorkSender(TransportImpl.java:599)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWork(TransportImpl.java:518)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeInto(TransportImpl.java:347)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.pending(TransportOutputAdaptor.java:59)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.head(TransportOutputAdaptor.java:80)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.SaslImpl$SwitchingSaslTransportWrapper.head(SaslImpl.java:820)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.HandshakeSniffingTransportWrapper.head(HandshakeSniffingTransportWrapper.java:151)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.head(TransportImpl.java:1533)
> [proton-j-0.27.1.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flushBytes(ProtonHandler.java:212)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:516)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:307)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.inputBuffer(ProtonHandler.java:272)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.inputBuffer(AMQPConnectionContext.java:158)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:147)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
>
[jira] [Commented] (ARTEMIS-1917) Support logging HTTP access
[ https://issues.apache.org/jira/browse/ARTEMIS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516304#comment-16516304 ] ASF GitHub Bot commented on ARTEMIS-1917: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2129 I'm confused.. if you access the web with /requestLogs you will have the output of the server logs? isn't that dangerous? is there any security concern? > Support logging HTTP access > --- > > Key: ARTEMIS-1917 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1917 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1918) RemotingConnectionImpl contains unused private clientID field used by toString()
[ https://issues.apache.org/jira/browse/ARTEMIS-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516303#comment-16516303 ] ASF GitHub Bot commented on ARTEMIS-1918: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2130 > RemotingConnectionImpl contains unused private clientID field used by > toString() > > > Key: ARTEMIS-1918 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1918 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.1 >Reporter: Johan Stenberg >Priority: Minor > > The > [RemotingConnectionImpl|https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/RemotingConnectionImpl.java#L79] > declares a private field clientID that is never set but used by the > toString() method. The base class > [AbstractRemotingConnection|https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/spi/core/protocol/AbstractRemotingConnection.java#L47] > already declares a private field clientId with appropriate setters. Setting > the cliendID value via this setter on the RemotingConnectionImpl is not > reflected by it's string representation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1926) Refactor SSLSupport
[
https://issues.apache.org/jira/browse/ARTEMIS-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516302#comment-16516302
]
ASF GitHub Bot commented on ARTEMIS-1926:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2138
> Refactor SSLSupport
> ---
>
> Key: ARTEMIS-1926
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1926
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 2.6.1
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> {{org.apache.activemq.artemis.core.remoting.impl.ssl.SSLSupport}} has
> ballooned in recent months with several additional options. These new
> options have required additional constructors and the existing constructors
> were already a bit clumsy to use because for simple use-cases they required
> passing in multiple default values. This class can be greatly simplified by
> adding properties, giving those properties reasonable defaults, and removing
> most of the static methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARTEMIS-1943) Removing core specific attributes from broker
clebert suconic created ARTEMIS-1943: Summary: Removing core specific attributes from broker Key: ARTEMIS-1943 URL: https://issues.apache.org/jira/browse/ARTEMIS-1943 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.6.1, 2.6.0 Reporter: clebert suconic Assignee: Justin Bertram Fix For: 2.7.0, 2.6.2 some properties were added in top of ARTEMIS-1819.. this is reverting those changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1819) Missing fields on listAllConsumersAsJSON, listConsumersAsJSON and listConnectionsAsJSON
[ https://issues.apache.org/jira/browse/ARTEMIS-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516294#comment-16516294 ] ASF GitHub Bot commented on ARTEMIS-1819: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2136 > Missing fields on listAllConsumersAsJSON, listConsumersAsJSON and > listConnectionsAsJSON > --- > > Key: ARTEMIS-1819 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1819 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.5.0 >Reporter: Ingo Weiss >Priority: Minor > Labels: regresion > Fix For: 2.6.0 > > > This is a regression against 1.5.5. Some fields are missing. On > listConsumersAsJSON and listAllConsumersAsJSON the fields are > destinationName, destinationType and durable. listConnectionsAsJSON is > missing clientID. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1939) Remove space from parameter annotations name in ActiveMQServerControl
[
https://issues.apache.org/jira/browse/ARTEMIS-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516289#comment-16516289
]
ASF GitHub Bot commented on ARTEMIS-1939:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2146
> Remove space from parameter annotations name in ActiveMQServerControl
> -
>
> Key: ARTEMIS-1939
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1939
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.6.1
>Reporter: Shailendra Kumar singh
>Priority: Major
> Attachments: Console_JMX_error.png
>
>
> Some operations in ActiveMQServerControl have space in Parameter annotations
> name which breaks webconsole with below error
> {code:java}
> Error: Syntax Error: Token 'Number' is an unexpected token at column 13 of
> the expression [entity.Page Number] starting at [Number].
> Stack trace:
> Error: Syntax Error: Token 'Number' is an unexpected token at column 13 of
> the expression [entity.Page Number] starting at [Number].
> {code}
> Attached screen-shot
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1939) Remove space from parameter annotations name in ActiveMQServerControl
[
https://issues.apache.org/jira/browse/ARTEMIS-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516287#comment-16516287
]
ASF GitHub Bot commented on ARTEMIS-1939:
-
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/2146
I already saw it...
will merge it and bring it into 2.6.x
> Remove space from parameter annotations name in ActiveMQServerControl
> -
>
> Key: ARTEMIS-1939
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1939
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.6.1
>Reporter: Shailendra Kumar singh
>Priority: Major
> Attachments: Console_JMX_error.png
>
>
> Some operations in ActiveMQServerControl have space in Parameter annotations
> name which breaks webconsole with below error
> {code:java}
> Error: Syntax Error: Token 'Number' is an unexpected token at column 13 of
> the expression [entity.Page Number] starting at [Number].
> Stack trace:
> Error: Syntax Error: Token 'Number' is an unexpected token at column 13 of
> the expression [entity.Page Number] starting at [Number].
> {code}
> Attached screen-shot
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1939) Remove space from parameter annotations name in ActiveMQServerControl
[
https://issues.apache.org/jira/browse/ARTEMIS-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516286#comment-16516286
]
ASF GitHub Bot commented on ARTEMIS-1939:
-
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/2146
it's just changing the parameter name.. why is this an issue?
> Remove space from parameter annotations name in ActiveMQServerControl
> -
>
> Key: ARTEMIS-1939
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1939
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.6.1
>Reporter: Shailendra Kumar singh
>Priority: Major
> Attachments: Console_JMX_error.png
>
>
> Some operations in ActiveMQServerControl have space in Parameter annotations
> name which breaks webconsole with below error
> {code:java}
> Error: Syntax Error: Token 'Number' is an unexpected token at column 13 of
> the expression [entity.Page Number] starting at [Number].
> Stack trace:
> Error: Syntax Error: Token 'Number' is an unexpected token at column 13 of
> the expression [entity.Page Number] starting at [Number].
> {code}
> Attached screen-shot
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1931) Create a Camel example
[ https://issues.apache.org/jira/browse/ARTEMIS-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516282#comment-16516282 ] ASF GitHub Bot commented on ARTEMIS-1931: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2140 > Create a Camel example > --- > > Key: ARTEMIS-1931 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1931 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > > Camel is a common component leveraged by users. It would be good to have an > example demonstrating how to use Camel and the broker in the same JVM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1941) broker changes AMQP body section type during 'Large' message handling
[ https://issues.apache.org/jira/browse/ARTEMIS-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516275#comment-16516275 ] Timothy Bish commented on ARTEMIS-1941: --- The broker converters aren't preserving the message body type as is done in ActiveMQ 5.x so it just converts any Server side BytesMessage into an AmqpValue section body type. ActiveMQ 5 had similar issues which were resolved in AMQ-6374. > broker changes AMQP body section type during 'Large' message handling > - > > Key: ARTEMIS-1941 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1941 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.6.1 >Reporter: Robbie Gemmell >Priority: Major > > When the broker receives AMQP messages it considers those over a certain size > (currently the lower of journal file size and journal buffer size) to be a > 'large' message. In its handling of these, the message is essentially > converted internally to a Core message, and when sending the message to an > AMQP consumer, essentially gets converted back. During investigation of and > testing of ARTEMIS-1940 I noted that although my test sent in an AMQP Data > body section and so that is what should come back out, I instead received an > AMQP Value body section containing a binary value (with the same bytes). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (ARTEMIS-1940) premature release of pooled buffers during send can cause AMQP connection failures
[
https://issues.apache.org/jira/browse/ARTEMIS-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on ARTEMIS-1940 started by Robbie Gemmell.
---
> premature release of pooled buffers during send can cause AMQP connection
> failures
> --
>
> Key: ARTEMIS-1940
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1940
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.6.0, 2.6.1
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 2.6.2
>
>
> When sending messages over AMQP connections to consumers, in certain cases
> the broker can prematurely release a pooled buffer before the message send
> process has completed using it. When attempt is made to send more data for
> the message later on the process fails since the buffer is no longer valid,
> per stacktrace below.
> The issue is that the broker assumes the send is entirely complete after
> pumping the proton transport, but there are cases where that may not yet be
> the case, perhaps leading to this issue. Most sends are not affected by the
> issue at all, but some such as for redelivered messages can be due to their
> use of pooled buffers.
> To address the issue for now, cases where the pooled buffers are being used
> should revert to the older copying send methods of proton, while the
> remainder continue to use the newer send methods that directly use the
> provided buffer (which is often just going to be the one created when the
> message arrived at the broker).
> {noformat}
> Thread-1 (activemq-netty-threads)] 18:49:34,857 WARN
> [org.apache.activemq.artemis.core.server] AMQ18: Server disconnecting:
> Error decoding buffer: io.netty.util.IllegalReferenceCountException: refCnt: 0
> at
> io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1417)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at io.netty.buffer.PooledHeapByteBuf.array(PooledHeapByteBuf.java:318)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.util.NettyReadable.get(NettyReadable.java:211)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.qpid.proton.codec.WritableBuffer$ByteBufferWrapper.put(WritableBuffer.java:140)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.FrameWriter.writeFrame(FrameWriter.java:180)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeFrame(TransportImpl.java:1075)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWorkSender(TransportImpl.java:599)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWork(TransportImpl.java:518)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeInto(TransportImpl.java:347)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.pending(TransportOutputAdaptor.java:59)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.head(TransportOutputAdaptor.java:80)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.SaslImpl$SwitchingSaslTransportWrapper.head(SaslImpl.java:820)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.HandshakeSniffingTransportWrapper.head(HandshakeSniffingTransportWrapper.java:151)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.head(TransportImpl.java:1533)
> [proton-j-0.27.1.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flushBytes(ProtonHandler.java:212)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:516)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:307)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.inputBuffer(ProtonHandler.java:272)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.inputBuffer(AMQPConnectionContext.java:158)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:147)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
>
[jira] [Commented] (ARTEMIS-1941) broker changes AMQP body section type during 'Large' message handling
[ https://issues.apache.org/jira/browse/ARTEMIS-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516185#comment-16516185 ] Robbie Gemmell commented on ARTEMIS-1941: - Note for anyone looking later, the test for ARTEMIS-1940 added in https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=commit;h=ed2a18f1c49bc1f45a7978f01989fd4b253f0693 will require fixing when this issue stops being the case. > broker changes AMQP body section type during 'Large' message handling > - > > Key: ARTEMIS-1941 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1941 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.6.1 >Reporter: Robbie Gemmell >Priority: Major > > When the broker receives AMQP messages it considers those over a certain size > (currently the lower of journal file size and journal buffer size) to be a > 'large' message. In its handling of these, the message is essentially > converted internally to a Core message, and when sending the message to an > AMQP consumer, essentially gets converted back. During investigation of and > testing of ARTEMIS-1940 I noted that although my test sent in an AMQP Data > body section and so that is what should come back out, I instead received an > AMQP Value body section containing a binary value (with the same bytes). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1934) the broker sends duplicate AMQP connection data in certain conditions
[ https://issues.apache.org/jira/browse/ARTEMIS-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-1934: Description: The broker can write out some connection data twice in certain circumstances, corrupting the connection data, due to the way it handles the proton-j transport output and sending it out to Netty. It fails to 'pop' the correct amount of data from the proton transport that was actually transmitted, under-accounting the amount, which results in some of the data being sent a second time the next time output is generated and sent. The underlying bug has been present for quite some time, but other changes from 2.6.0 onward change broker behaviour in ways that make it much more likely to actually occur during real world usage. was:The broker can write out some connection data twice in certain circumstances, corrupting the connection data, due to the way it handles the proton-j transport output and sending it out to Netty. It fails to 'pop' the correct amount of data from the proton transport that was actually transmitted, underaccounting the amount, which results in some of the data being sent a second time the next time output is generated and sent. > the broker sends duplicate AMQP connection data in certain conditions > - > > Key: ARTEMIS-1934 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1934 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.5.0, 2.6.0, 2.6.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 2.6.2 > > > The broker can write out some connection data twice in certain circumstances, > corrupting the connection data, due to the way it handles the proton-j > transport output and sending it out to Netty. It fails to 'pop' the correct > amount of data from the proton transport that was actually transmitted, > under-accounting the amount, which results in some of the data being sent a > second time the next time output is generated and sent. > The underlying bug has been present for quite some time, but other changes > from 2.6.0 onward change broker behaviour in ways that make it much more > likely to actually occur during real world usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1547) Support referrals in the LDAP login module
[ https://issues.apache.org/jira/browse/ARTEMIS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516168#comment-16516168 ] ASF GitHub Bot commented on ARTEMIS-1547: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2143 > Support referrals in the LDAP login module > -- > > Key: ARTEMIS-1547 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1547 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 2.4.0 >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1547) Support referrals in the LDAP login module
[ https://issues.apache.org/jira/browse/ARTEMIS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516166#comment-16516166 ] ASF GitHub Bot commented on ARTEMIS-1547: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2143 @gtully I'm creating its own JIRA for this issue. as the commit report and release report would look weird with a fix jira in 2.5.0 > Support referrals in the LDAP login module > -- > > Key: ARTEMIS-1547 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1547 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 2.4.0 >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1932) Wildcard subscriptions create permanent bindings (STOMP)
[
https://issues.apache.org/jira/browse/ARTEMIS-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516164#comment-16516164
]
Justin Bertram commented on ARTEMIS-1932:
-
I attempted to reproduce this with no luck. Can you provide the STOMP frames
and {{broker.xml}} to reproduce this?
> Wildcard subscriptions create permanent bindings (STOMP)
>
>
> Key: ARTEMIS-1932
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1932
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> When using STOMP to create a wildcard subscription to {{/queue/test.\*}},
> Artemis creates a {{/queue/test.\*}} address and an eponymous ANYCAST queue
> within. So far, so good.
> However, these automatically created objects are permanent and survive at the
> end of the connection.
> Here is the test scenario:
> - start with an empty broker
> - connect
> - subscribe to {{/queue/test.\*}}
> - unsubscribe
> - disconnect
> - bug => the address and queue remain
> - connect
> - send a message to {{/queue/test.foo}}
> - bug => the message appears in the {{/queue/test.\*}} queue (in addition to
> {{/queue/test.foo}})
> FWIW, I'm using {{default-address-routing-type}} to make sure destinations
> starting with {{/queue/}} act like a queue (see ARTEMIS-1906).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1942) LDAP Configuration is missing
[ https://issues.apache.org/jira/browse/ARTEMIS-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516162#comment-16516162 ] clebert suconic commented on ARTEMIS-1942: -- this was originally done at ARTEMIS-1547 ARTEMIS-1600 broke this functionality. > LDAP Configuration is missing > - > > Key: ARTEMIS-1942 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1942 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.0 >Reporter: clebert suconic >Assignee: Gary Tully >Priority: Major > Fix For: 2.7.0, 2.6.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1942) LDAP Configuration is missing
clebert suconic created ARTEMIS-1942: Summary: LDAP Configuration is missing Key: ARTEMIS-1942 URL: https://issues.apache.org/jira/browse/ARTEMIS-1942 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.6.0 Reporter: clebert suconic Assignee: Gary Tully Fix For: 2.7.0, 2.6.2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1934) the broker sends duplicate AMQP connection data in certain conditions
[ https://issues.apache.org/jira/browse/ARTEMIS-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-1934: Affects Version/s: 2.5.0 2.6.0 > the broker sends duplicate AMQP connection data in certain conditions > - > > Key: ARTEMIS-1934 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1934 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.5.0, 2.6.0, 2.6.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 2.6.2 > > > The broker can write out some connection data twice in certain circumstances, > corrupting the connection data, due to the way it handles the proton-j > transport output and sending it out to Netty. It fails to 'pop' the correct > amount of data from the proton transport that was actually transmitted, > underaccounting the amount, which results in some of the data being sent a > second time the next time output is generated and sent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1940) premature release of pooled buffers during send can cause AMQP connection failures
[
https://issues.apache.org/jira/browse/ARTEMIS-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-1940:
Affects Version/s: 2.6.0
> premature release of pooled buffers during send can cause AMQP connection
> failures
> --
>
> Key: ARTEMIS-1940
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1940
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.6.0, 2.6.1
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 2.6.2
>
>
> When sending messages over AMQP connections to consumers, in certain cases
> the broker can prematurely release a pooled buffer before the message send
> process has completed using it. When attempt is made to send more data for
> the message later on the process fails since the buffer is no longer valid,
> per stacktrace below.
> The issue is that the broker assumes the send is entirely complete after
> pumping the proton transport, but there are cases where that may not yet be
> the case, perhaps leading to this issue. Most sends are not affected by the
> issue at all, but some such as for redelivered messages can be due to their
> use of pooled buffers.
> To address the issue for now, cases where the pooled buffers are being used
> should revert to the older copying send methods of proton, while the
> remainder continue to use the newer send methods that directly use the
> provided buffer (which is often just going to be the one created when the
> message arrived at the broker).
> {noformat}
> Thread-1 (activemq-netty-threads)] 18:49:34,857 WARN
> [org.apache.activemq.artemis.core.server] AMQ18: Server disconnecting:
> Error decoding buffer: io.netty.util.IllegalReferenceCountException: refCnt: 0
> at
> io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1417)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at io.netty.buffer.PooledHeapByteBuf.array(PooledHeapByteBuf.java:318)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.util.NettyReadable.get(NettyReadable.java:211)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.qpid.proton.codec.WritableBuffer$ByteBufferWrapper.put(WritableBuffer.java:140)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.FrameWriter.writeFrame(FrameWriter.java:180)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeFrame(TransportImpl.java:1075)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWorkSender(TransportImpl.java:599)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWork(TransportImpl.java:518)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeInto(TransportImpl.java:347)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.pending(TransportOutputAdaptor.java:59)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.head(TransportOutputAdaptor.java:80)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.SaslImpl$SwitchingSaslTransportWrapper.head(SaslImpl.java:820)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.HandshakeSniffingTransportWrapper.head(HandshakeSniffingTransportWrapper.java:151)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.head(TransportImpl.java:1533)
> [proton-j-0.27.1.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flushBytes(ProtonHandler.java:212)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:516)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:307)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.inputBuffer(ProtonHandler.java:272)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.inputBuffer(AMQPConnectionContext.java:158)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:147)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
>
[jira] [Commented] (ARTEMIS-1940) premature release of pooled buffers during send can cause AMQP connection failures
[
https://issues.apache.org/jira/browse/ARTEMIS-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516154#comment-16516154
]
ASF GitHub Bot commented on ARTEMIS-1940:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2147
> premature release of pooled buffers during send can cause AMQP connection
> failures
> --
>
> Key: ARTEMIS-1940
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1940
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.6.1
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 2.6.2
>
>
> When sending messages over AMQP connections to consumers, in certain cases
> the broker can prematurely release a pooled buffer before the message send
> process has completed using it. When attempt is made to send more data for
> the message later on the process fails since the buffer is no longer valid,
> per stacktrace below.
> The issue is that the broker assumes the send is entirely complete after
> pumping the proton transport, but there are cases where that may not yet be
> the case, perhaps leading to this issue. Most sends are not affected by the
> issue at all, but some such as for redelivered messages can be due to their
> use of pooled buffers.
> To address the issue for now, cases where the pooled buffers are being used
> should revert to the older copying send methods of proton, while the
> remainder continue to use the newer send methods that directly use the
> provided buffer (which is often just going to be the one created when the
> message arrived at the broker).
> {noformat}
> Thread-1 (activemq-netty-threads)] 18:49:34,857 WARN
> [org.apache.activemq.artemis.core.server] AMQ18: Server disconnecting:
> Error decoding buffer: io.netty.util.IllegalReferenceCountException: refCnt: 0
> at
> io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1417)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at io.netty.buffer.PooledHeapByteBuf.array(PooledHeapByteBuf.java:318)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.util.NettyReadable.get(NettyReadable.java:211)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.qpid.proton.codec.WritableBuffer$ByteBufferWrapper.put(WritableBuffer.java:140)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.FrameWriter.writeFrame(FrameWriter.java:180)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeFrame(TransportImpl.java:1075)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWorkSender(TransportImpl.java:599)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWork(TransportImpl.java:518)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeInto(TransportImpl.java:347)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.pending(TransportOutputAdaptor.java:59)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.head(TransportOutputAdaptor.java:80)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.SaslImpl$SwitchingSaslTransportWrapper.head(SaslImpl.java:820)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.HandshakeSniffingTransportWrapper.head(HandshakeSniffingTransportWrapper.java:151)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.head(TransportImpl.java:1533)
> [proton-j-0.27.1.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flushBytes(ProtonHandler.java:212)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:516)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:307)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.inputBuffer(ProtonHandler.java:272)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.inputBuffer(AMQPConnectionContext.java:158)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:147)
>
[jira] [Updated] (AMQ-6998) ArrayIndexOutOfBoundsException on Network of Brokers
[
https://issues.apache.org/jira/browse/AMQ-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Zhang updated AMQ-6998:
--
Description:
After updating from 5.14.0 to 5.15.3, we are seeing
ArrayIndexOutOfBoundsException in ActiveMQ logs like this:
{noformat}
2018-05-26 16:01:09,568 | WARN | Async error occurred:
java.lang.ArrayIndexOutOfBoundsException: 0 |
org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport:
tcp:///:61616@42320
2018-05-26 15:15:38,218 | INFO | Network connection between
vm://#1068 and tcp:///:61616@45338 shutdown
due to a local error: {} |
org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ Transport:
tcp:///:61616@45338
java.lang.ArrayIndexOutOfBoundsException: 0
at
org.apache.activemq.broker.region.virtual.MappedQueueFilter.addSubscription(MappedQueueFilter.java:62)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.region.AbstractRegion.addSubscriptionsForDestination(AbstractRegion.java:244)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:162)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:339)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:242)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.region.AbstractRegion.lookup(AbstractRegion.java:555)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.region.AbstractRegion.addConsumer(AbstractRegion.java:342)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.region.RegionBroker.addConsumer(RegionBroker.java:418)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.jmx.ManagedRegionBroker.addConsumer(ManagedRegionBroker.java:240)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:104)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.advisory.AdvisoryBroker.addConsumer(AdvisoryBroker.java:131)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:104)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:104)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:104)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.TransportConnection.processAddConsumer(TransportConnection.java:697)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.command.ConsumerInfo.visit(ConsumerInfo.java:352)[activemq-client-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:330)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:194)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)[activemq-client-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)[activemq-client-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.vm.VMTransport.doDispatch(VMTransport.java:165)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.vm.VMTransport.dispatch(VMTransport.java:157)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:134)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68)[activemq-client-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)[activemq-client-5.15.3.jar:5.15.3]
at
org.apache.activemq.network.DemandForwardingBridgeSupport.addSubscription(DemandForwardingBridgeSupport.java:1151)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.network.DemandForwardingBridgeSupport.addConsumerInfo(DemandForwardingBridgeSupport.java:1447)[activemq-broker-5.15.3.jar:5.15.3]
at
[jira] [Created] (AMQ-6998) ArrayIndexOutOfBoundsException on Network of Brokers
Joseph Zhang created AMQ-6998:
-
Summary: ArrayIndexOutOfBoundsException on Network of Brokers
Key: AMQ-6998
URL: https://issues.apache.org/jira/browse/AMQ-6998
Project: ActiveMQ
Issue Type: Bug
Components: Broker, networkbridge
Affects Versions: 5.15.3
Reporter: Joseph Zhang
After updating from 5.14.0 to 5.15.3, we are seeing
ArrayIndexOutOfBoundsException in ActiveMQ logs like this:
{noformat}
2018-05-26 16:01:09,568 | WARN | Async error occurred:
java.lang.ArrayIndexOutOfBoundsException: 0 |
org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport:
tcp:///:61616@42320
2018-05-26 15:15:38,218 | INFO | Network connection between
vm://#1068 and tcp:///:61616@45338 shutdown
due to a local error: {} |
org.apache.activemq.network.DemandForwardingBridgeSupport | ActiveMQ Transport:
tcp:///:61616@45338
java.lang.ArrayIndexOutOfBoundsException: 0 at
org.apache.activemq.broker.region.virtual.MappedQueueFilter.addSubscription(MappedQueueFilter.java:62)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.region.AbstractRegion.addSubscriptionsForDestination(AbstractRegion.java:244)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:162)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:339)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:242)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:454)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.jmx.ManagedRegionBroker.send(ManagedRegionBroker.java:293)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:154)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.CompositeDestinationBroker.send(CompositeDestinationBroker.java:96)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.TransactionBroker.send(TransactionBroker.java:293)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:154)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.TransportConnection.processMessage(TransportConnection.java:572)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:768)[activemq-client-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:330)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:194)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)[activemq-client-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:125)[activemq-client-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:301)[activemq-client-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)[activemq-client-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:233)[activemq-client-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:215)[activemq-client-5.15.3.jar:5.15.3]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_172]
{noformat}
It's breaking the networkbridge connections between brokers, making them unable
to forward message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1933) Wildcard subscriptions deliver queue message multiple times (STOMP)
[
https://issues.apache.org/jira/browse/ARTEMIS-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516152#comment-16516152
]
Justin Bertram commented on ARTEMIS-1933:
-
I attempted to reproduce this with no luck. Can you provide the STOMP frames
and {{broker.xml}} to reproduce this?
> Wildcard subscriptions deliver queue message multiple times (STOMP)
> ---
>
> Key: ARTEMIS-1933
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1933
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> Here is the scenario (using STOMP):
> - one subscription to {{/queue/test.foo}}
> - one subscription to {{/queue/test.*}}
> - one message sent to {{/queue/test.foo}}
> Since we are dealing with queues, the message should be load-balanced between
> the two matching subscriptions so only one should get it. This is what
> ActiveMQ 5 does.
> With Artemis, both subscriptions get the message.
> FWIW, I'm using {{default-address-routing-type}} to make sure destinations
> starting with {{/queue/}} act like a queue (see ARTEMIS-1906).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1940) premature release of pooled buffers during send can cause AMQP connection failures
[
https://issues.apache.org/jira/browse/ARTEMIS-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516132#comment-16516132
]
ASF GitHub Bot commented on ARTEMIS-1940:
-
GitHub user gemmellr opened a pull request:
https://github.com/apache/activemq-artemis/pull/2147
ARTEMIS-1940: premature release of pooled buffers during send can cause
AMQP connection failures
See https://issues.apache.org/jira/browse/ARTEMIS-1940 for details.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gemmellr/activemq-artemis ARTEMIS-1940
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/2147.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2147
commit ed2a18f1c49bc1f45a7978f01989fd4b253f0693
Author: Robbie Gemmell
Date: 2018-06-18T18:30:26Z
ARTEMIS-1940: restore use of copying send in certain edge cases
Avoids pooling corner cases interacting with ARTEMIS 1843 + ARTEMIS 1861
improvements.
Also tagging ARTEMIS-1941 to note test needs altered along with it.
> premature release of pooled buffers during send can cause AMQP connection
> failures
> --
>
> Key: ARTEMIS-1940
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1940
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.6.1
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 2.6.2
>
>
> When sending messages over AMQP connections to consumers, in certain cases
> the broker can prematurely release a pooled buffer before the message send
> process has completed using it. When attempt is made to send more data for
> the message later on the process fails since the buffer is no longer valid,
> per stacktrace below.
> The issue is that the broker assumes the send is entirely complete after
> pumping the proton transport, but there are cases where that may not yet be
> the case, perhaps leading to this issue. Most sends are not affected by the
> issue at all, but some such as for redelivered messages can be due to their
> use of pooled buffers.
> To address the issue for now, cases where the pooled buffers are being used
> should revert to the older copying send methods of proton, while the
> remainder continue to use the newer send methods that directly use the
> provided buffer (which is often just going to be the one created when the
> message arrived at the broker).
> {noformat}
> Thread-1 (activemq-netty-threads)] 18:49:34,857 WARN
> [org.apache.activemq.artemis.core.server] AMQ18: Server disconnecting:
> Error decoding buffer: io.netty.util.IllegalReferenceCountException: refCnt: 0
> at
> io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1417)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at io.netty.buffer.PooledHeapByteBuf.array(PooledHeapByteBuf.java:318)
> [netty-buffer-4.1.24.Final.jar:4.1.24.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.util.NettyReadable.get(NettyReadable.java:211)
> [artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
> at
> org.apache.qpid.proton.codec.WritableBuffer$ByteBufferWrapper.put(WritableBuffer.java:140)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.FrameWriter.writeFrame(FrameWriter.java:180)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeFrame(TransportImpl.java:1075)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWorkSender(TransportImpl.java:599)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWork(TransportImpl.java:518)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.writeInto(TransportImpl.java:347)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.pending(TransportOutputAdaptor.java:59)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.head(TransportOutputAdaptor.java:80)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.SaslImpl$SwitchingSaslTransportWrapper.head(SaslImpl.java:820)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.HandshakeSniffingTransportWrapper.head(HandshakeSniffingTransportWrapper.java:151)
> [proton-j-0.27.1.jar:]
> at
> org.apache.qpid.proton.engine.impl.TransportImpl.head(TransportImpl.java:1533)
> [proton-j-0.27.1.jar:]
> at
>
[jira] [Created] (ARTEMIS-1941) broker changes AMQP body section type during 'Large' message handling
Robbie Gemmell created ARTEMIS-1941: --- Summary: broker changes AMQP body section type during 'Large' message handling Key: ARTEMIS-1941 URL: https://issues.apache.org/jira/browse/ARTEMIS-1941 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.6.1 Reporter: Robbie Gemmell When the broker receives AMQP messages it considers those over a certain size (currently the lower of journal file size and journal buffer size) to be a 'large' message. In its handling of these, the message is essentially converted internally to a Core message, and when sending the message to an AMQP consumer, essentially gets converted back. During investigation of and testing of ARTEMIS-1940 I noted that although my test sent in an AMQP Data body section and so that is what should come back out, I instead received an AMQP Value body section containing a binary value (with the same bytes). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1940) premature release of pooled buffers during send can cause AMQP connection failures
Robbie Gemmell created ARTEMIS-1940:
---
Summary: premature release of pooled buffers during send can cause
AMQP connection failures
Key: ARTEMIS-1940
URL: https://issues.apache.org/jira/browse/ARTEMIS-1940
Project: ActiveMQ Artemis
Issue Type: Bug
Components: AMQP
Affects Versions: 2.6.1
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
Fix For: 2.6.2
When sending messages over AMQP connections to consumers, in certain cases the
broker can prematurely release a pooled buffer before the message send process
has completed using it. When attempt is made to send more data for the message
later on the process fails since the buffer is no longer valid, per stacktrace
below.
The issue is that the broker assumes the send is entirely complete after
pumping the proton transport, but there are cases where that may not yet be the
case, perhaps leading to this issue. Most sends are not affected by the issue
at all, but some such as for redelivered messages can be due to their use of
pooled buffers.
To address the issue for now, cases where the pooled buffers are being used
should revert to the older copying send methods of proton, while the remainder
continue to use the newer send methods that directly use the provided buffer
(which is often just going to be the one created when the message arrived at
the broker).
{noformat}
Thread-1 (activemq-netty-threads)] 18:49:34,857 WARN
[org.apache.activemq.artemis.core.server] AMQ18: Server disconnecting:
Error decoding buffer: io.netty.util.IllegalReferenceCountException: refCnt: 0
at
io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1417)
[netty-buffer-4.1.24.Final.jar:4.1.24.Final]
at io.netty.buffer.PooledHeapByteBuf.array(PooledHeapByteBuf.java:318)
[netty-buffer-4.1.24.Final.jar:4.1.24.Final]
at
org.apache.activemq.artemis.protocol.amqp.util.NettyReadable.get(NettyReadable.java:211)
[artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
at
org.apache.qpid.proton.codec.WritableBuffer$ByteBufferWrapper.put(WritableBuffer.java:140)
[proton-j-0.27.1.jar:]
at
org.apache.qpid.proton.engine.impl.FrameWriter.writeFrame(FrameWriter.java:180)
[proton-j-0.27.1.jar:]
at
org.apache.qpid.proton.engine.impl.TransportImpl.writeFrame(TransportImpl.java:1075)
[proton-j-0.27.1.jar:]
at
org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWorkSender(TransportImpl.java:599)
[proton-j-0.27.1.jar:]
at
org.apache.qpid.proton.engine.impl.TransportImpl.processTransportWork(TransportImpl.java:518)
[proton-j-0.27.1.jar:]
at
org.apache.qpid.proton.engine.impl.TransportImpl.writeInto(TransportImpl.java:347)
[proton-j-0.27.1.jar:]
at
org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.pending(TransportOutputAdaptor.java:59)
[proton-j-0.27.1.jar:]
at
org.apache.qpid.proton.engine.impl.TransportOutputAdaptor.head(TransportOutputAdaptor.java:80)
[proton-j-0.27.1.jar:]
at
org.apache.qpid.proton.engine.impl.SaslImpl$SwitchingSaslTransportWrapper.head(SaslImpl.java:820)
[proton-j-0.27.1.jar:]
at
org.apache.qpid.proton.engine.impl.HandshakeSniffingTransportWrapper.head(HandshakeSniffingTransportWrapper.java:151)
[proton-j-0.27.1.jar:]
at
org.apache.qpid.proton.engine.impl.TransportImpl.head(TransportImpl.java:1533)
[proton-j-0.27.1.jar:]
at
org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flushBytes(ProtonHandler.java:212)
[artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
at
org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:516)
[artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
at
org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:307)
[artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
at
org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.inputBuffer(ProtonHandler.java:272)
[artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
at
org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.inputBuffer(AMQPConnectionContext.java:158)
[artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
at
org.apache.activemq.artemis.protocol.amqp.broker.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:147)
[artemis-amqp-protocol-2.7.0-SNAPSHOT.jar:]
at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:643)
[artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
[artemis-core-client-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
[jira] [Commented] (ARTEMIS-1939) Remove space from parameter annotations name in ActiveMQServerControl
[
https://issues.apache.org/jira/browse/ARTEMIS-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515995#comment-16515995
]
ASF GitHub Bot commented on ARTEMIS-1939:
-
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2146
Does this change the current exposed JMX endpoints?
> Remove space from parameter annotations name in ActiveMQServerControl
> -
>
> Key: ARTEMIS-1939
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1939
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.6.1
>Reporter: Shailendra Kumar singh
>Priority: Major
> Attachments: Console_JMX_error.png
>
>
> Some operations in ActiveMQServerControl have space in Parameter annotations
> name which breaks webconsole with below error
> {code:java}
> Error: Syntax Error: Token 'Number' is an unexpected token at column 13 of
> the expression [entity.Page Number] starting at [Number].
> Stack trace:
> Error: Syntax Error: Token 'Number' is an unexpected token at column 13 of
> the expression [entity.Page Number] starting at [Number].
> {code}
> Attached screen-shot
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1928) Message redistribution + AMQP causes NPE
[
https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515871#comment-16515871
]
Justin Bertram commented on ARTEMIS-1928:
-
Version 2.6.1 contained a fix for ARTEMIS-1875 that was supposed to deal with
this issue, but it turned out to be only a partial fix. Since 2.6.1 a couple
commits have been added which I've been told should deal with this issue (I
haven't personally tried your use-case). Can you build & test
[2.6.x|https://github.com/apache/activemq-artemis/tree/2.6.x]?
> Message redistribution + AMQP causes NPE
>
>
> Key: ARTEMIS-1928
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1928
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.6.1
> Environment: * Broker Version: 2.6.1
> * Client: AMQPNetLite v2.1.2
> * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1
> (2018-05-07) x86_64 GNU/Linux
> * Host Platform: AWS EC2
> * broker.xml from node1 attached as node1-broker.xml
> * broker.xml from node2 attached as node2-broker.xml
>Reporter: Simon Chalmers
>Priority: Blocker
> Attachments: node1-broker.xml, node2-broker.xml
>
>
>
> Steps to produce, using a producing application (running AMQPNetLite)
> connecting to node1 of the cluster:
> * Create queue1, publish 199 messages to it
> * Create queue2, publish 1 message to it
> Running a consuming application (AMQPNetLite) connecting to node2 of the
> cluster:
> * On node1 of the cluster, queue1 & queue2 now have 0 messages in it
> * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2
> messages in it (i.e. an additional message in each queue, even though the
> consuming application is not publishing any messages).
> * The consuming application connected to node2 of the cluster does not
> consume any messages off either queue1 or queue2 from node2 (of the cluster).
> In artemis.log on node2 of the cluster, the following appears:
> {noformat}
> 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server]
> AMQ222151: removing consumer which did not handle a message,
> consumer=ServerConsumerImpl [id=1, filter=null, binding=LocalQueueBinding
> [address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> queue=QueueImpl[name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=f80e9286-6e9f-11e8-bd64-0204cf8299ac],
> temp=false]@50517445, filter=null,
> name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> clusterName=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-requestf80e9286-6e9f-11e8-bd64-0204cf8299ac]],
>
> message=Reference[117]:NON-RELIABLE:LargeServerMessage[messageID=117,durable=false,userID=null,priority=0,
> timestamp=0,expiration=0, durable=false,
> address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> properties=TypedProperties[_AMQ_LARGE_SIZE=330649]]@2025498374:
> java.lang.IllegalStateException: Can't deliver message
> java.lang.NullPointerException
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:652)
> [artemis-amqp-protocol-2.6.1.jar:]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1106)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:464)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:2934)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2402)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$2000(QueueImpl.java:107)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:3207)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
>
[jira] [Commented] (AMQ-6987) ActiveMQ 5.15.4 contains activemq-camel-5.15.4.jar wich has two high severity CVEs against it
[ https://issues.apache.org/jira/browse/AMQ-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515799#comment-16515799 ] Albert Baker commented on AMQ-6987: --- 5.15.4 is the latest version in maven central : [http://mvnrepository.com/artifact/org.apache.activemq/activemq-camel] > ActiveMQ 5.15.4 contains activemq-camel-5.15.4.jar wich has two high severity > CVEs against it > - > > Key: AMQ-6987 > URL: https://issues.apache.org/jira/browse/AMQ-6987 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-camel >Affects Versions: 5.15.4 > Environment: Customer environment is a mix of Linux and Windows, > Gig-LAN. Will not accept the risk of having even one high severity CVE in > thier environment. >Reporter: Albert Baker >Priority: Blocker > > ActiveMQ 5.15.4 contains activemq-camel-5.15.4.jar which has two high > severity CVEs against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report > CVE-2015-5183 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-254 Security Features The Hawtio console in A-MQ does not set > HTTPOnly or Secure attributes on cookies. > CVE-2015-5184 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-254 Security Features The Hawtio console in A-MQ allows remote > attackers to obtain sensitive information and perform other unspecified > impact. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6988) ActiveMQ 5.15.4 contains activemq-protobuf-1.1.jar which has three high severity CVEs against it.Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and run
[ https://issues.apache.org/jira/browse/AMQ-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515796#comment-16515796 ] Albert Baker commented on AMQ-6988: --- 2.11 is the latest version in maven central : [http://mvnrepository.com/artifact/org.apache.activemq.protobuf/activemq-protobuf] Yet this CVE has been open for three yrs ? > ActiveMQ 5.15.4 contains activemq-protobuf-1.1.jar which has three high > severity CVEs against it.Discovered by adding OWASP Dependency check into > ActiveMQ pom.xml and running the OWASP report > --- > > Key: AMQ-6988 > URL: https://issues.apache.org/jira/browse/AMQ-6988 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN. Will not accept the risk of having even one high severity > CVE in thier environment. >Reporter: Albert Baker >Priority: Blocker > > ActiveMQ 5.15.4 contains activemq-protobuf-1.1.jar which has two high > severity CVEs against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report > CVE-2015-5183 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-254 Security Features The Hawtio console in A-MQ does not set > HTTPOnly or Secure attributes on cookies. > CVE-2015-5184 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-254 Security Features The Hawtio console in A-MQ allows remote > attackers to obtain sensitive information and perform other unspecified > impact. > CVE-2016-3088 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-20 Improper Input Validation > The Fileserver web application in Apache ActiveMQ 5.x before 5.14.0 allows > remote attackers to upload and execute arbitrary files via an HTTP PUT > followed by an HTTP MOVE request. > CONFIRM - > http://activemq.apache.org/security-advisories.data/CVE-2016-3088-announcement.txt > EXPLOIT-DB - 42283 > MISC - http://www.zerodayinitiative.com/advisories/ZDI-16-356 > MISC - http://www.zerodayinitiative.com/advisories/ZDI-16-357 > REDHAT - RHSA-2016:2036 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6989) ActiveMQ 5.15.4 contains scala-library-2.11.0.jar which has one high severity CVE against it.
[
https://issues.apache.org/jira/browse/AMQ-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515795#comment-16515795
]
Albert Baker commented on AMQ-6989:
---
2.12.6 is available in maven central :
[http://mvnrepository.com/artifact/org.scala-lang/scala-library]
Its unclear if upgrading to this will pass all build tests.
> ActiveMQ 5.15.4 contains scala-library-2.11.0.jar which has one high severity
> CVE against it.
> -
>
> Key: AMQ-6989
> URL: https://issues.apache.org/jira/browse/AMQ-6989
> Project: ActiveMQ
> Issue Type: Bug
> Components: webconsole
>Affects Versions: 5.15.4
> Environment: Environment: Customer environment is a mix of Linux and
> Windows, Gig-LAN. Will not accept the risk of having even one high severity
> CVE in thier environment.
>Reporter: Albert Baker
>Priority: Blocker
>
> ActiveMQ 5.15.4 contains scala-library-2.11.0.jar which has one high severity
> CVE against it.
> Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running
> the OWASP report.
> CVE-2017-15288 Severity:High CVSS Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C)
> CWE: CWE-264 Permissions, Privileges, and Access Controls
> The compilation daemon in Scala before 2.10.7, 2.11.x before 2.11.12, and
> 2.12.x before 2.12.4 uses weak permissions for private files in
> /tmp/scala-devel/${USER:shared}
> /scalac-compile-server-port, which allows local users to write to arbitrary
> class files and consequently gain privileges.
> CONFIRM - http://scala-lang.org/news/security-update-nov17.html
> CONFIRM - https://github.com/scala/scala/pull/6108
> CONFIRM - https://github.com/scala/scala/pull/6120
> CONFIRM - https://github.com/scala/scala/pull/6128
> Vulnerable Software & Versions: (show all)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-6990) ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity CVE against it.
[ https://issues.apache.org/jira/browse/AMQ-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515792#comment-16515792 ] Albert Baker commented on AMQ-6990: --- 1.8.3 is available in maven central [http://mvnrepository.com/artifact/commons-beanutils/commons-beanutils-core] Please update the AQM pom to use 1.8.3 > ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity > CVE against it. > > > Key: AMQ-6990 > URL: https://issues.apache.org/jira/browse/AMQ-6990 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > > ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity > CVE against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > CVE-2014-0114 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-20 Improper Input Validation > Apache Commons BeanUtils, as distributed in lib/commons-beanutils-1.8.0.jar > in Apache Struts 1.x through 1.3.10 and in other products requiring > commons-beanutils > through 1.9.2, does not suppress the class property, which allows remote > attackers to "manipulate" the ClassLoader and execute arbitrary code via the > class parameter, as > demonstrated by the passing of this parameter to the getClass method of the > ActionForm object in Struts 1. > BID - 67121 > BUGTRAQ - 20141205 NEW: VMSA-2014-0012 - VMware vSphere product updates > address security vulnerabilities > CONFIRM - http://advisories.mageia.org/MGASA-2014-0219.html > CONFIRM - > http://commons.apache.org/proper/commons-beanutils/javadocs/v1.9.2/RELEASE-NOTES.txt > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674128 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674812 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675266 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675387 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675689 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675898 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675972 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676091 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676110 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676303 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676375 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676931 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21677110 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg27042296 > CONFIRM - http://www.ibm.com/support/docview.wss?uid=swg21675496 > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpujan2015-1972971.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpuoct2014-1972960.html > CONFIRM - http://www.vmware.com/security/advisories/VMSA-2014-0008.html > CONFIRM - http://www.vmware.com/security/advisories/VMSA-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1938) AMQP: Update Qpid JMS to latest 0.33.0
[ https://issues.apache.org/jira/browse/ARTEMIS-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515791#comment-16515791 ] ASF GitHub Bot commented on ARTEMIS-1938: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2145 > AMQP: Update Qpid JMS to latest 0.33.0 > -- > > Key: ARTEMIS-1938 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1938 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Affects Versions: 2.6.1 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 2.7.0 > > > Update to latest Qpid JMS client release -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6991) ActiveMQ 5.15.4 hadoop-core-1.0.0.jar which has two high severity CVEs against it.
[ https://issues.apache.org/jira/browse/AMQ-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515786#comment-16515786 ] Albert Baker commented on AMQ-6991: --- "NameNode provided as a query parameter is not validated in Apache Hadoop before 2.7.0." 2.7.0 does not exist in maven central : [http://mvnrepository.com/artifact/org.apache.hadoop/hadoop-core] or maven cloudera : [http://mvnrepository.com/artifact/org.apache.hadoop/hadoop-core?repo=cloudera] > ActiveMQ 5.15.4 hadoop-core-1.0.0.jar which has two high severity CVEs > against it. > -- > > Key: AMQ-6991 > URL: https://issues.apache.org/jira/browse/AMQ-6991 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > > ActiveMQ 5.15.4 hadoop-core-1.0.0.jar which has two high severity CVEs > against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > CVE-2012-4449 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-327 Use of a Broken or Risky Cryptographic Algorithm > Apache Hadoop before 0.23.4, 1.x before 1.0.4, and 2.x before 2.0.2 generate > token passwords using a 20-bit secret when Kerberos security features are > enabled, which > makes it easier for context-dependent attackers to crack secret keys via a > brute-force attack. > CONFIRM - > https://www.cloudera.com/documentation/other/security-bulletins/topics/csb_topic_1.html#topic_1_0 > MLIST - [hadoop-general] 20121012 [ANNOUNCE] Hadoop-1.0.4 release, with > Security fix > Vulnerable Software & Versions: (show all) > cpe:/a:apache:hadoop:1.0.0 > CVE-2017-3162 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-20 Improper Input Validation > HDFS clients interact with a servlet on the DataNode to browse the HDFS > namespace. The NameNode is provided as a query parameter that is not > validated in Apache > Hadoop before 2.7.0. > BID - 98017 > MLIST - [hadoop-common-dev] 20170425 CVE-2017-3162: Apache Hadoop DataNode > web UI vulnerability > Vulnerable Software & Versions: > cpe:/a:apache:hadoop:2.6.5 and all previous versions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6992) ActiveMQ 5.15.4 jackson-databind-2.9.4.jar which has one high severity CVEs against it.
[ https://issues.apache.org/jira/browse/AMQ-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515779#comment-16515779 ] Albert Baker commented on AMQ-6992: --- 2.9.6 is the latest version in maven central : [http://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind] But its unclear if there are incompatabilities btween this library and other libs &| AMQ > ActiveMQ 5.15.4 jackson-databind-2.9.4.jar which has one high severity CVEs > against it. > --- > > Key: AMQ-6992 > URL: https://issues.apache.org/jira/browse/AMQ-6992 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > > ctiveMQ 5.15.4 jackson-databind-2.9.4.jar which has one high severity CVEs > against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > CVE-2018-7489 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-184 Incomplete Blacklist > FasterXML jackson-databind before 2.8.11.1 and 2.9.x before 2.9.5 allows > unauthenticated remote code execution because of an incomplete fix for the > CVE-2017-7525 > deserialization flaw. This is exploitable by sending maliciously crafted JSON > input to the readValue method of the ObjectMapper, bypassing a blacklist that > is ineffective if the > c3p0 libraries are available in the classpath. > BID - 103203 > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html > CONFIRM - https://github.com/FasterXML/jackson-databind/issues/1931 > CONFIRM - https://security.netapp.com/advisory/ntap-20180328-0001/ > DEBIAN - DSA-4190 > REDHAT - RHSA-2018:1447 > REDHAT - RHSA-2018:1448 > REDHAT - RHSA-2018:1449 > REDHAT - RHSA-2018:1450 > REDHAT - RHSA-2018:1451 > REDHAT - RHSA-2018:1786 > SECTRACK - 1040693 > Vulnerable Software & Versions: (show all) > cpe:/a:fasterxml:jackson-databind:2.9.4 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6993) ActiveMQ 5.15.4 activeio-core-3.1.4.jar which has three high severity CVEs against it.
[ https://issues.apache.org/jira/browse/AMQ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515777#comment-16515777 ] Albert Baker commented on AMQ-6993: --- 3.14 is the latest version in maven central : http://mvnrepository.com/artifact/org.apache.activemq/activeio-core > ActiveMQ 5.15.4 activeio-core-3.1.4.jar which has three high severity CVEs > against it. > --- > > Key: AMQ-6993 > URL: https://issues.apache.org/jira/browse/AMQ-6993 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > > ActiveMQ 5.15.4 activeio-core-3.1.4.jar which has three high severity CVEs > against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > CVE-2015-5183 suppress > Severity:High > CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-254 Security Features > The Hawtio console in A-MQ does not set HTTPOnly or Secure attributes on > cookies. > CONFIRM - https://bugzilla.redhat.com/show_bug.cgi?id=1249182 > Vulnerable Software & Versions: > cpe:/a:apache:activemq:- > CVE-2015-5184 Severity:High > CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-254 Security Features > The Hawtio console in A-MQ allows remote attackers to obtain sensitive > information and perform other unspecified impact. > CONFIRM - https://bugzilla.redhat.com/show_bug.cgi?id=1249183 > Vulnerable Software & Versions: > cpe:/a:apache:activemq:- > CVE-2016-3088 Severity:High > CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-20 Improper Input Validation > The Fileserver web application in Apache ActiveMQ 5.x before 5.14.0 allows > remote attackers to upload and execute arbitrary files via an HTTP PUT > followed by an HTTP > MOVE request. > CONFIRM - > http://activemq.apache.org/security-advisories.data/CVE-2016-3088-announcement.txt > EXPLOIT-DB - 42283 > MISC - http://www.zerodayinitiative.com/advisories/ZDI-16-356 > MISC - http://www.zerodayinitiative.com/advisories/ZDI-16-357 > REDHAT - RHSA-2016:2036 > SECTRACK - 1035951 > Vulnerable Software & Versions: > cpe:/a:apache:activemq:5.13.3 and all previous versions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6994) ActiveMQ 5.15.4 tomcat-servlet-api-8.0.24.jar which has four high severity CVEs against it.
[ https://issues.apache.org/jira/browse/AMQ-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515772#comment-16515772 ] Albert Baker commented on AMQ-6994: --- 9.0.8 esists in maven central : [http://mvnrepository.com/artifact/org.apache.tomcat/tomcat-servlet-api/9.0.8] But its unclear if there are other incompatible dependencies across the other libs & AMQ with that version. > ActiveMQ 5.15.4 tomcat-servlet-api-8.0.24.jar which has four high severity > CVEs against it. > > > Key: AMQ-6994 > URL: https://issues.apache.org/jira/browse/AMQ-6994 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > > ActiveMQ 5.15.4 tomcat-servlet-api-8.0.24.jar which has four high severity > CVEs against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > Referenced In Projects/Scopes: > ActiveMQ :: Assembly:compile > ActiveMQ :: Web:provided > ActiveMQ :: Web Console:provided > CVE-2016-3092 Severity:High CVSS Score: 7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C) > CWE: CWE-20 Improper Input Validation > The MultipartStream class in Apache Commons Fileupload before 1.3.2, as used > in Apache Tomcat 7.x before 7.0.70, 8.x before 8.0.36, 8.5.x before 8.5.3, > and 9.x before > 9.0.0.M7 and other products, allows remote attackers to cause a denial of > service (CPU consumption) via a long boundary string. > BID - 91453 > CONFIRM - http://svn.apache.org/viewvc?view=revision=1743480 > CONFIRM - http://svn.apache.org/viewvc?view=revision=1743722 > CONFIRM - http://svn.apache.org/viewvc?view=revision=1743738 > CONFIRM - http://svn.apache.org/viewvc?view=revision=1743742 > CONFIRM - http://tomcat.apache.org/security-7.html > CONFIRM - http://tomcat.apache.org/security-8.html > CONFIRM - http://tomcat.apache.org/security-9.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/bulletinjul2016-3090568.html > CONFIRM - https://bugzilla.redhat.com/show_bug.cgi?id=1349468 > CONFIRM - > https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05204371 > CONFIRM - > https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05289840 > CONFIRM - > https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05324759 > DEBIAN - DSA-3609 > DEBIAN - DSA-3611 > DEBIAN - DSA-3614 > GENTOO - GLSA-201705-09 > JVN - JVN#89379547 > JVNDB - JVNDB-2016-000121 > MLIST - [dev] 20160621 CVE-2016-3092: Apache Commons Fileupload information > disclosure vulnerability > REDHAT - RHSA-2016:2068 > REDHAT - RHSA-2016:2069 > REDHAT - RHSA-2016:2070 > REDHAT - RHSA-2016:2071 > REDHAT - RHSA-2016:2072 > REDHAT - RHSA-2016:2599 > REDHAT - RHSA-2016:2807 > REDHAT - RHSA-2016:2808 > REDHAT - RHSA-2017:0455 > REDHAT - RHSA-2017:0456 > REDHAT - RHSA-2017:0457 > SECTRACK - 1036427 > SECTRACK - 1036900 > SECTRACK - 1037029 > SECTRACK - 1039606 > SUSE - openSUSE-SU-2016:2252 > UBUNTU - USN-3024-1 > UBUNTU - USN-3027-1 > Vulnerable Software & Versions: (show all) > cpe:/a:apache:tomcat:8.0.24 > CVE-2016-5425 Severity:High CVSS Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C) > CWE: CWE-264 Permissions, Privileges, and Access Controls > The Tomcat package on Red Hat Enterprise Linux (RHEL) 7, Fedora, CentOS, > Oracle Linux, and possibly other Linux distributions uses weak permissions > for /usr/lib > /tmpfiles.d/tomcat.conf, which allows local users to gain root privileges by > leveraging membership in the tomcat group. > BID - 93472 > CONFIRM - > http://www.oracle.com/technetwork/topics/security/linuxbulletinoct2016-3090545.html > EXPLOIT-DB - 40488 > MISC - > http://legalhackers.com/advisories/Tomcat-RedHat-Pkgs-Root-PrivEsc-Exploit-CVE-2016-5425.html > MISC - > http://packetstormsecurity.com/files/139041/Apache-Tomcat-8-7-6-Privilege-Escalation.html > MLIST - [oss-security] 20161010 CVE-2016-5425 - Apache Tomcat packaging on > RedHat-based distros - Root Privilege Escalation (affecting CentOS, Fedora, > OracleLinux, RedHat etc.) > REDHAT - RHSA-2016:2046 > SECTRACK - 1036979 > Vulnerable Software & Versions: >
[jira] [Comment Edited] (AMQ-6994) ActiveMQ 5.15.4 tomcat-servlet-api-8.0.24.jar which has four high severity CVEs against it.
[ https://issues.apache.org/jira/browse/AMQ-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515772#comment-16515772 ] Albert Baker edited comment on AMQ-6994 at 6/18/18 2:24 PM: 9.0.8 exists in maven central : [http://mvnrepository.com/artifact/org.apache.tomcat/tomcat-servlet-api/9.0.8] But its unclear if there are other incompatible dependencies across the other libs & AMQ with that version. was (Author: abakeriii): 9.0.8 esists in maven central : [http://mvnrepository.com/artifact/org.apache.tomcat/tomcat-servlet-api/9.0.8] But its unclear if there are other incompatible dependencies across the other libs & AMQ with that version. > ActiveMQ 5.15.4 tomcat-servlet-api-8.0.24.jar which has four high severity > CVEs against it. > > > Key: AMQ-6994 > URL: https://issues.apache.org/jira/browse/AMQ-6994 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > > ActiveMQ 5.15.4 tomcat-servlet-api-8.0.24.jar which has four high severity > CVEs against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > Referenced In Projects/Scopes: > ActiveMQ :: Assembly:compile > ActiveMQ :: Web:provided > ActiveMQ :: Web Console:provided > CVE-2016-3092 Severity:High CVSS Score: 7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C) > CWE: CWE-20 Improper Input Validation > The MultipartStream class in Apache Commons Fileupload before 1.3.2, as used > in Apache Tomcat 7.x before 7.0.70, 8.x before 8.0.36, 8.5.x before 8.5.3, > and 9.x before > 9.0.0.M7 and other products, allows remote attackers to cause a denial of > service (CPU consumption) via a long boundary string. > BID - 91453 > CONFIRM - http://svn.apache.org/viewvc?view=revision=1743480 > CONFIRM - http://svn.apache.org/viewvc?view=revision=1743722 > CONFIRM - http://svn.apache.org/viewvc?view=revision=1743738 > CONFIRM - http://svn.apache.org/viewvc?view=revision=1743742 > CONFIRM - http://tomcat.apache.org/security-7.html > CONFIRM - http://tomcat.apache.org/security-8.html > CONFIRM - http://tomcat.apache.org/security-9.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/bulletinjul2016-3090568.html > CONFIRM - https://bugzilla.redhat.com/show_bug.cgi?id=1349468 > CONFIRM - > https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05204371 > CONFIRM - > https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05289840 > CONFIRM - > https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05324759 > DEBIAN - DSA-3609 > DEBIAN - DSA-3611 > DEBIAN - DSA-3614 > GENTOO - GLSA-201705-09 > JVN - JVN#89379547 > JVNDB - JVNDB-2016-000121 > MLIST - [dev] 20160621 CVE-2016-3092: Apache Commons Fileupload information > disclosure vulnerability > REDHAT - RHSA-2016:2068 > REDHAT - RHSA-2016:2069 > REDHAT - RHSA-2016:2070 > REDHAT - RHSA-2016:2071 > REDHAT - RHSA-2016:2072 > REDHAT - RHSA-2016:2599 > REDHAT - RHSA-2016:2807 > REDHAT - RHSA-2016:2808 > REDHAT - RHSA-2017:0455 > REDHAT - RHSA-2017:0456 > REDHAT - RHSA-2017:0457 > SECTRACK - 1036427 > SECTRACK - 1036900 > SECTRACK - 1037029 > SECTRACK - 1039606 > SUSE - openSUSE-SU-2016:2252 > UBUNTU - USN-3024-1 > UBUNTU - USN-3027-1 > Vulnerable Software & Versions: (show all) > cpe:/a:apache:tomcat:8.0.24 > CVE-2016-5425 Severity:High CVSS Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C) > CWE: CWE-264 Permissions, Privileges, and Access Controls > The Tomcat package on Red Hat Enterprise Linux (RHEL) 7, Fedora, CentOS, > Oracle Linux, and possibly other Linux distributions uses weak permissions > for /usr/lib > /tmpfiles.d/tomcat.conf, which allows local users to gain root privileges by > leveraging membership in the tomcat group. > BID - 93472 > CONFIRM - > http://www.oracle.com/technetwork/topics/security/linuxbulletinoct2016-3090545.html > EXPLOIT-DB - 40488 > MISC - > http://legalhackers.com/advisories/Tomcat-RedHat-Pkgs-Root-PrivEsc-Exploit-CVE-2016-5425.html > MISC - >
[jira] [Commented] (AMQ-6995) ActiveMQ 5.15.4 activemq-ra-5.15.4.jar which has two high severity CVEs against it.
[ https://issues.apache.org/jira/browse/AMQ-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515762#comment-16515762 ] Albert Baker commented on AMQ-6995: --- 15.4 looks like its the /latest/ version in maven central : http://mvnrepository.com/artifact/org.apache.activemq/activemq-ra > ActiveMQ 5.15.4 activemq-ra-5.15.4.jar which has two high severity CVEs > against it. > --- > > Key: AMQ-6995 > URL: https://issues.apache.org/jira/browse/AMQ-6995 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > > CVE-2015-5183 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-254 Security Features > The Hawtio console in A-MQ does not set HTTPOnly or Secure attributes on > cookies. > CONFIRM - https://bugzilla.redhat.com/show_bug.cgi?id=1249182 > Vulnerable Software & Versions: > cpe:/a:apache:activemq:- > CVE-2015-5184 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-254 Security Features > The Hawtio console in A-MQ allows remote attackers to obtain sensitive > information and perform other unspecified impact. > CONFIRM - https://bugzilla.redhat.c -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6996) ActiveMQ 5.15.4 xercesImpl-2.11.0.jar which has one high severity CVE against it.
[ https://issues.apache.org/jira/browse/AMQ-6996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515761#comment-16515761 ] Albert Baker commented on AMQ-6996: --- 2.12 exists here : [http://apache.mirrors.hoobly.com//xerces/j/binaries/Xerces-J-bin.2.12.0.tar.gz] Its unclear if replacing 2.11 w/ 2.12 will pass the build tests. Its unclear if there may be other weird inter-depencecy issues within the rest of the libraries. I would hope that the ActiveMQ team took these thrd party dependency issues on instead of every user having to patch the build. > ActiveMQ 5.15.4 xercesImpl-2.11.0.jar which has one high severity CVE against > it. > - > > Key: AMQ-6996 > URL: https://issues.apache.org/jira/browse/AMQ-6996 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, webconsole >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > > ActiveMQ 5.15.4 xercesImpl-2.11.0.jar which has one high severity CVE against > it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > CVE-2012-0881 Severity:High CVSS Score: 7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C) > CWE: CWE-399 Resource Management Errors > Apache Xerces2 Java allows remote attackers to cause a denial of service (CPU > consumption) via a crafted message to an XML service, which triggers hash > table collisions. > CONFIRM - https://bugzilla.redhat.com/show_bug.cgi?id=787104 > MLIST - [oss-security] 20140708 Summer bug cleaning - some Hash DoS stuff > Vulnerable Software & Versions: > cpe:/a:apache:xerces2_java:2.11.0 and all previous versions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
