[jira] [Commented] (ARTEMIS-283) Protocol independent JMSMessageID from management interface

[Petter Nordlander (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15996171#comment-15996171
 ] 

Petter Nordlander commented on ARTEMIS-283:
---

I have a hard time even calling listMessages/listMessagesAsJSON in 2.0 since it 
won't accept an empty filter param, or some simple "true" filter. I will make 
some more investigation into this.

> Protocol independent JMSMessageID from management interface
> ---
>
> Key: ARTEMIS-283
> URL: https://issues.apache.org/jira/browse/ARTEMIS-283
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
>Reporter: Petter Nordlander
>Priority: Minor
>
> The Management interface (JMX) has a listMessagesAsJSON operation on JMS 
> queues.
> Listing JMS messages would not make sense if there is not a JMSMessageID to 
> correlate with. This works only for messages produced with Artemis "Core JMS" 
> protocol (i.e. HornetQ wire protocol). Messages produced with AMQP (proton) 
> and OpenWire JMS clients does not contain the JMSMessageID property. 
> This property is vital to make GUIs, management scripts and whatnot.
> Example:
> Three messages in the following order: Artemis JMS, OpenWire, AMQP
> {code:javascript}
> [
>   {
>   "JMSPriority":4,
>   "JMSMessageID":"ID:11d61bfc-7c8f-11e5-b67d-fbf95a4499b8",
>   "address":"jms.queue.a1",
>   "JMSExpiration":0,
>   "__AMQ_CID":"11d1d638-7c8f-11e5-b67d-fbf95a4499b8",
>   "JMSTimestamp":1445938962608,
>   "messageID":134336,
>   "JMSDeliveryMode":"PERSISTENT"
>   },
>   {
>   "address":"jms.queue.a1",
>   "JMSExpiration":0,
>   "JMSTimestamp":1445938969309,
>   
> "__HDR_MARSHALL_PROP":[0,0,0,1,0,6,118,101,110,100,111,114,9,0,3,97,109,113],
>   "messageID":134354,
>   "__HDR_GROUP_SEQUENCE":0,
>   
> "__HDR_PRODUCER_ID":[0,0,0,61,123,1,43,0,52,73,68,58,80,101,116,116,101,114,115,45,77,97,99,66,111,111,107,45,80,114,111,46,108,111,99,97,108,45,54,52,53,55,52,45,49,52,52,53,57,51,56,57,54,57,49,53,54,45,49,58,49,0,1,0,1],
>   "JMSDeliveryMode":"PERSISTENT",
>   "JMSPriority":4,
>   "__HDR_COMMAND_ID":6,
>   "__HDR_ARRIVAL":0,
>   "__HDR_REDELIVER_COUNTER":0,
>   
> "__HDR_MESSAGE_ID":[0,0,0,65,110,2,-82,2,123,0,52,73,68,58,80,101,116,116,101,114,115,45,77,97,99,66,111,111,107,45,80,114,111,46,108,111,99,97,108,45,54,52,53,55,52,45,49,52,52,53,57,51,56,57,54,57,49,53,54,45,49,58,49,0,1,0,1,0,1],
>   "__HDR_DROPPABLE":false,
>   "__HDR_BROKER_IN_TIME":1445938969310
>   },
>   {
>   "JMS_AMQP_NATIVE":false,
>   "JMSPriority":4,
>   "address":"jms.queue.a1",
>   "JMSExpiration":0,
>   "JMS_AMQP_MESSAGE_FORMAT":0,
>   "JMSTimestamp":1445939704838,
>   "messageID":134376,
>   "JMSDeliveryMode":"PERSISTENT"
>   }
> ]
> {code}
> Corresponding Message Ids would be (read from JMS interface).
> Core: JMSMessageID: 783cf118-7c91-11e5-9a09-b3c5f39ba469:0:0:-1
> OpenWire: JMSMessageID: 
> ID:Petters-MacBook-Pro.local-64574-1445938969156-1:1:1:1:1
> AMQP: JMSMessageID: 783d1829-7c91-11e5-9a09-b3c5f39ba469:0:0:-1
> Problem is in QueueCtrlImpl which uses core-jms-client to convert messages 
> from core to Jms Map. It consider all messages as core messages. Logic from 
> each protocol/client should be used on respective message.
> Map jmsMessage = 
> ActiveMQMessage.coreMaptoJMSMap(coreMessage);



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1141) Validate Karaf features using the karaf plugin

[clebert suconic (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995749#comment-15995749
 ] 

clebert suconic commented on ARTEMIS-1141:
--

[~gnt] I'm getting this failure from time to time:

[WARNING] Feature resolution failed for [artemis-openwire/2.1.0.SNAPSHOT]
Message: Uses constraint violation. Unable to resolve resource 
org.apache.activemq.artemis-openwire-protocol 
[org.apache.activemq.artemis-openwire-protocol/2.1.0.SNAPSHOT] because it is 
exposed to package 'io.netty.buffer' from resources 
org.apache.activemq.artemis-server-osgi 
[org.apache.activemq.artemis-server-osgi/2.1.0.SNAPSHOT] and io.netty.buffer 
[io.netty.buffer/4.1.9.Final] via two dependency chains.

Chain 1:
  org.apache.activemq.artemis-openwire-protocol 
[org.apache.activemq.artemis-openwire-protocol/2.1.0.SNAPSHOT]
import: (osgi.wiring.package=io.netty.buffer)
 |
export: osgi.wiring.package: io.netty.buffer
  org.apache.activemq.artemis-server-osgi 
[org.apache.activemq.artemis-server-osgi/2.1.0.SNAPSHOT]

Chain 2:
  org.apache.activemq.artemis-openwire-protocol 
[org.apache.activemq.artemis-openwire-protocol/2.1.0.SNAPSHOT]
import: (osgi.wiring.package=io.netty.channel)
 |
export: osgi.wiring.package=io.netty.channel; uses:=io.netty.buffer
  io.netty.transport [io.netty.transport/4.1.9.Final]
import: 
(&(osgi.wiring.package=io.netty.buffer)(version>=4.1.0)(!(version>=5.0.0)))
 |
export: osgi.wiring.package: io.netty.buffer
  io.netty.buffer [io.netty.buffer/4.1.9.Final]



I had seen that also on the ArtemisFeatureTest... it's intermittent... kind of 
annoying... any ideas?

> Validate Karaf features using the karaf plugin
> --
>
> Key: ARTEMIS-1141
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1141
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: osgi
>Affects Versions: 2.0.0
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.next
>
>
> The Karaf maven plugin provides a validation goal which run the OSGi resolver 
> to ensure that the features can actually be installed in Karaf.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ARTEMIS-639) Make credit refresh size and refresh threshold configurable on AMQP protocol

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish closed ARTEMIS-639.

   Resolution: Fixed
Fix Version/s: 2.next

This was added in ARTEMIS-1073

> Make credit refresh size and refresh threshold configurable on AMQP protocol
> 
>
> Key: ARTEMIS-639
> URL: https://issues.apache.org/jira/browse/ARTEMIS-639
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Martyn Taylor
> Fix For: 2.next
>
>
> The number of credits allocated on an inbound linkAttach is hard coded at 
> 100, with a lower refresh boundary of 30 (the broker aims to issue more 
> credits once the client hits 30).  These numbers should be configurable.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ARTEMIS-460) AMQP topic subcription not working (qpid-cpp)

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish closed ARTEMIS-460.

Resolution: Cannot Reproduce

No test steps provided to reproduce.  The current AMQP test suite exercises the 
handling of Topic and Queue subscriptions without issue.  Reopen if a 
reproducer can be provided.  

> AMQP topic subcription not working (qpid-cpp)
> -
>
> Key: ARTEMIS-460
> URL: https://issues.apache.org/jira/browse/ARTEMIS-460
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.3.0
> Environment: RHEL 7.2 + openJDK
>Reporter: Ari Tilli
>
> This might be stupid user error (some flags missing) but on git-version
> I can not get topics working through AMQP wiht qpid-cpp
> 1) Topics are defined in broker.xml
> 2) Create a receiver in session and when sending message to itself, message 
> is not received. (Does not work even from different app, so not related to 
> using same session)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ARTEMIS-1140) Avoid Queue lock on queueQuery

[clebert suconic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

clebert suconic closed ARTEMIS-1140.

Resolution: Fixed

> Avoid Queue lock on queueQuery
> --
>
> Key: ARTEMIS-1140
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1140
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.5.4, 2.0.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.5.5, 2.next
>
>
> queueQuery is currently holding a lock on the queue to get a strict message 
> count on the queue.
> In case of high performance scenarios mixed with an anti-pattern on the 
> client with calling queueQuery constantly this will incur on low performance.
> this is an anti-pattern and not much we can do, but we don't need to hold a 
> lock just for that query.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1141) Validate Karaf features using the karaf plugin

[Guillaume Nodet (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995641#comment-15995641
 ] 

Guillaume Nodet commented on ARTEMIS-1141:
--

Yeah, I was about to fix the missing {{netty-transport-native-epoll}} bundle 
issue when I realized it was already fix, but then decided to leverage the 
plugin in order to detect those problems at build time.

> Validate Karaf features using the karaf plugin
> --
>
> Key: ARTEMIS-1141
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1141
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: osgi
>Affects Versions: 2.0.0
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.next
>
>
> The Karaf maven plugin provides a validation goal which run the OSGi resolver 
> to ensure that the features can actually be installed in Karaf.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ARTEMIS-267) AMQP messages without a Header section get persisted despite being non-durable

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish closed ARTEMIS-267.

   Resolution: Fixed
Fix Version/s: 2.next

> AMQP messages without a Header section get persisted despite being non-durable
> --
>
> Key: ARTEMIS-267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-267
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.1.0
>Reporter: Robbie Gemmell
> Fix For: 2.next
>
>
> When an AMQP message has no header section, or has a header but contains no 
> explicit value for the durable field, the spec defaults the value to being 
> false / non-durable. If a message is received by the broker without a Header 
> section, it currently gets persisted despite this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1141) Validate Karaf features using the karaf plugin

[clebert suconic (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995634#comment-15995634
 ] 

clebert suconic commented on ARTEMIS-1141:
--

[~gnt] thank you so much for this.. it would have saved me a day of work last 
week if this was already implemented.

> Validate Karaf features using the karaf plugin
> --
>
> Key: ARTEMIS-1141
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1141
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: osgi
>Affects Versions: 2.0.0
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.next
>
>
> The Karaf maven plugin provides a validation goal which run the OSGi resolver 
> to ensure that the features can actually be installed in Karaf.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1140) Avoid Queue lock on queueQuery

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995625#comment-15995625
 ] 

ASF subversion and git services commented on ARTEMIS-1140:
--

Commit 534fd8093d4bff4b0f883af1a0fbb3df2d701546 in activemq-artemis's branch 
refs/heads/1.x from Clebert Suconic
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=534fd80 ]

ARTEMIS-1140 Avoid lock on queue for message counts

(cherry picked from commit 33f2ad65c915a8fa2c3606271f106bf5703ace83)


> Avoid Queue lock on queueQuery
> --
>
> Key: ARTEMIS-1140
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1140
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.5.4, 2.0.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.5.5, 2.next
>
>
> queueQuery is currently holding a lock on the queue to get a strict message 
> count on the queue.
> In case of high performance scenarios mixed with an anti-pattern on the 
> client with calling queueQuery constantly this will incur on low performance.
> this is an anti-pattern and not much we can do, but we don't need to hold a 
> lock just for that query.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1112) EmbeddedJMS.start() doesn't return if shared-store master starts as backup server

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995622#comment-15995622
 ] 

ASF subversion and git services commented on ARTEMIS-1112:
--

Commit 6017e305d90664b4bf5b8f891e43514907df9a4b in activemq-artemis's branch 
refs/heads/master from [~bgutjahr]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=6017e30 ]

ARTEMIS-1112: Added wait-for-activation option to shared-store-master config

Added a wait-for-activation option to shared-store master HA policies.
This option is enabled by default to ensure unchanged server startup behavior.

If this option is enabled, ActiveMQServer.start() with a shared-store master 
server will not return
before the server has been activated.
If this options is disabled, start() will return after a background activation 
thread has been started.
The caller can use waitForActivation() to wait until server is activated, or 
just check the current activation status.


> EmbeddedJMS.start() doesn't return if shared-store master starts as backup 
> server
> -
>
> Key: ARTEMIS-1112
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1112
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.4, 2.0.0
>Reporter: Bernd Gutjahr
>Priority: Minor
>
> EmbeddedServer.start() doesn't return when a share-store master server has 
> been configured, but at startup another server is already running as live 
> server (i.e. another previously started master).
> In that case, this server becomes a backup server for the currently running 
> live server. The start() method hangs until the currently running live server 
> stops and this server actually becomes the new live server.
> This is inconsistent with starting a server as slave server, where the start 
> method returns and doesn't wait until the slave took over as live server.
> It also blocks the application that called EmbeddedServer.start() to proceed 
> it's normal operation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1112) EmbeddedJMS.start() doesn't return if shared-store master starts as backup server

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995623#comment-15995623
 ] 

ASF GitHub Bot commented on ARTEMIS-1112:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1246


> EmbeddedJMS.start() doesn't return if shared-store master starts as backup 
> server
> -
>
> Key: ARTEMIS-1112
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1112
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.4, 2.0.0
>Reporter: Bernd Gutjahr
>Priority: Minor
>
> EmbeddedServer.start() doesn't return when a share-store master server has 
> been configured, but at startup another server is already running as live 
> server (i.e. another previously started master).
> In that case, this server becomes a backup server for the currently running 
> live server. The start() method hangs until the currently running live server 
> stops and this server actually becomes the new live server.
> This is inconsistent with starting a server as slave server, where the start 
> method returns and doesn't wait until the slave took over as live server.
> It also blocks the application that called EmbeddedServer.start() to proceed 
> it's normal operation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1141) Validate Karaf features using the karaf plugin

[clebert suconic (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995621#comment-15995621
 ] 

clebert suconic commented on ARTEMIS-1141:
--

I was using mvn -Pdev install -T20 on my machine...

I guess this is not compatible with multi thread. not a big deal.

> Validate Karaf features using the karaf plugin
> --
>
> Key: ARTEMIS-1141
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1141
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: osgi
>Affects Versions: 2.0.0
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.next
>
>
> The Karaf maven plugin provides a validation goal which run the OSGi resolver 
> to ensure that the features can actually be installed in Karaf.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ARTEMIS-1141) Validate Karaf features using the karaf plugin

[Guillaume Nodet (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995615#comment-15995615
 ] 

Guillaume Nodet edited comment on ARTEMIS-1141 at 5/3/17 8:35 PM:
--

I ran the built with tests with no problems.  Did I miss something ?

I missed the ArtemisFeatureTest, but the feature could not be installed, so the 
test is definitely not working very well to detect failures.
To the "how can that be used", the build ensures that you can't break the 
feature installation.  Try removing an important bundle from a feature and 
you'll see the build will break.  If a new package dependency is added which 
cause a new import to be added to one of the bundles, the build will also fail 
fast.


was (Author: gnt):
I ran the built with tests with no problems.  Did I miss something ?

I missed the ArtemisFeatureTest, but the feature can't be installed, so the 
test is definitely not working very well to detect failures.
To the "how can that be used", the build ensures that you can't break the 
feature installation.  Try removing an important bundle from a feature and 
you'll see the build will break.  If a new package dependency is added which 
cause a new import to be added to one of the bundles, the build will also fail 
fast.

> Validate Karaf features using the karaf plugin
> --
>
> Key: ARTEMIS-1141
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1141
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: osgi
>Affects Versions: 2.0.0
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.next
>
>
> The Karaf maven plugin provides a validation goal which run the OSGi resolver 
> to ensure that the features can actually be installed in Karaf.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1141) Validate Karaf features using the karaf plugin

[Guillaume Nodet (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995615#comment-15995615
 ] 

Guillaume Nodet commented on ARTEMIS-1141:
--

I ran the built with tests with no problems.  Did I miss something ?

I missed the ArtemisFeatureTest, but the feature can't be installed, so the 
test is definitely not working very well to detect failures.
To the "how can that be used", the build ensures that you can't break the 
feature installation.  Try removing an important bundle from a feature and 
you'll see the build will break.  If a new package dependency is added which 
cause a new import to be added to one of the bundles, the build will also fail 
fast.

> Validate Karaf features using the karaf plugin
> --
>
> Key: ARTEMIS-1141
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1141
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: osgi
>Affects Versions: 2.0.0
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.next
>
>
> The Karaf maven plugin provides a validation goal which run the OSGi resolver 
> to ensure that the features can actually be installed in Karaf.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-267) AMQP messages without a Header section get persisted despite being non-durable

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995609#comment-15995609
 ] 

ASF subversion and git services commented on ARTEMIS-267:
-

Commit cf3e2bf7f06df833d22f4ae55e7b1308d1800de5 in activemq-artemis's branch 
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=cf3e2bf ]

ARTEMIS-267 Add test for handling of AMQP header and durability

Adds a test that validates that messages that are either lacking a
header or are set to be non-durable are not persisted and are not
recovered on broker restart.  

> AMQP messages without a Header section get persisted despite being non-durable
> --
>
> Key: ARTEMIS-267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-267
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.1.0
>Reporter: Robbie Gemmell
>
> When an AMQP message has no header section, or has a header but contains no 
> explicit value for the durable field, the spec defaults the value to being 
> false / non-durable. If a message is received by the broker without a Header 
> section, it currently gets persisted despite this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-267) AMQP messages without a Header section get persisted despite being non-durable

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995611#comment-15995611
 ] 

ASF GitHub Bot commented on ARTEMIS-267:


Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1248


> AMQP messages without a Header section get persisted despite being non-durable
> --
>
> Key: ARTEMIS-267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-267
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.1.0
>Reporter: Robbie Gemmell
>
> When an AMQP message has no header section, or has a header but contains no 
> explicit value for the durable field, the spec defaults the value to being 
> false / non-durable. If a message is received by the broker without a Header 
> section, it currently gets persisted despite this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1140) Avoid Queue lock on queueQuery

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995605#comment-15995605
 ] 

ASF subversion and git services commented on ARTEMIS-1140:
--

Commit 0146109d6a06f9702f245034a43c49dffc5779bd in activemq-artemis's branch 
refs/heads/master from Clebert Suconic
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=0146109 ]

ARTEMIS-1140: Trivial test fix


> Avoid Queue lock on queueQuery
> --
>
> Key: ARTEMIS-1140
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1140
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.5.4, 2.0.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.5.5, 2.next
>
>
> queueQuery is currently holding a lock on the queue to get a strict message 
> count on the queue.
> In case of high performance scenarios mixed with an anti-pattern on the 
> client with calling queueQuery constantly this will incur on low performance.
> this is an anti-pattern and not much we can do, but we don't need to hold a 
> lock just for that query.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1141) Validate Karaf features using the karaf plugin

[clebert suconic (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995600#comment-15995600
 ] 

clebert suconic commented on ARTEMIS-1141:
--

hmmm.. I have made it pass now...

maybe this should be part of -Pdev

> Validate Karaf features using the karaf plugin
> --
>
> Key: ARTEMIS-1141
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1141
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: osgi
>Affects Versions: 2.0.0
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.next
>
>
> The Karaf maven plugin provides a validation goal which run the OSGi resolver 
> to ensure that the features can actually be installed in Karaf.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1141) Validate Karaf features using the karaf plugin

[clebert suconic (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995587#comment-15995587
 ] 

clebert suconic commented on ARTEMIS-1141:
--

this is actually breaking the build...

We already have ArtemisFeatureTest as part of the testsuite...

I will revert the commit.. as I won't be able to release with it.

> Validate Karaf features using the karaf plugin
> --
>
> Key: ARTEMIS-1141
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1141
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: osgi
>Affects Versions: 2.0.0
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.next
>
>
> The Karaf maven plugin provides a validation goal which run the OSGi resolver 
> to ensure that the features can actually be installed in Karaf.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1141) Validate Karaf features using the karaf plugin

[clebert suconic (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995579#comment-15995579
 ] 

clebert suconic commented on ARTEMIS-1141:
--

or a discuss thread?

how this can be used? 

> Validate Karaf features using the karaf plugin
> --
>
> Key: ARTEMIS-1141
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1141
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: osgi
>Affects Versions: 2.0.0
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.next
>
>
> The Karaf maven plugin provides a validation goal which run the OSGi resolver 
> to ensure that the features can actually be installed in Karaf.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1141) Validate Karaf features using the karaf plugin

[Justin Bertram (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995574#comment-15995574
 ] 

Justin Bertram commented on ARTEMIS-1141:
-

No PR for this, just a straight commit/push?

> Validate Karaf features using the karaf plugin
> --
>
> Key: ARTEMIS-1141
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1141
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: osgi
>Affects Versions: 2.0.0
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.next
>
>
> The Karaf maven plugin provides a validation goal which run the OSGi resolver 
> to ensure that the features can actually be installed in Karaf.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (ARTEMIS-1141) Validate Karaf features using the karaf plugin

[Guillaume Nodet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved ARTEMIS-1141.
--
Resolution: Fixed

https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=commitdiff;h=9e165d17336f23d86dbe34c2c910abfa17cc78c4

> Validate Karaf features using the karaf plugin
> --
>
> Key: ARTEMIS-1141
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1141
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: osgi
>Affects Versions: 2.0.0
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.next
>
>
> The Karaf maven plugin provides a validation goal which run the OSGi resolver 
> to ensure that the features can actually be installed in Karaf.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1140) Avoid Queue lock on queueQuery

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995422#comment-15995422
 ] 

ASF GitHub Bot commented on ARTEMIS-1140:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1247


> Avoid Queue lock on queueQuery
> --
>
> Key: ARTEMIS-1140
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1140
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.5.4, 2.0.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.5.5, 2.next
>
>
> queueQuery is currently holding a lock on the queue to get a strict message 
> count on the queue.
> In case of high performance scenarios mixed with an anti-pattern on the 
> client with calling queueQuery constantly this will incur on low performance.
> this is an anti-pattern and not much we can do, but we don't need to hold a 
> lock just for that query.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-267) AMQP messages without a Header section get persisted despite being non-durable

[Timothy Bish (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995414#comment-15995414
 ] 

Timothy Bish commented on ARTEMIS-267:
--

I've added a test to validate this is fixed, once merged we can close this 
issue.

> AMQP messages without a Header section get persisted despite being non-durable
> --
>
> Key: ARTEMIS-267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-267
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.1.0
>Reporter: Robbie Gemmell
>
> When an AMQP message has no header section, or has a header but contains no 
> explicit value for the durable field, the spec defaults the value to being 
> false / non-durable. If a message is received by the broker without a Header 
> section, it currently gets persisted despite this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-267) AMQP messages without a Header section get persisted despite being non-durable

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995410#comment-15995410
 ] 

ASF GitHub Bot commented on ARTEMIS-267:


GitHub user tabish121 opened a pull request:

https://github.com/apache/activemq-artemis/pull/1248

ARTEMIS-267 Add test for handling of AMQP header and durability

Adds a test that validates that messages that are either lacking a
header or are set to be non-durable are not persisted and are not
recovered on broker restart.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tabish121/activemq-artemis ARTEMIS-267

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1248.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 #1248


commit 30db592fcca9b1ea51765e23b099af8e87d7d8ca
Author: Timothy Bish 
Date:   2017-05-03T18:42:11Z

ARTEMIS-267 Add test for handling of AMQP header and durability

Adds a test that validates that messages that are either lacking a
header or are set to be non-durable are not persisted and are not
recovered on broker restart.




> AMQP messages without a Header section get persisted despite being non-durable
> --
>
> Key: ARTEMIS-267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-267
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.1.0
>Reporter: Robbie Gemmell
>
> When an AMQP message has no header section, or has a header but contains no 
> explicit value for the durable field, the spec defaults the value to being 
> false / non-durable. If a message is received by the broker without a Header 
> section, it currently gets persisted despite this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMQ-6068) RAR - cannot reset clientId on pooled managed connection

[Anders Hanson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995398#comment-15995398
 ] 

Anders Hanson commented on AMQ-6068:


The fix for this bug introduces an unwanted behaviour in our activemq cluster.
We are running JBoss 6.4 with a Java EE application that processes around 25000 
msg per minute throught couple of JMS queues.
The application consumes one message, does some logic and then post a message 
on another queue. 
The applucation is running with XA-transaction enabled.

We recently upgraded from activemq-rar.rar version 5.13.5 to 5.14.5 and noticed 
that the A-MQ cluster started to behave strange,
one issue was that the nodes in the cluster (network of brokers) ran out of 
native memory. 

We have now come to the conclusion that the fix for this issue forces the 
activemq client to send a new ConnectionInfo message
to the broker for every message it processes. This get passed around in the 
cluster via Advisory messages and both memory consumtion
and CPU load went up on all brokers. The information sent in the connectionInfo 
is in our case always the same thing, i.e. we don't set any clientId etc.

There is almost no use having a JCA connection pool for activemq resource 
adapter when it cant avoid sending ConnectionInfo messages.

We have reverted back to 5.13.5 for now.  

> RAR - cannot reset clientId on pooled managed connection
> 
>
> Key: AMQ-6068
> URL: https://issues.apache.org/jira/browse/AMQ-6068
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: RAR
>Affects Versions: 5.12.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.14.0
>
>
> A managed connection returned to the pool has cleanup called, but cleanup is 
> not releasing the underlying activemq connection  info and clientid. On the 
> second attempt to reuse the connection, setting the id fails due to the pre 
> existing state in error.
> {code}[Server:eai01] 17:04:58,073 WARN  
> [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] 
> (jmsListener-734) IJ000613: Throwable while trying to match managed 
> connection, destroying connection: 
> org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@3e11f08f[state=NORMAL
>  managed 
> connection=[org.apache.activemq.ra.ActiveMQManagedConnection@34bc339a,ActiveMQConnection
>  
> {id=ID:macbookpro-2.local-54186-1448868251571-1463:1,clientId=xxx,started=false}]
>  connection handles=0 lastUse=1448874205871 trackByTx=false 
> pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@2f2f39fd pool 
> internal 
> context=SemaphoreArrayListManagedConnectionPool@51eff7c[pool=ActiveMQConnectionFactory]
>  
> xaResource=XAResourceWrapperImpl@623206[xaResource=[org.apache.activemq.ra.ActiveMQManagedConnection$1@64df868a,TransactionContext{transactionId=null,connection=ActiveMQConnection
>  
> {id=ID:macbookpro-2.local-54186-1448868251571-1463:1,clientId=xxx,started=false}}]
>  pad=false overrideRmValue=null productName=ActiveMQ productVersion=5.12.1 
> jndiName=java:/ra/activeMQ/ActiveMQConnectionFactory] txSync=null]: 
> javax.resource.ResourceException: javax.jms.IllegalStateException: Setting 
> clientID on a used Connection is not allowed
> [Server:eai01]at 
> org.apache.activemq.ra.ActiveMQManagedConnectionFactory.matchManagedConnections(ActiveMQManagedConnectionFactory.java:217)
>  [activemq-ra-5.12.1.jar:5.12.1]
> [Server:eai01]at 
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:314)
> [Server:eai01]at 
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:453)
> [Server:eai01]at 
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:425)
> [Server:eai01]at 
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:354)
> [Server:eai01]at 
> org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:368)
> [Server:eai01]at 
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:510)
> [Server:eai01]at 
> org.apache.activemq.ra.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:94)
>  [activemq-ra-5.12.1.jar:5.12.1]
> [Server:eai01]at 
> org.apache.activemq.ra.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:78)
>  [activemq-ra-5.12.1.jar:5.12.1]{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (AMQ-6668) Broker not created by activemq.xml file on offline PC

[Giuseppe Gerla (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Giuseppe Gerla resolved AMQ-6668.
-
Resolution: Duplicate

It is duplicated of 6544

> Broker not created by activemq.xml file on offline PC
> -
>
> Key: AMQ-6668
> URL: https://issues.apache.org/jira/browse/AMQ-6668
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.14.1
> Environment: PC with no connection to internet
>Reporter: Giuseppe Gerla
>Assignee: Christian Schneider
>
> If the PC is not connected to internet, during the parsing of the 
> activemq.xml file, It is not possible to read the schema documents (i.e. 
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd, 
> http://activemq.apache.org/schema/core, etc), so Broker is not created.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-267) AMQP messages without a Header section get persisted despite being non-durable

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995197#comment-15995197
 ] 

Robbie Gemmell commented on ARTEMIS-267:


I'm not sure. I don't even know what I was doing when I noticed it, given how 
long ago it was. Probably best to add a test, or check if one now exists.

> AMQP messages without a Header section get persisted despite being non-durable
> --
>
> Key: ARTEMIS-267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-267
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.1.0
>Reporter: Robbie Gemmell
>
> When an AMQP message has no header section, or has a header but contains no 
> explicit value for the durable field, the spec defaults the value to being 
> false / non-durable. If a message is received by the broker without a Header 
> section, it currently gets persisted despite this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-209) [AMQP] Broker sends frames after SASL failure

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995190#comment-15995190
 ] 

Robbie Gemmell commented on ARTEMIS-209:


Yep. Related to https://issues.apache.org/jira/browse/PROTON-900. Most folks 
seemed to think it was fine to do that, since it shouldnt make any difference 
to the other side (fail is fail..), but I dislike it and raised it anyway. I 
later came to realise it was semi deliberate to allow for other behaviours, 
though perhaps we can find a middle ground for making it less silly the rest of 
the time.

> [AMQP] Broker sends frames after SASL failure
> -
>
> Key: ARTEMIS-209
> URL: https://issues.apache.org/jira/browse/ARTEMIS-209
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: AMQP
>Affects Versions: 1.0.0
> Environment: SASL negotiation over AMQP
>Reporter: Chuck Rolke
>Assignee: Timothy Bish
>
> The client sends bogus credentials to the Artemis server. The server 
> correctly fails with sasl.outcome code: auth(1). So far so good. Then the 
> server sends an AMQP protocol negotiation frame as if everything was OK.
> After failing SASL the server should close the connection.
> Trace file: 
> https://people.apache.org/~chug/artemis/20150821-1/artemis-sasl-fail-but-sends-amqp-header.html
> From the trace:
> {noformat}
> 10.10.1.1:1340  -> 10.10.10.254:5672  ->   init SASL (3): (1.0.0)
> 10.10.1.1:1340  -> 10.10.10.254:5672  ->   method sasl.init
> 10.10.1.1:1340 <-  10.10.10.254:5672 <-init SASL (3): (1.0.0), method 
> sasl.mechanisms, method sasl.outcome
> 10.10.1.1:1340 <-  10.10.10.254:5672 <-init AMQP (0): (1.0.0)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1043) NettyConnector not working with IPv6 address

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995174#comment-15995174
 ] 

ASF GitHub Bot commented on ARTEMIS-1043:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1245


> NettyConnector not working with IPv6 address
> 
>
> Key: ARTEMIS-1043
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1043
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.3
>Reporter: Jeff Mesnil
> Fix For: 1.5.5, 2.next
>
>
> Artemis client doesn't correctly enclose IPv6 address when sending HTTP 
> upgrade packet. 
> According to [RFC2732 | https://www.ietf.org/rfc/rfc2732.txt], section {{2. 
> Literal IPv6 Address Format in URL's Syntax}} and [HTTP header field 
> definition 
> specification|https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html], 
> correct request URL should be enclosed like following one: 
> {{http://[fe80::56ee:75ff:fe47:c83e]}} 
> Following code snippet creates request for URL 
> {{http://fe80::56ee:75ff:fe47:c83e}} 
> {code} 
> HashMap map = new HashMap(); 
> map.put("host", "fe80::56ee:75ff:fe47:c83e"); 
> map.put("port", "8080"); 
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true); 
> TransportConfiguration transportConfiguration = new 
> TransportConfiguration(NettyConnectorFactory.class.getName(), map); 
> ConnectionFactory cf = 
> ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, 
> transportConfiguration); 
>  connection = cf.createConnection(); 
> {code} 
> This works fine when client connects directly to the server. However it may 
> cause problems when Artemis connects to proxy which expects IPv6 address 
> correctly enclosed. 
> Artemis client should detect IPv6 address and enclose it, so it conforms to 
> specification.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1043) NettyConnector not working with IPv6 address

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995168#comment-15995168
 ] 

ASF subversion and git services commented on ARTEMIS-1043:
--

Commit 15b91f039411182aed2b474ebcf899fef03e in activemq-artemis's branch 
refs/heads/master from [~jmesnil]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=15b9133 ]

[ARTEMIS-1043] Support IPv6 in NettyConnector

Wrap the host added to the HTTP request headers with IPV6Util.encloseHost
to ensure that load balancers that reads the header will have a valid
IPv6 address.

JIRA: https://issues.apache.org/jira/browse/ARTEMIS-1043


> NettyConnector not working with IPv6 address
> 
>
> Key: ARTEMIS-1043
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1043
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.3
>Reporter: Jeff Mesnil
> Fix For: 1.5.5, 2.next
>
>
> Artemis client doesn't correctly enclose IPv6 address when sending HTTP 
> upgrade packet. 
> According to [RFC2732 | https://www.ietf.org/rfc/rfc2732.txt], section {{2. 
> Literal IPv6 Address Format in URL's Syntax}} and [HTTP header field 
> definition 
> specification|https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html], 
> correct request URL should be enclosed like following one: 
> {{http://[fe80::56ee:75ff:fe47:c83e]}} 
> Following code snippet creates request for URL 
> {{http://fe80::56ee:75ff:fe47:c83e}} 
> {code} 
> HashMap map = new HashMap(); 
> map.put("host", "fe80::56ee:75ff:fe47:c83e"); 
> map.put("port", "8080"); 
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true); 
> TransportConfiguration transportConfiguration = new 
> TransportConfiguration(NettyConnectorFactory.class.getName(), map); 
> ConnectionFactory cf = 
> ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, 
> transportConfiguration); 
>  connection = cf.createConnection(); 
> {code} 
> This works fine when client connects directly to the server. However it may 
> cause problems when Artemis connects to proxy which expects IPv6 address 
> correctly enclosed. 
> Artemis client should detect IPv6 address and enclose it, so it conforms to 
> specification.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1043) NettyConnector not working with IPv6 address

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995173#comment-15995173
 ] 

ASF subversion and git services commented on ARTEMIS-1043:
--

Commit 64c89b6874a0c72df15397db779ecb817885be35 in activemq-artemis's branch 
refs/heads/1.x from [~jmesnil]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=64c89b6 ]

[ARTEMIS-1043] Support IPv6 in NettyConnector

Wrap the host added to the HTTP request headers with
IPV6Util.encloseHost to ensure that load balancers that reads the header
will have a valid IPv6 address.

JIRA: https://issues.apache.org/jira/browse/ARTEMIS-1043


> NettyConnector not working with IPv6 address
> 
>
> Key: ARTEMIS-1043
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1043
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.3
>Reporter: Jeff Mesnil
> Fix For: 1.5.5, 2.next
>
>
> Artemis client doesn't correctly enclose IPv6 address when sending HTTP 
> upgrade packet. 
> According to [RFC2732 | https://www.ietf.org/rfc/rfc2732.txt], section {{2. 
> Literal IPv6 Address Format in URL's Syntax}} and [HTTP header field 
> definition 
> specification|https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html], 
> correct request URL should be enclosed like following one: 
> {{http://[fe80::56ee:75ff:fe47:c83e]}} 
> Following code snippet creates request for URL 
> {{http://fe80::56ee:75ff:fe47:c83e}} 
> {code} 
> HashMap map = new HashMap(); 
> map.put("host", "fe80::56ee:75ff:fe47:c83e"); 
> map.put("port", "8080"); 
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true); 
> TransportConfiguration transportConfiguration = new 
> TransportConfiguration(NettyConnectorFactory.class.getName(), map); 
> ConnectionFactory cf = 
> ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, 
> transportConfiguration); 
>  connection = cf.createConnection(); 
> {code} 
> This works fine when client connects directly to the server. However it may 
> cause problems when Artemis connects to proxy which expects IPv6 address 
> correctly enclosed. 
> Artemis client should detect IPv6 address and enclose it, so it conforms to 
> specification.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1043) NettyConnector not working with IPv6 address

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995170#comment-15995170
 ] 

ASF GitHub Bot commented on ARTEMIS-1043:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1244


> NettyConnector not working with IPv6 address
> 
>
> Key: ARTEMIS-1043
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1043
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.3
>Reporter: Jeff Mesnil
> Fix For: 1.5.5, 2.next
>
>
> Artemis client doesn't correctly enclose IPv6 address when sending HTTP 
> upgrade packet. 
> According to [RFC2732 | https://www.ietf.org/rfc/rfc2732.txt], section {{2. 
> Literal IPv6 Address Format in URL's Syntax}} and [HTTP header field 
> definition 
> specification|https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html], 
> correct request URL should be enclosed like following one: 
> {{http://[fe80::56ee:75ff:fe47:c83e]}} 
> Following code snippet creates request for URL 
> {{http://fe80::56ee:75ff:fe47:c83e}} 
> {code} 
> HashMap map = new HashMap(); 
> map.put("host", "fe80::56ee:75ff:fe47:c83e"); 
> map.put("port", "8080"); 
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true); 
> TransportConfiguration transportConfiguration = new 
> TransportConfiguration(NettyConnectorFactory.class.getName(), map); 
> ConnectionFactory cf = 
> ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, 
> transportConfiguration); 
>  connection = cf.createConnection(); 
> {code} 
> This works fine when client connects directly to the server. However it may 
> cause problems when Artemis connects to proxy which expects IPv6 address 
> correctly enclosed. 
> Artemis client should detect IPv6 address and enclose it, so it conforms to 
> specification.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (AMQ-6668) Broker not created by activemq.xml file on offline PC

[Christian Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schneider reassigned AMQ-6668:


Assignee: Christian Schneider

> Broker not created by activemq.xml file on offline PC
> -
>
> Key: AMQ-6668
> URL: https://issues.apache.org/jira/browse/AMQ-6668
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.14.1
> Environment: PC with no connection to internet
>Reporter: Giuseppe Gerla
>Assignee: Christian Schneider
>
> If the PC is not connected to internet, during the parsing of the 
> activemq.xml file, It is not possible to read the schema documents (i.e. 
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd, 
> http://activemq.apache.org/schema/core, etc), so Broker is not created.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1043) NettyConnector not working with IPv6 address

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995172#comment-15995172
 ] 

ASF subversion and git services commented on ARTEMIS-1043:
--

Commit 64c89b6874a0c72df15397db779ecb817885be35 in activemq-artemis's branch 
refs/heads/1.x from [~jmesnil]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=64c89b6 ]

[ARTEMIS-1043] Support IPv6 in NettyConnector

Wrap the host added to the HTTP request headers with
IPV6Util.encloseHost to ensure that load balancers that reads the header
will have a valid IPv6 address.

JIRA: https://issues.apache.org/jira/browse/ARTEMIS-1043


> NettyConnector not working with IPv6 address
> 
>
> Key: ARTEMIS-1043
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1043
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.3
>Reporter: Jeff Mesnil
> Fix For: 1.5.5, 2.next
>
>
> Artemis client doesn't correctly enclose IPv6 address when sending HTTP 
> upgrade packet. 
> According to [RFC2732 | https://www.ietf.org/rfc/rfc2732.txt], section {{2. 
> Literal IPv6 Address Format in URL's Syntax}} and [HTTP header field 
> definition 
> specification|https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html], 
> correct request URL should be enclosed like following one: 
> {{http://[fe80::56ee:75ff:fe47:c83e]}} 
> Following code snippet creates request for URL 
> {{http://fe80::56ee:75ff:fe47:c83e}} 
> {code} 
> HashMap map = new HashMap(); 
> map.put("host", "fe80::56ee:75ff:fe47:c83e"); 
> map.put("port", "8080"); 
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true); 
> TransportConfiguration transportConfiguration = new 
> TransportConfiguration(NettyConnectorFactory.class.getName(), map); 
> ConnectionFactory cf = 
> ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, 
> transportConfiguration); 
>  connection = cf.createConnection(); 
> {code} 
> This works fine when client connects directly to the server. However it may 
> cause problems when Artemis connects to proxy which expects IPv6 address 
> correctly enclosed. 
> Artemis client should detect IPv6 address and enclose it, so it conforms to 
> specification.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1043) NettyConnector not working with IPv6 address

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995169#comment-15995169
 ] 

ASF subversion and git services commented on ARTEMIS-1043:
--

Commit 15b91f039411182aed2b474ebcf899fef03e in activemq-artemis's branch 
refs/heads/master from [~jmesnil]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=15b9133 ]

[ARTEMIS-1043] Support IPv6 in NettyConnector

Wrap the host added to the HTTP request headers with IPV6Util.encloseHost
to ensure that load balancers that reads the header will have a valid
IPv6 address.

JIRA: https://issues.apache.org/jira/browse/ARTEMIS-1043


> NettyConnector not working with IPv6 address
> 
>
> Key: ARTEMIS-1043
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1043
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.3
>Reporter: Jeff Mesnil
> Fix For: 1.5.5, 2.next
>
>
> Artemis client doesn't correctly enclose IPv6 address when sending HTTP 
> upgrade packet. 
> According to [RFC2732 | https://www.ietf.org/rfc/rfc2732.txt], section {{2. 
> Literal IPv6 Address Format in URL's Syntax}} and [HTTP header field 
> definition 
> specification|https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html], 
> correct request URL should be enclosed like following one: 
> {{http://[fe80::56ee:75ff:fe47:c83e]}} 
> Following code snippet creates request for URL 
> {{http://fe80::56ee:75ff:fe47:c83e}} 
> {code} 
> HashMap map = new HashMap(); 
> map.put("host", "fe80::56ee:75ff:fe47:c83e"); 
> map.put("port", "8080"); 
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true); 
> TransportConfiguration transportConfiguration = new 
> TransportConfiguration(NettyConnectorFactory.class.getName(), map); 
> ConnectionFactory cf = 
> ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, 
> transportConfiguration); 
>  connection = cf.createConnection(); 
> {code} 
> This works fine when client connects directly to the server. However it may 
> cause problems when Artemis connects to proxy which expects IPv6 address 
> correctly enclosed. 
> Artemis client should detect IPv6 address and enclose it, so it conforms to 
> specification.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMQ-6668) Broker not created by activemq.xml file on offline PC

[Giuseppe Gerla (JIRA)]

Giuseppe Gerla created AMQ-6668:
---

 Summary: Broker not created by activemq.xml file on offline PC
 Key: AMQ-6668
 URL: https://issues.apache.org/jira/browse/AMQ-6668
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.14.1
 Environment: PC with no connection to internet
Reporter: Giuseppe Gerla


If the PC is not connected to internet, during the parsing of the activemq.xml 
file, It is not possible to read the schema documents (i.e. 
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd, 
http://activemq.apache.org/schema/core, etc), so Broker is not created.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-898) Artemis Plugin Support

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995151#comment-15995151
 ] 

ASF subversion and git services commented on ARTEMIS-898:
-

Commit 1e1ede84c0483099f27741bc046ef95c08e1d090 in activemq-artemis's branch 
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=1e1ede8 ]

ARTEMIS-898 - Adding Plugin Support

Adding a new ActievMQServerPlugin interface to support adding custom
behavior to the broker at certain events such as connection or session
creation.

https://issues.apache.org/jira/browse/ARTEMIS-898


> Artemis Plugin Support
> --
>
> Key: ARTEMIS-898
> URL: https://issues.apache.org/jira/browse/ARTEMIS-898
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 2.next
>Reporter: Matt Pavlovich
>Assignee: Christopher L. Shannon
> Fix For: 2.next
>
>
> ActiveMQ 5.x currently has a number of extension points via Plugins, or 
> simple Spring bean wiring. Artemis should provide extension points to meet 
> various requirements.
> The protocol interceptors are handy, but also limiting in that each plugin 
> would need to be implemented for every protocol. Feels like there should be 
> defined extension point(s) within the broker.
> Core Broker Plugins:
> 1. Message header / property manipulation
> 2. Message body manipulation
> 3. Activity tracing (broker becomes master, network bridge start/stop, 
> message rcv/sent/ack/rollback, consumer/producer add/remove, broker 
> add/remove, destination add/remove, connection add/remove, fast producer/slow 
> consumer, etc)
>  a. Audit / trace logs
>  b. Triggers based on events
> ref: 
> http://activemq.apache.org/maven/apidocs/org/apache/activemq/broker/MutableBrokerFilter.html
> Additional extension point:
>  DestinationPolicies: Ability to impact destination behaviors for dispatch, 
> subscription policies, etc.
> Side benefit regarding Advisory Support:
> If the plugin framework can get squared away, an upside could be that 
> Advisory support becomes a plugin vs an ingrained feature and we could have 
> more control over configuration and behavior.
> From ARTEMIS-17
> Support for using Camel as an interceptor/plugin



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-1140) Avoid Queue lock on queueQuery

[clebert suconic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

clebert suconic updated ARTEMIS-1140:
-
Description: 
queueQuery is currently holding a lock on the queue to get a strict message 
count on the queue.

In case of high performance scenarios mixed with an anti-pattern on the client 
with calling queueQuery constantly this will incur on low performance.

this is an anti-pattern and not much we can do, but we don't need to hold a 
lock just for that query.

> Avoid Queue lock on queueQuery
> --
>
> Key: ARTEMIS-1140
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1140
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.5.4, 2.0.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.5.5, 2.next
>
>
> queueQuery is currently holding a lock on the queue to get a strict message 
> count on the queue.
> In case of high performance scenarios mixed with an anti-pattern on the 
> client with calling queueQuery constantly this will incur on low performance.
> this is an anti-pattern and not much we can do, but we don't need to hold a 
> lock just for that query.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (ARTEMIS-1140) Avoid Queue lock on queueQuery

[clebert suconic (JIRA)]

clebert suconic created ARTEMIS-1140:


 Summary: Avoid Queue lock on queueQuery
 Key: ARTEMIS-1140
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1140
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 2.0.0, 1.5.4
Reporter: clebert suconic
Assignee: clebert suconic
 Fix For: 1.5.5, 2.next






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-209) [AMQP] Broker sends frames after SASL failure

[Timothy Bish (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995140#comment-15995140
 ] 

Timothy Bish commented on ARTEMIS-209:
--

This would likely require a change to Proton-J to prevent from happening as the 
header is being emitted from Proton-J following the SASL exchange.  

> [AMQP] Broker sends frames after SASL failure
> -
>
> Key: ARTEMIS-209
> URL: https://issues.apache.org/jira/browse/ARTEMIS-209
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: AMQP
>Affects Versions: 1.0.0
> Environment: SASL negotiation over AMQP
>Reporter: Chuck Rolke
>Assignee: Timothy Bish
>
> The client sends bogus credentials to the Artemis server. The server 
> correctly fails with sasl.outcome code: auth(1). So far so good. Then the 
> server sends an AMQP protocol negotiation frame as if everything was OK.
> After failing SASL the server should close the connection.
> Trace file: 
> https://people.apache.org/~chug/artemis/20150821-1/artemis-sasl-fail-but-sends-amqp-header.html
> From the trace:
> {noformat}
> 10.10.1.1:1340  -> 10.10.10.254:5672  ->   init SASL (3): (1.0.0)
> 10.10.1.1:1340  -> 10.10.10.254:5672  ->   method sasl.init
> 10.10.1.1:1340 <-  10.10.10.254:5672 <-init SASL (3): (1.0.0), method 
> sasl.mechanisms, method sasl.outcome
> 10.10.1.1:1340 <-  10.10.10.254:5672 <-init AMQP (0): (1.0.0)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1112) EmbeddedJMS.start() doesn't return if shared-store master starts as backup server

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995117#comment-15995117
 ] 

ASF GitHub Bot commented on ARTEMIS-1112:
-

GitHub user bgutjahr opened a pull request:

https://github.com/apache/activemq-artemis/pull/1246

ARTEMIS-1112: Added wait-for-activation option to shared-store master config

Added a wait-for-activation option to shared-store master HA policies.
This option is enabled by default to ensure unchanged server startup 
behavior.

If this option is enabled, ActiveMQServer.start() with a shared-store 
master server will not return
before the server has been activated.
If this options is disabled, start() will return after a background 
activation thread has been started.
The caller can use waitForActivation() to wait until server is activated, 
or just check the current activation status.

This is slightly different from the previous proposal of having a 
wait-for-failback option to just run backup startup in the background in case 
there is already another live server running. The implementation for the 
previous idea had a race condition: if 2 masters were started simultaneously, 
both might not see the other and one would still infinitely wait to obtain the 
live lock. So my new solution is to decouple startup into a background 
activation thread in all cases, similar to how a backup server is started. I 
have called the option wait-for-activation to be aligned with the 
waitForActivation() method.

Please run the integration tests, since many of then fail on Windows. I 
hope I didn't break something else.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bgutjahr/activemq-artemis 
enhanced-shared-store

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1246.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 #1246


commit 481486d14c4a9f27ba55ec31bcda188e4aaa9542
Author: Bernd Gutjahr 
Date:   2017-05-03T12:46:47Z

ARTEMIS-1112: Added wait-for-activation option to shared-store-master config

Added a wait-for-activation option to shared-store master HA policies.
This option is enabled by default to ensure unchanged server startup 
behavior.

If this option is enabled, ActiveMQServer.start() with a shared-store 
master server will not return
before the server has been activated.
If this options is disabled, start() will return after a background 
activation thread has been started.
The caller can use waitForActivation() to wait until server is activated, 
or just check the current activation status.




> EmbeddedJMS.start() doesn't return if shared-store master starts as backup 
> server
> -
>
> Key: ARTEMIS-1112
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1112
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.4, 2.0.0
>Reporter: Bernd Gutjahr
>Priority: Minor
>
> EmbeddedServer.start() doesn't return when a share-store master server has 
> been configured, but at startup another server is already running as live 
> server (i.e. another previously started master).
> In that case, this server becomes a backup server for the currently running 
> live server. The start() method hangs until the currently running live server 
> stops and this server actually becomes the new live server.
> This is inconsistent with starting a server as slave server, where the start 
> method returns and doesn't wait until the slave took over as live server.
> It also blocks the application that called EmbeddedServer.start() to proceed 
> it's normal operation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMQCLI-3) Create a CLI tool to export a KahaDB store to Artemis XML format

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQCLI-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995102#comment-15995102
 ] 

ASF subversion and git services commented on AMQCLI-3:
--

Commit fc20f15942ce52b0e6449425aff0b49bfef9ea85 in activemq-cli-tools's branch 
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-cli-tools.git;h=fc20f15 ]

AMQCLI-3 - Add LICENSE and NOTICE to binary


> Create a CLI tool to export a KahaDB store to Artemis XML format
> 
>
> Key: AMQCLI-3
> URL: https://issues.apache.org/jira/browse/AMQCLI-3
> Project: ActiveMQ CLI Tools
>  Issue Type: New Feature
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
> Fix For: 0.1.0
>
>
> This is the main Jira to support the creation of a tool to export a KahaDB 
> store into XML that Artemis can import.  There will be subtasks created for 
> this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-898) Artemis Plugin Support

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995064#comment-15995064
 ] 

ASF GitHub Bot commented on ARTEMIS-898:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1242
  
@cshannon that's good.. thanks

I was going to use:
```sh
./scripts/checkout-PR.sh 1242
# ammend myself here
./scripts/merge-branch.sh 1242
```


But I will let you do then.


> Artemis Plugin Support
> --
>
> Key: ARTEMIS-898
> URL: https://issues.apache.org/jira/browse/ARTEMIS-898
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 2.next
>Reporter: Matt Pavlovich
>Assignee: Christopher L. Shannon
> Fix For: 2.next
>
>
> ActiveMQ 5.x currently has a number of extension points via Plugins, or 
> simple Spring bean wiring. Artemis should provide extension points to meet 
> various requirements.
> The protocol interceptors are handy, but also limiting in that each plugin 
> would need to be implemented for every protocol. Feels like there should be 
> defined extension point(s) within the broker.
> Core Broker Plugins:
> 1. Message header / property manipulation
> 2. Message body manipulation
> 3. Activity tracing (broker becomes master, network bridge start/stop, 
> message rcv/sent/ack/rollback, consumer/producer add/remove, broker 
> add/remove, destination add/remove, connection add/remove, fast producer/slow 
> consumer, etc)
>  a. Audit / trace logs
>  b. Triggers based on events
> ref: 
> http://activemq.apache.org/maven/apidocs/org/apache/activemq/broker/MutableBrokerFilter.html
> Additional extension point:
>  DestinationPolicies: Ability to impact destination behaviors for dispatch, 
> subscription policies, etc.
> Side benefit regarding Advisory Support:
> If the plugin framework can get squared away, an upside could be that 
> Advisory support becomes a plugin vs an ingrained feature and we could have 
> more control over configuration and behavior.
> From ARTEMIS-17
> Support for using Camel as an interceptor/plugin



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-898) Artemis Plugin Support

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995063#comment-15995063
 ] 

ASF GitHub Bot commented on ARTEMIS-898:


Github user cshannon commented on the issue:

https://github.com/apache/activemq-artemis/pull/1242
  
@clebertsuconic - should be good to go, i squashed the commits and I 
rebased against the latest in master


> Artemis Plugin Support
> --
>
> Key: ARTEMIS-898
> URL: https://issues.apache.org/jira/browse/ARTEMIS-898
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 2.next
>Reporter: Matt Pavlovich
>Assignee: Christopher L. Shannon
> Fix For: 2.next
>
>
> ActiveMQ 5.x currently has a number of extension points via Plugins, or 
> simple Spring bean wiring. Artemis should provide extension points to meet 
> various requirements.
> The protocol interceptors are handy, but also limiting in that each plugin 
> would need to be implemented for every protocol. Feels like there should be 
> defined extension point(s) within the broker.
> Core Broker Plugins:
> 1. Message header / property manipulation
> 2. Message body manipulation
> 3. Activity tracing (broker becomes master, network bridge start/stop, 
> message rcv/sent/ack/rollback, consumer/producer add/remove, broker 
> add/remove, destination add/remove, connection add/remove, fast producer/slow 
> consumer, etc)
>  a. Audit / trace logs
>  b. Triggers based on events
> ref: 
> http://activemq.apache.org/maven/apidocs/org/apache/activemq/broker/MutableBrokerFilter.html
> Additional extension point:
>  DestinationPolicies: Ability to impact destination behaviors for dispatch, 
> subscription policies, etc.
> Side benefit regarding Advisory Support:
> If the plugin framework can get squared away, an upside could be that 
> Advisory support becomes a plugin vs an ingrained feature and we could have 
> more control over configuration and behavior.
> From ARTEMIS-17
> Support for using Camel as an interceptor/plugin



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-898) Artemis Plugin Support

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995066#comment-15995066
 ] 

ASF GitHub Bot commented on ARTEMIS-898:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1242
  
you already did.. thanks...

^^ just to let you know we can use this script for intermediate rebases


> Artemis Plugin Support
> --
>
> Key: ARTEMIS-898
> URL: https://issues.apache.org/jira/browse/ARTEMIS-898
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 2.next
>Reporter: Matt Pavlovich
>Assignee: Christopher L. Shannon
> Fix For: 2.next
>
>
> ActiveMQ 5.x currently has a number of extension points via Plugins, or 
> simple Spring bean wiring. Artemis should provide extension points to meet 
> various requirements.
> The protocol interceptors are handy, but also limiting in that each plugin 
> would need to be implemented for every protocol. Feels like there should be 
> defined extension point(s) within the broker.
> Core Broker Plugins:
> 1. Message header / property manipulation
> 2. Message body manipulation
> 3. Activity tracing (broker becomes master, network bridge start/stop, 
> message rcv/sent/ack/rollback, consumer/producer add/remove, broker 
> add/remove, destination add/remove, connection add/remove, fast producer/slow 
> consumer, etc)
>  a. Audit / trace logs
>  b. Triggers based on events
> ref: 
> http://activemq.apache.org/maven/apidocs/org/apache/activemq/broker/MutableBrokerFilter.html
> Additional extension point:
>  DestinationPolicies: Ability to impact destination behaviors for dispatch, 
> subscription policies, etc.
> Side benefit regarding Advisory Support:
> If the plugin framework can get squared away, an upside could be that 
> Advisory support becomes a plugin vs an ingrained feature and we could have 
> more control over configuration and behavior.
> From ARTEMIS-17
> Support for using Camel as an interceptor/plugin



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-898) Artemis Plugin Support

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995054#comment-15995054
 ] 

ASF GitHub Bot commented on ARTEMIS-898:


Github user cshannon commented on the issue:

https://github.com/apache/activemq-artemis/pull/1242
  
I'll rebase, let me do that real quick.


> Artemis Plugin Support
> --
>
> Key: ARTEMIS-898
> URL: https://issues.apache.org/jira/browse/ARTEMIS-898
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 2.next
>Reporter: Matt Pavlovich
>Assignee: Christopher L. Shannon
> Fix For: 2.next
>
>
> ActiveMQ 5.x currently has a number of extension points via Plugins, or 
> simple Spring bean wiring. Artemis should provide extension points to meet 
> various requirements.
> The protocol interceptors are handy, but also limiting in that each plugin 
> would need to be implemented for every protocol. Feels like there should be 
> defined extension point(s) within the broker.
> Core Broker Plugins:
> 1. Message header / property manipulation
> 2. Message body manipulation
> 3. Activity tracing (broker becomes master, network bridge start/stop, 
> message rcv/sent/ack/rollback, consumer/producer add/remove, broker 
> add/remove, destination add/remove, connection add/remove, fast producer/slow 
> consumer, etc)
>  a. Audit / trace logs
>  b. Triggers based on events
> ref: 
> http://activemq.apache.org/maven/apidocs/org/apache/activemq/broker/MutableBrokerFilter.html
> Additional extension point:
>  DestinationPolicies: Ability to impact destination behaviors for dispatch, 
> subscription policies, etc.
> Side benefit regarding Advisory Support:
> If the plugin framework can get squared away, an upside could be that 
> Advisory support becomes a plugin vs an ingrained feature and we could have 
> more control over configuration and behavior.
> From ARTEMIS-17
> Support for using Camel as an interceptor/plugin



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-898) Artemis Plugin Support

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995052#comment-15995052
 ] 

ASF GitHub Bot commented on ARTEMIS-898:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1242
  
@cshannon since we didn't merge this yet, I would rebase -i, and fix this 
commit on the previous.

Ok? or you want to keep it separate?


> Artemis Plugin Support
> --
>
> Key: ARTEMIS-898
> URL: https://issues.apache.org/jira/browse/ARTEMIS-898
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 2.next
>Reporter: Matt Pavlovich
>Assignee: Christopher L. Shannon
> Fix For: 2.next
>
>
> ActiveMQ 5.x currently has a number of extension points via Plugins, or 
> simple Spring bean wiring. Artemis should provide extension points to meet 
> various requirements.
> The protocol interceptors are handy, but also limiting in that each plugin 
> would need to be implemented for every protocol. Feels like there should be 
> defined extension point(s) within the broker.
> Core Broker Plugins:
> 1. Message header / property manipulation
> 2. Message body manipulation
> 3. Activity tracing (broker becomes master, network bridge start/stop, 
> message rcv/sent/ack/rollback, consumer/producer add/remove, broker 
> add/remove, destination add/remove, connection add/remove, fast producer/slow 
> consumer, etc)
>  a. Audit / trace logs
>  b. Triggers based on events
> ref: 
> http://activemq.apache.org/maven/apidocs/org/apache/activemq/broker/MutableBrokerFilter.html
> Additional extension point:
>  DestinationPolicies: Ability to impact destination behaviors for dispatch, 
> subscription policies, etc.
> Side benefit regarding Advisory Support:
> If the plugin framework can get squared away, an upside could be that 
> Advisory support becomes a plugin vs an ingrained feature and we could have 
> more control over configuration and behavior.
> From ARTEMIS-17
> Support for using Camel as an interceptor/plugin



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-209) [AMQP] Broker sends frames after SASL failure

[clebert suconic (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995043#comment-15995043
 ] 

clebert suconic commented on ARTEMIS-209:
-

[~chug] Tim fixed something on master. can you try master?

> [AMQP] Broker sends frames after SASL failure
> -
>
> Key: ARTEMIS-209
> URL: https://issues.apache.org/jira/browse/ARTEMIS-209
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: AMQP
>Affects Versions: 1.0.0
> Environment: SASL negotiation over AMQP
>Reporter: Chuck Rolke
>Assignee: Timothy Bish
>
> The client sends bogus credentials to the Artemis server. The server 
> correctly fails with sasl.outcome code: auth(1). So far so good. Then the 
> server sends an AMQP protocol negotiation frame as if everything was OK.
> After failing SASL the server should close the connection.
> Trace file: 
> https://people.apache.org/~chug/artemis/20150821-1/artemis-sasl-fail-but-sends-amqp-header.html
> From the trace:
> {noformat}
> 10.10.1.1:1340  -> 10.10.10.254:5672  ->   init SASL (3): (1.0.0)
> 10.10.1.1:1340  -> 10.10.10.254:5672  ->   method sasl.init
> 10.10.1.1:1340 <-  10.10.10.254:5672 <-init SASL (3): (1.0.0), method 
> sasl.mechanisms, method sasl.outcome
> 10.10.1.1:1340 <-  10.10.10.254:5672 <-init AMQP (0): (1.0.0)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1102) Implement cert-based auth for OpenWire

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994932#comment-15994932
 ] 

ASF subversion and git services commented on ARTEMIS-1102:
--

Commit 2968e0a7dac85ad08fe34552e274f329e695fd94 in activemq-artemis's branch 
refs/heads/master from Clebert Suconic
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=2968e0a ]

ARTEMIS-1102 Fixing Openwire test after security change


> Implement cert-based auth for OpenWire
> --
>
> Key: ARTEMIS-1102
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1102
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: OpenWire
>Affects Versions: 2.0.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 2.next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (ARTEMIS-209) [AMQP] Broker sends frames after SASL failure

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish reassigned ARTEMIS-209:


Assignee: Timothy Bish

> [AMQP] Broker sends frames after SASL failure
> -
>
> Key: ARTEMIS-209
> URL: https://issues.apache.org/jira/browse/ARTEMIS-209
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: AMQP
>Affects Versions: 1.0.0
> Environment: SASL negotiation over AMQP
>Reporter: Chuck Rolke
>Assignee: Timothy Bish
>
> The client sends bogus credentials to the Artemis server. The server 
> correctly fails with sasl.outcome code: auth(1). So far so good. Then the 
> server sends an AMQP protocol negotiation frame as if everything was OK.
> After failing SASL the server should close the connection.
> Trace file: 
> https://people.apache.org/~chug/artemis/20150821-1/artemis-sasl-fail-but-sends-amqp-header.html
> From the trace:
> {noformat}
> 10.10.1.1:1340  -> 10.10.10.254:5672  ->   init SASL (3): (1.0.0)
> 10.10.1.1:1340  -> 10.10.10.254:5672  ->   method sasl.init
> 10.10.1.1:1340 <-  10.10.10.254:5672 <-init SASL (3): (1.0.0), method 
> sasl.mechanisms, method sasl.outcome
> 10.10.1.1:1340 <-  10.10.10.254:5672 <-init AMQP (0): (1.0.0)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-898) Artemis Plugin Support

[clebert suconic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

clebert suconic updated ARTEMIS-898:

Affects Version/s: 2.next

> Artemis Plugin Support
> --
>
> Key: ARTEMIS-898
> URL: https://issues.apache.org/jira/browse/ARTEMIS-898
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 2.next
>Reporter: Matt Pavlovich
>Assignee: Christopher L. Shannon
> Fix For: 2.next
>
>
> ActiveMQ 5.x currently has a number of extension points via Plugins, or 
> simple Spring bean wiring. Artemis should provide extension points to meet 
> various requirements.
> The protocol interceptors are handy, but also limiting in that each plugin 
> would need to be implemented for every protocol. Feels like there should be 
> defined extension point(s) within the broker.
> Core Broker Plugins:
> 1. Message header / property manipulation
> 2. Message body manipulation
> 3. Activity tracing (broker becomes master, network bridge start/stop, 
> message rcv/sent/ack/rollback, consumer/producer add/remove, broker 
> add/remove, destination add/remove, connection add/remove, fast producer/slow 
> consumer, etc)
>  a. Audit / trace logs
>  b. Triggers based on events
> ref: 
> http://activemq.apache.org/maven/apidocs/org/apache/activemq/broker/MutableBrokerFilter.html
> Additional extension point:
>  DestinationPolicies: Ability to impact destination behaviors for dispatch, 
> subscription policies, etc.
> Side benefit regarding Advisory Support:
> If the plugin framework can get squared away, an upside could be that 
> Advisory support becomes a plugin vs an ingrained feature and we could have 
> more control over configuration and behavior.
> From ARTEMIS-17
> Support for using Camel as an interceptor/plugin



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (ARTEMIS-898) Artemis Plugin Support

[clebert suconic (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

clebert suconic reassigned ARTEMIS-898:
---

Assignee: Christopher L. Shannon

> Artemis Plugin Support
> --
>
> Key: ARTEMIS-898
> URL: https://issues.apache.org/jira/browse/ARTEMIS-898
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 2.next
>Reporter: Matt Pavlovich
>Assignee: Christopher L. Shannon
> Fix For: 2.next
>
>
> ActiveMQ 5.x currently has a number of extension points via Plugins, or 
> simple Spring bean wiring. Artemis should provide extension points to meet 
> various requirements.
> The protocol interceptors are handy, but also limiting in that each plugin 
> would need to be implemented for every protocol. Feels like there should be 
> defined extension point(s) within the broker.
> Core Broker Plugins:
> 1. Message header / property manipulation
> 2. Message body manipulation
> 3. Activity tracing (broker becomes master, network bridge start/stop, 
> message rcv/sent/ack/rollback, consumer/producer add/remove, broker 
> add/remove, destination add/remove, connection add/remove, fast producer/slow 
> consumer, etc)
>  a. Audit / trace logs
>  b. Triggers based on events
> ref: 
> http://activemq.apache.org/maven/apidocs/org/apache/activemq/broker/MutableBrokerFilter.html
> Additional extension point:
>  DestinationPolicies: Ability to impact destination behaviors for dispatch, 
> subscription policies, etc.
> Side benefit regarding Advisory Support:
> If the plugin framework can get squared away, an upside could be that 
> Advisory support becomes a plugin vs an ingrained feature and we could have 
> more control over configuration and behavior.
> From ARTEMIS-17
> Support for using Camel as an interceptor/plugin



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-898) Artemis Plugin Support

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994720#comment-15994720
 ] 

ASF GitHub Bot commented on ARTEMIS-898:


Github user cshannon commented on the issue:

https://github.com/apache/activemq-artemis/pull/1242
  
@clebertsuconic - I added a second commit to address the performance 
concerns, the lambda expressions should now be avoided if there are no 
registered plugins. The JVM should skip the lambda creation during the method 
call if the hasBrokerPlugins() check is false.


> Artemis Plugin Support
> --
>
> Key: ARTEMIS-898
> URL: https://issues.apache.org/jira/browse/ARTEMIS-898
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Matt Pavlovich
> Fix For: 2.next
>
>
> ActiveMQ 5.x currently has a number of extension points via Plugins, or 
> simple Spring bean wiring. Artemis should provide extension points to meet 
> various requirements.
> The protocol interceptors are handy, but also limiting in that each plugin 
> would need to be implemented for every protocol. Feels like there should be 
> defined extension point(s) within the broker.
> Core Broker Plugins:
> 1. Message header / property manipulation
> 2. Message body manipulation
> 3. Activity tracing (broker becomes master, network bridge start/stop, 
> message rcv/sent/ack/rollback, consumer/producer add/remove, broker 
> add/remove, destination add/remove, connection add/remove, fast producer/slow 
> consumer, etc)
>  a. Audit / trace logs
>  b. Triggers based on events
> ref: 
> http://activemq.apache.org/maven/apidocs/org/apache/activemq/broker/MutableBrokerFilter.html
> Additional extension point:
>  DestinationPolicies: Ability to impact destination behaviors for dispatch, 
> subscription policies, etc.
> Side benefit regarding Advisory Support:
> If the plugin framework can get squared away, an upside could be that 
> Advisory support becomes a plugin vs an ingrained feature and we could have 
> more control over configuration and behavior.
> From ARTEMIS-17
> Support for using Camel as an interceptor/plugin



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-898) Artemis Plugin Support

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994698#comment-15994698
 ] 

ASF GitHub Bot commented on ARTEMIS-898:


Github user cshannon commented on the issue:

https://github.com/apache/activemq-artemis/pull/1242
  
Yeah I thought about that but wasn't sure how much of a difference it would 
really make in terms of real performance and how the JVM will optimize.  I was 
trying to keep the code clean and not have to wrap every plugin call with an 
if/else check.

What about if I did something like this...replace:

`callPlugins(plugin -> plugin.afterCreateSession(session));`

with 

`callPlugins(getBrokerPlugins().size() > 0 ? plugin -> 
plugin.afterCreateSession(session) : null);`

and then the callPlugins method could drop the redundant size check.


> Artemis Plugin Support
> --
>
> Key: ARTEMIS-898
> URL: https://issues.apache.org/jira/browse/ARTEMIS-898
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Matt Pavlovich
> Fix For: 2.next
>
>
> ActiveMQ 5.x currently has a number of extension points via Plugins, or 
> simple Spring bean wiring. Artemis should provide extension points to meet 
> various requirements.
> The protocol interceptors are handy, but also limiting in that each plugin 
> would need to be implemented for every protocol. Feels like there should be 
> defined extension point(s) within the broker.
> Core Broker Plugins:
> 1. Message header / property manipulation
> 2. Message body manipulation
> 3. Activity tracing (broker becomes master, network bridge start/stop, 
> message rcv/sent/ack/rollback, consumer/producer add/remove, broker 
> add/remove, destination add/remove, connection add/remove, fast producer/slow 
> consumer, etc)
>  a. Audit / trace logs
>  b. Triggers based on events
> ref: 
> http://activemq.apache.org/maven/apidocs/org/apache/activemq/broker/MutableBrokerFilter.html
> Additional extension point:
>  DestinationPolicies: Ability to impact destination behaviors for dispatch, 
> subscription policies, etc.
> Side benefit regarding Advisory Support:
> If the plugin framework can get squared away, an upside could be that 
> Advisory support becomes a plugin vs an ingrained feature and we could have 
> more control over configuration and behavior.
> From ARTEMIS-17
> Support for using Camel as an interceptor/plugin



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMQ-2100) Concurrent Modification of Delivered Messages in MessageConsumer.dispose()

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994690#comment-15994690
 ] 

ASF subversion and git services commented on AMQ-2100:
--

Commit 35f30102a6d2083bd640f86f30abffc536863458 in activemq's branch 
refs/heads/master from [~gtully]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=35f3010 ]

[AMQ-2100] fix for intermittent ci failure


> Concurrent Modification of Delivered Messages in MessageConsumer.dispose()
> --
>
> Key: AMQ-2100
> URL: https://issues.apache.org/jira/browse/AMQ-2100
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.2.0
>Reporter: Rob Davies
>Assignee: Rob Davies
> Fix For: 5.3.0
>
>
> See thread on ActiveMQ user list: 
> http://www.nabble.com/ConcurrentModificationException-while-closing-consumer-td21867250.html#a21924323



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMQ-6465) Memory usage incorrectly increases when messages are forwarded over a bridge for a durable subscription

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994684#comment-15994684
 ] 

ASF subversion and git services commented on AMQ-6465:
--

Commit c4a1346875dc40c1469e5b9625efe73eccb4b081 in activemq's branch 
refs/heads/master from [~gtully]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=c4a1346 ]

[AMQ-6465] fix up test interplay - clean on start and consume what is produced


> Memory usage incorrectly increases when messages are forwarded over a bridge 
> for a durable subscription
> ---
>
> Key: AMQ-6465
> URL: https://issues.apache.org/jira/browse/AMQ-6465
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, networkbridge
>Affects Versions: 5.14.1
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
> Fix For: 5.15.0, 5.14.2
>
>
> There is an issue with duplicate message suppression for durable 
> subscriptions over a network bridge that is causing the memory usage counter 
> to grow and never shrink.  The issue is that when the message is checked 
> against the network bridge filter, a reference to the message is incremented 
> (which increases the memory usage counter) but then that reference is never 
> decremented so the memory usage doesn't decrease as it should.  The actual 
> memory is freed but the counter continues to grow until it reaches the 
> configured maximum at which point the broker can't do any work because it 
> thinks the memory is full.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMQ-6667) Many instances of "duplicate message ... from cursor" redirecting to dlq

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994645#comment-15994645
 ] 

ASF subversion and git services commented on AMQ-6667:
--

Commit a0ba0bf4c6beaf50ce5e021ef5e4d493119bb1ef in activemq's branch 
refs/heads/master from [~gtully]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=a0ba0bf ]

[AMQ-6667] gate cursor cache enablement on a single pending send and tidy up 
setbatch to always check outstanding async future list. Fix and test


> Many instances of "duplicate message ... from cursor" redirecting to dlq
> 
>
> Key: AMQ-6667
> URL: https://issues.apache.org/jira/browse/AMQ-6667
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: KahaDB
>Affects Versions: 5.14.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.15.0
>
>
> In a high throughput scenario on a single destination there can be many 
> warnings of this kind:
> {code}
> [2017-03-21 09:51:37,548] WARN ActiveMQ BrokerService[localhost] Task-5 Queue 
> - queue://TEST, subscriptions=10, memory=102%, size=399, 
> pending=0, duplicate message ActiveMQTextMessage {commandId = 72, 
> responseRequired = true, 
> messageId = ID:Mac.fritz.box-64479-1490086286066-183:1:1:1:68, 
> originalDestination = null, originalTransactionId = null, 
> producerId = ID:Mac.fritz.box-64479-1490086286066-183:1:1:1, destination = 
> queue://TEST, transactionId = null, expiration = 0, 
> timestamp = 1490086297427, arrival = 0, brokerInTime = 1490086297427, 
> brokerOutTime = 1490086297427, correlationId = null, replyTo = null, 
> persistent = true, 
> type = null, priority = 4, groupID = null, groupSequence = 0, 
> targetConsumerId = null, compressed = false, userID = null, 
> content = org.apache.activemq.util.ByteSequence@8672edc, marshalledProperties 
> = null, dataStructure = null, redeliveryCounter = 0, size = 50216, properties 
> = null, 
> readOnlyProperties = false, readOnlyBody = false, droppable = false, 
> jmsXGroupFirstForConsumer = false, text = ...} 
> from cursor, is cursor audit disabled or too constrained? Redirecting to dlq
> {code}
> The broker loads messages twice into the cursor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMQ-6667) Many instances of "duplicate message ... from cursor" redirecting to dlq

[Gary Tully (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994642#comment-15994642
 ] 

Gary Tully commented on AMQ-6667:
-

increasing the audit capacity; policyEntry maxProducersToAudit=200 ensures the 
cursor audit tracks up to 200 producers and traps the duplicate from the store. 
In addition, disabling concurrentStoreAndDispatch avoids the issue.

The root cause is enabling the cursor cache when there are pending sends 
leaving a possible scenario where a sync send is lost behind sufficient async 
sends that fill the cache. Reverting to the store in this case results in 
duplicates.

> Many instances of "duplicate message ... from cursor" redirecting to dlq
> 
>
> Key: AMQ-6667
> URL: https://issues.apache.org/jira/browse/AMQ-6667
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: KahaDB
>Affects Versions: 5.14.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.15.0
>
>
> In a high throughput scenario on a single destination there can be many 
> warnings of this kind:
> {code}
> [2017-03-21 09:51:37,548] WARN ActiveMQ BrokerService[localhost] Task-5 Queue 
> - queue://TEST, subscriptions=10, memory=102%, size=399, 
> pending=0, duplicate message ActiveMQTextMessage {commandId = 72, 
> responseRequired = true, 
> messageId = ID:Mac.fritz.box-64479-1490086286066-183:1:1:1:68, 
> originalDestination = null, originalTransactionId = null, 
> producerId = ID:Mac.fritz.box-64479-1490086286066-183:1:1:1, destination = 
> queue://TEST, transactionId = null, expiration = 0, 
> timestamp = 1490086297427, arrival = 0, brokerInTime = 1490086297427, 
> brokerOutTime = 1490086297427, correlationId = null, replyTo = null, 
> persistent = true, 
> type = null, priority = 4, groupID = null, groupSequence = 0, 
> targetConsumerId = null, compressed = false, userID = null, 
> content = org.apache.activemq.util.ByteSequence@8672edc, marshalledProperties 
> = null, dataStructure = null, redeliveryCounter = 0, size = 50216, properties 
> = null, 
> readOnlyProperties = false, readOnlyBody = false, droppable = false, 
> jmsXGroupFirstForConsumer = false, text = ...} 
> from cursor, is cursor audit disabled or too constrained? Redirecting to dlq
> {code}
> The broker loads messages twice into the cursor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMQ-6667) Many instances of "duplicate message ... from cursor" redirecting to dlq

[Gary Tully (JIRA)]

Gary Tully created AMQ-6667:
---

 Summary: Many instances of "duplicate message ... from cursor" 
redirecting to dlq
 Key: AMQ-6667
 URL: https://issues.apache.org/jira/browse/AMQ-6667
 Project: ActiveMQ
  Issue Type: Bug
  Components: KahaDB
Affects Versions: 5.14.0
Reporter: Gary Tully
Assignee: Gary Tully
 Fix For: 5.15.0


In a high throughput scenario on a single destination there can be many 
warnings of this kind:

{code}
[2017-03-21 09:51:37,548] WARN ActiveMQ BrokerService[localhost] Task-5 Queue - 
queue://TEST, subscriptions=10, memory=102%, size=399, 
pending=0, duplicate message ActiveMQTextMessage {commandId = 72, 
responseRequired = true, 
messageId = ID:Mac.fritz.box-64479-1490086286066-183:1:1:1:68, 
originalDestination = null, originalTransactionId = null, 
producerId = ID:Mac.fritz.box-64479-1490086286066-183:1:1:1, destination = 
queue://TEST, transactionId = null, expiration = 0, 
timestamp = 1490086297427, arrival = 0, brokerInTime = 1490086297427, 
brokerOutTime = 1490086297427, correlationId = null, replyTo = null, persistent 
= true, 
type = null, priority = 4, groupID = null, groupSequence = 0, targetConsumerId 
= null, compressed = false, userID = null, 
content = org.apache.activemq.util.ByteSequence@8672edc, marshalledProperties = 
null, dataStructure = null, redeliveryCounter = 0, size = 50216, properties = 
null, 
readOnlyProperties = false, readOnlyBody = false, droppable = false, 
jmsXGroupFirstForConsumer = false, text = ...} 
from cursor, is cursor audit disabled or too constrained? Redirecting to dlq
{code}

The broker loads messages twice into the cursor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1043) NettyConnector not working with IPv6 address

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1599#comment-1599
 ] 

ASF GitHub Bot commented on ARTEMIS-1043:
-

Github user jmesnil commented on the issue:

https://github.com/apache/activemq-artemis/pull/1245
  
Pending PR for master: https://github.com/apache/activemq-artemis/pull/1245


> NettyConnector not working with IPv6 address
> 
>
> Key: ARTEMIS-1043
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1043
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.3
>Reporter: Jeff Mesnil
> Fix For: 1.5.5, 2.next
>
>
> Artemis client doesn't correctly enclose IPv6 address when sending HTTP 
> upgrade packet. 
> According to [RFC2732 | https://www.ietf.org/rfc/rfc2732.txt], section {{2. 
> Literal IPv6 Address Format in URL's Syntax}} and [HTTP header field 
> definition 
> specification|https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html], 
> correct request URL should be enclosed like following one: 
> {{http://[fe80::56ee:75ff:fe47:c83e]}} 
> Following code snippet creates request for URL 
> {{http://fe80::56ee:75ff:fe47:c83e}} 
> {code} 
> HashMap map = new HashMap(); 
> map.put("host", "fe80::56ee:75ff:fe47:c83e"); 
> map.put("port", "8080"); 
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true); 
> TransportConfiguration transportConfiguration = new 
> TransportConfiguration(NettyConnectorFactory.class.getName(), map); 
> ConnectionFactory cf = 
> ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, 
> transportConfiguration); 
>  connection = cf.createConnection(); 
> {code} 
> This works fine when client connects directly to the server. However it may 
> cause problems when Artemis connects to proxy which expects IPv6 address 
> correctly enclosed. 
> Artemis client should detect IPv6 address and enclose it, so it conforms to 
> specification.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1043) NettyConnector not working with IPv6 address

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994442#comment-15994442
 ] 

ASF GitHub Bot commented on ARTEMIS-1043:
-

GitHub user jmesnil opened a pull request:

https://github.com/apache/activemq-artemis/pull/1245

[1.x] [ARTEMIS-1043] Support IPv6 in NettyConnector

Wrap the host added to the HTTP request headers with
IPV6Util.encloseHost to ensure that load balancers that reads the header
will have a valid IPv6 address.

JIRA: https://issues.apache.org/jira/browse/ARTEMIS-1043

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jmesnil/activemq-artemis 
ARTEMIS-1043_NettyConnector_IPv6_1.x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1245.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 #1245


commit 64c89b6874a0c72df15397db779ecb817885be35
Author: Jeff Mesnil 
Date:   2017-05-03T07:56:24Z

[ARTEMIS-1043] Support IPv6 in NettyConnector

Wrap the host added to the HTTP request headers with
IPV6Util.encloseHost to ensure that load balancers that reads the header
will have a valid IPv6 address.

JIRA: https://issues.apache.org/jira/browse/ARTEMIS-1043




> NettyConnector not working with IPv6 address
> 
>
> Key: ARTEMIS-1043
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1043
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.3
>Reporter: Jeff Mesnil
> Fix For: 1.5.5, 2.next
>
>
> Artemis client doesn't correctly enclose IPv6 address when sending HTTP 
> upgrade packet. 
> According to [RFC2732 | https://www.ietf.org/rfc/rfc2732.txt], section {{2. 
> Literal IPv6 Address Format in URL's Syntax}} and [HTTP header field 
> definition 
> specification|https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html], 
> correct request URL should be enclosed like following one: 
> {{http://[fe80::56ee:75ff:fe47:c83e]}} 
> Following code snippet creates request for URL 
> {{http://fe80::56ee:75ff:fe47:c83e}} 
> {code} 
> HashMap map = new HashMap(); 
> map.put("host", "fe80::56ee:75ff:fe47:c83e"); 
> map.put("port", "8080"); 
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true); 
> TransportConfiguration transportConfiguration = new 
> TransportConfiguration(NettyConnectorFactory.class.getName(), map); 
> ConnectionFactory cf = 
> ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, 
> transportConfiguration); 
>  connection = cf.createConnection(); 
> {code} 
> This works fine when client connects directly to the server. However it may 
> cause problems when Artemis connects to proxy which expects IPv6 address 
> correctly enclosed. 
> Artemis client should detect IPv6 address and enclose it, so it conforms to 
> specification.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-898) Artemis Plugin Support

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994400#comment-15994400
 ] 

ASF GitHub Bot commented on ARTEMIS-898:


Github user michaelandrepearce commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1242#discussion_r114486298
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
 ---
@@ -1808,6 +1822,33 @@ public void callPostQueueDeletionCallbacks(final 
SimpleString address,
}
 
@Override
+   public void registerBrokerPlugins(final List 
plugins) {
+  configuration.registerBrokerPlugins(plugins);
+   }
+
+   @Override
+   public void registerBrokerPlugin(final ActiveMQServerPlugin plugin) {
+  configuration.registerBrokerPlugin(plugin);
+   }
+
+   @Override
+   public void unRegisterBrokerPlugin(final ActiveMQServerPlugin plugin) {
+  configuration.unRegisterBrokerPlugin(plugin);
+   }
+
+   @Override
+   public List getBrokerPlugins() {
+  return configuration.getBrokerPlugins();
+   }
+
+   @Override
+   public void callPlugins(ActiveMQPluginRunnable pluginRun) {
+  if (getBrokerPlugins().size() > 0) {
--- End diff --

what I'm thinking here is like logging guard statements.


> Artemis Plugin Support
> --
>
> Key: ARTEMIS-898
> URL: https://issues.apache.org/jira/browse/ARTEMIS-898
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Matt Pavlovich
> Fix For: 2.next
>
>
> ActiveMQ 5.x currently has a number of extension points via Plugins, or 
> simple Spring bean wiring. Artemis should provide extension points to meet 
> various requirements.
> The protocol interceptors are handy, but also limiting in that each plugin 
> would need to be implemented for every protocol. Feels like there should be 
> defined extension point(s) within the broker.
> Core Broker Plugins:
> 1. Message header / property manipulation
> 2. Message body manipulation
> 3. Activity tracing (broker becomes master, network bridge start/stop, 
> message rcv/sent/ack/rollback, consumer/producer add/remove, broker 
> add/remove, destination add/remove, connection add/remove, fast producer/slow 
> consumer, etc)
>  a. Audit / trace logs
>  b. Triggers based on events
> ref: 
> http://activemq.apache.org/maven/apidocs/org/apache/activemq/broker/MutableBrokerFilter.html
> Additional extension point:
>  DestinationPolicies: Ability to impact destination behaviors for dispatch, 
> subscription policies, etc.
> Side benefit regarding Advisory Support:
> If the plugin framework can get squared away, an upside could be that 
> Advisory support becomes a plugin vs an ingrained feature and we could have 
> more control over configuration and behavior.
> From ARTEMIS-17
> Support for using Camel as an interceptor/plugin



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (ARTEMIS-1043) NettyConnector not working with IPv6 address

[Jeff Mesnil (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Mesnil reopened ARTEMIS-1043:
--

I forgot to enclose the host in the HTTP request headers (that are used by load 
balancer)

> NettyConnector not working with IPv6 address
> 
>
> Key: ARTEMIS-1043
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1043
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.3
>Reporter: Jeff Mesnil
> Fix For: 1.5.5, 2.next
>
>
> Artemis client doesn't correctly enclose IPv6 address when sending HTTP 
> upgrade packet. 
> According to [RFC2732 | https://www.ietf.org/rfc/rfc2732.txt], section {{2. 
> Literal IPv6 Address Format in URL's Syntax}} and [HTTP header field 
> definition 
> specification|https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html], 
> correct request URL should be enclosed like following one: 
> {{http://[fe80::56ee:75ff:fe47:c83e]}} 
> Following code snippet creates request for URL 
> {{http://fe80::56ee:75ff:fe47:c83e}} 
> {code} 
> HashMap map = new HashMap(); 
> map.put("host", "fe80::56ee:75ff:fe47:c83e"); 
> map.put("port", "8080"); 
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true); 
> TransportConfiguration transportConfiguration = new 
> TransportConfiguration(NettyConnectorFactory.class.getName(), map); 
> ConnectionFactory cf = 
> ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, 
> transportConfiguration); 
>  connection = cf.createConnection(); 
> {code} 
> This works fine when client connects directly to the server. However it may 
> cause problems when Artemis connects to proxy which expects IPv6 address 
> correctly enclosed. 
> Artemis client should detect IPv6 address and enclose it, so it conforms to 
> specification.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)