[jira] [Created] (ARTEMIS-1334) Scheduled Component.stop synchronization issues

[clebert suconic (JIRA)]

clebert suconic created ARTEMIS-1334:


 Summary: Scheduled Component.stop synchronization issues
 Key: ARTEMIS-1334
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1334
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: clebert suconic


I have been reported of issues ScheduledComponent.stop() (waiting to lock)

It shouldn't be synchronized..

I could replicate on a few tests. but I don't know how to write a unit test for 
this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ARTEMIS-1333) Completion listener can lead to message loss in case of crash

[clebert suconic (JIRA)]

clebert suconic created ARTEMIS-1333:


 Summary: Completion listener can lead to message loss in case of 
crash
 Key: ARTEMIS-1333
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1333
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 2.2.0
Reporter: clebert suconic
Assignee: clebert suconic
 Fix For: 2.3.0






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (AMQ-6788) ClassNotFoundException PListStoreImpl when trying to start an embedded broker with memory persistence

[ASF subversion and git services (JIRA)]

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

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

Commit 8646bb1010d2632f5d405fe1761c2b9c99a0a139 in activemq's branch 
refs/heads/master from [~ch...@die-schneider.net]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=8646bb1 ]

[AMQ-6788] Explain how to fix the problem in the exception


> ClassNotFoundException PListStoreImpl when trying to start an embedded broker 
> with memory persistence
> -
>
> Key: AMQ-6788
> URL: https://issues.apache.org/jira/browse/AMQ-6788
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.15.0
> Environment: Ubuntu Linux, ActiveMQ 5.15.0
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: 5.15.1
>
>
> I try to start an embedded broker:
> broker = new BrokerService();
> broker.setPersistenceAdapter(new MemoryPersistenceAdapter());
> broker.start();
> java.lang.RuntimeException: java.lang.ClassNotFoundException: 
> org.apache.activemq.store.kahadb.plist.PListStoreImpl
> For details see:
> https://apaste.info/vIkj



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1328) Delivery guard can take too long

[clebert suconic (JIRA)]

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

clebert suconic commented on ARTEMIS-1328:
--

michaelandrepear: so just quickly why the increase of CHECK_QUEUE_SIZE_PERIOD
[2:26pm] michaelandrepear: from 100 to 1000
[2:26pm] michaelandrepear: what does that do?
[2:26pm] clebert: it will check if the queue can be back into direct deliver
[2:26pm] clebert: it’s meant for after low periods
[2:26pm] clebert: I think 100 milliseconds it’s too short
[2:27pm] clebert: it’s usually meant to after the consumer caught up
[2:27pm] michaelandrepear: ok cool
[2:27pm] clebert: so.. you have no messages pending
[2:27pm] clebert: beeing idle for a while
[2:27pm] clebert: you check again…
[2:27pm] clebert: checking every 100 Milliseconds was being too much I think
[2:27pm] clebert: maybe I should add that to the JIRA
[2:28pm] michaelandrepear: i just couldnt work out what exactly 100 to 1000 was 
specific if its just gut feeling thats cool
[2:28pm] clebert: do you mind if I copy & paste the chat here into there?
[2:28pm] michaelandrepear: i was thinking it was more specific reason
[2:28pm] clebert: gut feeling really
[2:28pm] michaelandrepear: of course not
[2:28pm] clebert: after running tests

> Delivery guard can take too long
> 
>
> Key: ARTEMIS-1328
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1328
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.3.0
>
>
> There is a flush on delivery guard flush.
> if it's taking too long it will block the queue for a long period.
> This needs to be a quick check or keep doing async checks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1328) Delivery guard can take too long

[clebert suconic (JIRA)]

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

clebert suconic commented on ARTEMIS-1328:
--

basically, it will re-check every second.. but the check is cheaper now.. so 1 
second should be ok.

> Delivery guard can take too long
> 
>
> Key: ARTEMIS-1328
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1328
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.3.0
>
>
> There is a flush on delivery guard flush.
> if it's taking too long it will block the queue for a long period.
> This needs to be a quick check or keep doing async checks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1328) Delivery guard can take too long

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1328:
-

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1447
  
@clebertsuconic only query i have 

was why this change?
-   public static final int CHECK_QUEUE_SIZE_PERIOD = 100;
+   public static final int CHECK_QUEUE_SIZE_PERIOD = 1000;



> Delivery guard can take too long
> 
>
> Key: ARTEMIS-1328
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1328
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.3.0
>
>
> There is a flush on delivery guard flush.
> if it's taking too long it will block the queue for a long period.
> This needs to be a quick check or keep doing async checks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1328) Delivery guard can take too long

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1328:
-

Github user asfgit closed the pull request at:

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


> Delivery guard can take too long
> 
>
> Key: ARTEMIS-1328
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1328
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.3.0
>
>
> There is a flush on delivery guard flush.
> if it's taking too long it will block the queue for a long period.
> This needs to be a quick check or keep doing async checks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1328) Delivery guard can take too long

[ASF subversion and git services (JIRA)]

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

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

Commit 25c0f93ad50bc82f93cc2a6785203cb1ea366c40 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=25c0f93 ]

ARTEMIS-1328 Improving direct delivery check

Based on #1447 as it is not possible to cherry-pick here


> Delivery guard can take too long
> 
>
> Key: ARTEMIS-1328
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1328
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.3.0
>
>
> There is a flush on delivery guard flush.
> if it's taking too long it will block the queue for a long period.
> This needs to be a quick check or keep doing async checks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1328) Delivery guard can take too long

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1328:
-

Github user asfgit closed the pull request at:

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


> Delivery guard can take too long
> 
>
> Key: ARTEMIS-1328
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1328
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.3.0
>
>
> There is a flush on delivery guard flush.
> if it's taking too long it will block the queue for a long period.
> This needs to be a quick check or keep doing async checks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1328) Delivery guard can take too long

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-1328 Improving direct delivery check

Instead of wait to flush an executor,
I have added a method isFlushed() which will just translate to the
state on the OrderedExecutor.

In the case another executor is provided (for tests) there's a delegate
into normal executors.


> Delivery guard can take too long
> 
>
> Key: ARTEMIS-1328
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1328
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.3.0
>
>
> There is a flush on delivery guard flush.
> if it's taking too long it will block the queue for a long period.
> This needs to be a quick check or keep doing async checks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (AMQ-6790) AMQP: Update Qpid JMS and Qpid Proton-J

[Timothy Bish (JIRA)]

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

Timothy Bish resolved AMQ-6790.
---
Resolution: Fixed

> AMQP: Update Qpid JMS and Qpid Proton-J
> ---
>
> Key: AMQ-6790
> URL: https://issues.apache.org/jira/browse/AMQ-6790
> Project: ActiveMQ
>  Issue Type: Task
>  Components: AMQP
>Affects Versions: 5.15.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.15.1, 5.16.0
>
>
> Update to latest release Qpid JMS 0.24.0 and Proton-j 0.20.0



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (AMQ-6790) AMQP: Update Qpid JMS and Qpid Proton-J

[ASF subversion and git services (JIRA)]

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

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

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

AMQ-6790 Update to latest Qpid JMS and Qpid Proton versions

Moves to Qpid JMS 0.24.0 and Qpid Proton-J 0.20.0

> AMQP: Update Qpid JMS and Qpid Proton-J
> ---
>
> Key: AMQ-6790
> URL: https://issues.apache.org/jira/browse/AMQ-6790
> Project: ActiveMQ
>  Issue Type: Task
>  Components: AMQP
>Affects Versions: 5.15.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.15.1, 5.16.0
>
>
> Update to latest release Qpid JMS 0.24.0 and Proton-j 0.20.0



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (AMQ-6790) AMQP: Update Qpid JMS and Qpid Proton-J

[ASF subversion and git services (JIRA)]

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

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

Commit eabfa451dcb9d96bd0e256158c94ac04f82ab16c in activemq's branch 
refs/heads/activemq-5.15.x from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=eabfa45 ]

AMQ-6790 Update to latest Qpid JMS and Qpid Proton versions

Moves to Qpid JMS 0.24.0 and Qpid Proton-J 0.20.0
(cherry picked from commit 267fe73898ca45058ccfe9f2e0efee18262de8cb)


> AMQP: Update Qpid JMS and Qpid Proton-J
> ---
>
> Key: AMQ-6790
> URL: https://issues.apache.org/jira/browse/AMQ-6790
> Project: ActiveMQ
>  Issue Type: Task
>  Components: AMQP
>Affects Versions: 5.15.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.15.1, 5.16.0
>
>
> Update to latest release Qpid JMS 0.24.0 and Proton-j 0.20.0



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (AMQ-6790) AMQP: Update Qpid JMS and Qpid Proton-J

[Timothy Bish (JIRA)]

Timothy Bish created AMQ-6790:
-

 Summary: AMQP: Update Qpid JMS and Qpid Proton-J
 Key: AMQ-6790
 URL: https://issues.apache.org/jira/browse/AMQ-6790
 Project: ActiveMQ
  Issue Type: Task
  Components: AMQP
Affects Versions: 5.15.0
Reporter: Timothy Bish
Assignee: Timothy Bish
 Fix For: 5.15.1, 5.16.0


Update to latest release Qpid JMS 0.24.0 and Proton-j 0.20.0



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1332) The broker should always return a response when a client adds metadata

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1332:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1450
  
@cshannon ahaaa!!! thanks a lot... you just saved me a task !  
Someone reported me an issue at Red Hat.. I think this is the cause.


> The broker should always return a response when a client adds metadata
> --
>
> Key: ARTEMIS-1332
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1332
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
> Fix For: 2.3.0
>
>
> When adding metadata to a session (such as when a JMS client adds a clientId) 
> the client will never receive a response if there is an exception (other than 
> duplicate client id) on the broker side and the client will just hang.  This 
> scenario could happen if a broker plugin throws an ActiveMQException during 
> the beforeSessionMetadataAdded() method call.  An example use case when an 
> exception could be thrown is if a plugin writer wants to add extra security 
> or put restrictions on a clientId name (length, type of characters, etc).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1310) Provide GSSAPI (kerberos) SASL mechanism for AMQP

[ASF subversion and git services (JIRA)]

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

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

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

[ARTEMIS-1310] [ARTEMIS-1264] consolidate configuration to require login 
configuration scope


> Provide GSSAPI (kerberos) SASL mechanism for AMQP
> -
>
> Key: ARTEMIS-1310
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1310
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 2.3.0
>
>
> implement GSSAPI sasl mechanism for AMQP transport allowing kerberos single 
> sign on (authentication) and subsequent authorisation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1310) Provide GSSAPI (kerberos) SASL mechanism for AMQP

[ASF subversion and git services (JIRA)]

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

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

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

[ARTEMIS-1310] add amqp sasl gssapi mechanism support

delegate to the jdk saslServer. Allow acceptor configuration of supported 
mechanismis; saslMechanisms=
and allow login config scope for krb5 to be configured via 
saslLoginConfigScope=x


> Provide GSSAPI (kerberos) SASL mechanism for AMQP
> -
>
> Key: ARTEMIS-1310
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1310
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 2.3.0
>
>
> implement GSSAPI sasl mechanism for AMQP transport allowing kerberos single 
> sign on (authentication) and subsequent authorisation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1264) Client authentication via Kerberos TLS Cipher Suites (RFC 2712)

[ASF subversion and git services (JIRA)]

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

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

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

[ARTEMIS-1310] [ARTEMIS-1264] consolidate configuration to require login 
configuration scope


> Client authentication via Kerberos TLS Cipher Suites (RFC 2712)
> ---
>
> Key: ARTEMIS-1264
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1264
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Affects Versions: 2.1.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 2.2.0
>
>
> Allow a client authenticated with a kerberos credential to authenticate to 
> the broker using SSL via the Kerberos cipher suites.
> next steps:
>  - -ensure mapping from kerberos principal to broker identity is locked down-
>  -- https://github.com/apache/activemq-artemis/pull/1388
>  - -ensure jms client config is trivial-
>  -- the connector properties can be configured in the same way as for core.
>  - -validate broker side ticket expiry and renewal-
>  - work with qpid-jms to validate amqp client (on hold)
>  - validate with non java - proton-c client ({color:red}problem{color})
> Interop with non java clients is a problem. OpenSSL [has removed 
> support|http://openssl.6102.n7.nabble.com/openssl-users-Kerberos-tp57906p58095.html]
>  for [rfc2712|https://www.ietf.org/rfc/rfc2712.txt]. 
> While reusing the TLS handshake was a good idea at the time; it has issues 
> (non compatible impl between openssl and sun) and the world has moved on to 
> layering authentication over TLS rather than with.
> This makes sense b/c kerberos does two things, authentication over an 
> insecure connection and session encryption over that connection. With rfc2712 
> the available session encryption options are known to be insecure, best to 
> leave encryption entirely to TLS. 
> In a java only scenario (sun jdk on both ends), using this feature for 
> kerberos *authentication only* is viable.
> For example, if clients use username/password for authentication and TLS to 
> encrypt the connection to secure the password, but don't care about 
> encrypting the rest of the data, there is some value here.
> They can swap the username/password for a kerberos token and achieve 
> authentication. They will essentially drop encryption because the cypher in 
> use is insecure. Note a kerberos ticket is designed to be validated across an 
> insecure channel.
> The modern approach is to layer kerberos authentication over TLS using 
> something like the GSSAPI and SASL.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1310) Provide GSSAPI (kerberos) SASL mechanism for AMQP

[ASF subversion and git services (JIRA)]

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

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

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

[ARTEMIS-1310] require mechanism to be explicitly enabled


> Provide GSSAPI (kerberos) SASL mechanism for AMQP
> -
>
> Key: ARTEMIS-1310
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1310
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 2.3.0
>
>
> implement GSSAPI sasl mechanism for AMQP transport allowing kerberos single 
> sign on (authentication) and subsequent authorisation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1310) Provide GSSAPI (kerberos) SASL mechanism for AMQP

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1310:
-

Github user asfgit closed the pull request at:

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


> Provide GSSAPI (kerberos) SASL mechanism for AMQP
> -
>
> Key: ARTEMIS-1310
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1310
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 2.3.0
>
>
> implement GSSAPI sasl mechanism for AMQP transport allowing kerberos single 
> sign on (authentication) and subsequent authorisation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (ARTEMIS-1325) Update Proton 0.20 and qpid-jms 0.24

[clebert suconic (JIRA)]

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

clebert suconic closed ARTEMIS-1325.

Resolution: Fixed

> Update Proton 0.20 and qpid-jms 0.24
> 
>
> Key: ARTEMIS-1325
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1325
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Affects Versions: 2.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1325) Update Proton 0.20 and qpid-jms 0.24

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-1325 Update proton 0.20 and qpid-jms 0.24


> Update Proton 0.20 and qpid-jms 0.24
> 
>
> Key: ARTEMIS-1325
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1325
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Affects Versions: 2.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1310) Provide GSSAPI (kerberos) SASL mechanism for AMQP

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1310:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1449
  
@gtully I will update proton and qpid-jms on a different commit
and rebase this one.


> Provide GSSAPI (kerberos) SASL mechanism for AMQP
> -
>
> Key: ARTEMIS-1310
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1310
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 2.3.0
>
>
> implement GSSAPI sasl mechanism for AMQP transport allowing kerberos single 
> sign on (authentication) and subsequent authorisation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1310) Provide GSSAPI (kerberos) SASL mechanism for AMQP

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1310:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1449
  
@tabish121 Oh.. I see


> Provide GSSAPI (kerberos) SASL mechanism for AMQP
> -
>
> Key: ARTEMIS-1310
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1310
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 2.3.0
>
>
> implement GSSAPI sasl mechanism for AMQP transport allowing kerberos single 
> sign on (authentication) and subsequent authorisation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1332) The broker should always return a response when a client adds metadata

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1332:
-

GitHub user cshannon opened a pull request:

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

ARTEMIS-1332 - Always return a response to the client on session

metadata add

This will make sure that if there is an ActiveMQException thrown the
client will get notified and not hang.

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

$ git pull https://github.com/cshannon/activemq-artemis ARTEMIS-1332

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

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


commit 2cd3d5948675ccb550a87067bffbf74f1169043d
Author: Christopher L. Shannon (cshannon) 
Date:   2017-08-08T17:09:03Z

ARTEMIS-1332 - Always return a response to the client on session
metadata add

This will make sure that if there is an ActiveMQException thrown the
client will get notified and not hang.




> The broker should always return a response when a client adds metadata
> --
>
> Key: ARTEMIS-1332
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1332
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
> Fix For: 2.3.0
>
>
> When adding metadata to a session (such as when a JMS client adds a clientId) 
> the client will never receive a response if there is an exception (other than 
> duplicate client id) on the broker side and the client will just hang.  This 
> scenario could happen if a broker plugin throws an ActiveMQException during 
> the beforeSessionMetadataAdded() method call.  An example use case when an 
> exception could be thrown is if a plugin writer wants to add extra security 
> or put restrictions on a clientId name (length, type of characters, etc).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ARTEMIS-1332) The broker should always return a response when a client adds metadata

[Christopher L. Shannon (JIRA)]

Christopher L. Shannon created ARTEMIS-1332:
---

 Summary: The broker should always return a response when a client 
adds metadata
 Key: ARTEMIS-1332
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1332
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 2.2.0
Reporter: Christopher L. Shannon
Assignee: Christopher L. Shannon
 Fix For: 2.3.0


When adding metadata to a session (such as when a JMS client adds a clientId) 
the client will never receive a response if there is an exception (other than 
duplicate client id) on the broker side and the client will just hang.  This 
scenario could happen if a broker plugin throws an ActiveMQException during the 
beforeSessionMetadataAdded() method call.  An example use case when an 
exception could be thrown is if a plugin writer wants to add extra security or 
put restrictions on a clientId name (length, type of characters, etc).




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1328) Delivery guard can take too long

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1328:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1447
  
this is now ready...

@michaelandrepearce since you've looked.. mind looking again?



> Delivery guard can take too long
> 
>
> Key: ARTEMIS-1328
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1328
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.3.0
>
>
> There is a flush on delivery guard flush.
> if it's taking too long it will block the queue for a long period.
> This needs to be a quick check or keep doing async checks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1310) Provide GSSAPI (kerberos) SASL mechanism for AMQP

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1310:
-

Github user tabish121 commented on the issue:

https://github.com/apache/activemq-artemis/pull/1449
  
It looks to me like the third commit updates to the released bits.  Maybe 
squash the commits?


> Provide GSSAPI (kerberos) SASL mechanism for AMQP
> -
>
> Key: ARTEMIS-1310
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1310
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 2.3.0
>
>
> implement GSSAPI sasl mechanism for AMQP transport allowing kerberos single 
> sign on (authentication) and subsequent authorisation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1310) Provide GSSAPI (kerberos) SASL mechanism for AMQP

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1310:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1449
  
@gtully if they are in maven central, can't we just use the released bits 
then?


> Provide GSSAPI (kerberos) SASL mechanism for AMQP
> -
>
> Key: ARTEMIS-1310
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1310
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 2.3.0
>
>
> implement GSSAPI sasl mechanism for AMQP transport allowing kerberos single 
> sign on (authentication) and subsequent authorisation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1310) Provide GSSAPI (kerberos) SASL mechanism for AMQP

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1310:
-

Github user gtully commented on the issue:

https://github.com/apache/activemq-artemis/pull/1449
  
The new proton-j and qpid-jms deps are in maven central. 
W.r.t to the tests check failing, some unrelated permissions issue with 
temp dir creation seems to be the root cause of them all.


> Provide GSSAPI (kerberos) SASL mechanism for AMQP
> -
>
> Key: ARTEMIS-1310
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1310
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 2.3.0
>
>
> implement GSSAPI sasl mechanism for AMQP transport allowing kerberos single 
> sign on (authentication) and subsequent authorisation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (ARTEMIS-1308) Client Acknowledge not performant

[clebert suconic (JIRA)]

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

clebert suconic closed ARTEMIS-1308.

Resolution: Fixed

> Client Acknowledge not performant
> -
>
> Key: ARTEMIS-1308
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1308
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Michael Andre Pearce
>Assignee: Michael Andre Pearce
>Priority: Critical
> Fix For: 2.3.0
>
>
> Artemis recommendation in docs is to use CLIENT_ACKNOWLEDGE instead of 
> AUTO_ACKNOWLEDGE, on perf testing it seems this is not the case.
> On checking code it seems the reason for this is because ActiveMQMessage 
> acknowledge actually calls session.commit, causing a full session commit all 
> the time.
> On checking Core API, calling message.acknowledge it seems to behave as 
> expected, as such believe this to be an issue in JMS api wrapper, that it 
> should just be delegating to the ClientMessage.acknowledge method and this is 
> the cause of the perf issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (AMQ-6643) Shared virtual topic wildcard consumers receive spurious and duplicate messages

[ASF subversion and git services (JIRA)]

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

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

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

[AMQ-6643] refine fix to allow wildcard subs to non wildcard subscription 
queues, enable simple wildcard sub to drain all subscription queues


> Shared virtual topic wildcard consumers receive spurious and duplicate 
> messages
> ---
>
> Key: AMQ-6643
> URL: https://issues.apache.org/jira/browse/AMQ-6643
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.14.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.15.0
>
>
> Virtual topic wildcard subscriber queues are physical queues, however the 
> matching of destinations to new subscriptions matches based on the wildcard 
> destination in error. Causing subs to get subscribed in error and causing 
> duplicate subscriptions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1310) Provide GSSAPI (kerberos) SASL mechanism for AMQP

[Timothy Bish (JIRA)]

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

Timothy Bish commented on ARTEMIS-1310:
---

Qpid JMS 0.24.0 is already finalized and released, see central: 
https://search.maven.org/#search%7Cga%7C1%7Cqpid-jms

> Provide GSSAPI (kerberos) SASL mechanism for AMQP
> -
>
> Key: ARTEMIS-1310
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1310
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 2.3.0
>
>
> implement GSSAPI sasl mechanism for AMQP transport allowing kerberos single 
> sign on (authentication) and subsequent authorisation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1328) Delivery guard can take too long

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1328:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1447
  
Please.. don't merge this.. I'm changing this around.. will send another 
message when it's ok.


> Delivery guard can take too long
> 
>
> Key: ARTEMIS-1328
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1328
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.3.0
>
>
> There is a flush on delivery guard flush.
> if it's taking too long it will block the queue for a long period.
> This needs to be a quick check or keep doing async checks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1310) Provide GSSAPI (kerberos) SASL mechanism for AMQP

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1310:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1449
  
@gtully  Impressive work here!  磊 

just a question... qpid-jms has been already issued a vote.. it should be 
passed by tomorrow. wouldn't be worth to merge this tomorrow after it's 
released?

I had already issued a heads-up on the dev list, we could release this as 
soon as that is released.


> Provide GSSAPI (kerberos) SASL mechanism for AMQP
> -
>
> Key: ARTEMIS-1310
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1310
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 2.3.0
>
>
> implement GSSAPI sasl mechanism for AMQP transport allowing kerberos single 
> sign on (authentication) and subsequent authorisation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1310) Provide GSSAPI (kerberos) SASL mechanism for AMQP

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1310:
-

GitHub user gtully opened a pull request:

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

[ARTEMIS-1310] SASL GSSAPI support

update to proton-j 0.20.0 and qpid-jms 0.24.0

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

$ git pull https://github.com/gtully/activemq-artemis sasl-gssapi

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

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


commit d4a281ed049acfa11b489ed43a06ba57669d7588
Author: gtully 
Date:   2017-07-28T15:02:32Z

[ARTEMIS-1310] add amqp sasl gssapi mechanism support

delegate to the jdk saslServer. Allow acceptor configuration of supported 
mechanismis; saslMechanisms=
and allow login config scope for krb5 to be configured via 
saslLoginConfigScope=x

commit 1496b8c463eec9fbe385a8c9e4be7e9141018454
Author: gtully 
Date:   2017-08-02T11:19:07Z

[ARTEMIS-1310] [ARTEMIS-1264] consolidate configuration to require login 
configuration scope

commit b551f9ea978eaf0607cd7b8c1567cc13d06031c8
Author: gtully 
Date:   2017-08-02T14:05:50Z

[ARTEMIS-1310] require mechanism to be explicitly enabled




> Provide GSSAPI (kerberos) SASL mechanism for AMQP
> -
>
> Key: ARTEMIS-1310
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1310
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.2.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 2.3.0
>
>
> implement GSSAPI sasl mechanism for AMQP transport allowing kerberos single 
> sign on (authentication) and subsequent authorisation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1308) Client Acknowledge not performant

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1308:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1428
  
nice job on this one... no regressions whatsoever.. I even ran some outer 
tests on this.. compatibility kit and other stuff.. nice job!


> Client Acknowledge not performant
> -
>
> Key: ARTEMIS-1308
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1308
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Michael Andre Pearce
>Assignee: Michael Andre Pearce
>Priority: Critical
> Fix For: 2.3.0
>
>
> Artemis recommendation in docs is to use CLIENT_ACKNOWLEDGE instead of 
> AUTO_ACKNOWLEDGE, on perf testing it seems this is not the case.
> On checking code it seems the reason for this is because ActiveMQMessage 
> acknowledge actually calls session.commit, causing a full session commit all 
> the time.
> On checking Core API, calling message.acknowledge it seems to behave as 
> expected, as such believe this to be an issue in JMS api wrapper, that it 
> should just be delegating to the ClientMessage.acknowledge method and this is 
> the cause of the perf issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1308) Client Acknowledge not performant

[ASF subversion and git services (JIRA)]

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

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

Commit 7b40abead95b36e5769769373d6f7bab8e34dde9 in activemq-artemis's branch 
refs/heads/master from [~michael.andre.pearce]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=7b40abe ]

ARTEMIS-1308: Make acknowlegde in AcitveMQMessage non blocking 

Allow commit within the acknowledge to be non blocking (batch) this toggles the 
on the existing blockonacknowlegde config.


> Client Acknowledge not performant
> -
>
> Key: ARTEMIS-1308
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1308
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Michael Andre Pearce
>Assignee: Michael Andre Pearce
>Priority: Critical
> Fix For: 2.3.0
>
>
> Artemis recommendation in docs is to use CLIENT_ACKNOWLEDGE instead of 
> AUTO_ACKNOWLEDGE, on perf testing it seems this is not the case.
> On checking code it seems the reason for this is because ActiveMQMessage 
> acknowledge actually calls session.commit, causing a full session commit all 
> the time.
> On checking Core API, calling message.acknowledge it seems to behave as 
> expected, as such believe this to be an issue in JMS api wrapper, that it 
> should just be delegating to the ClientMessage.acknowledge method and this is 
> the cause of the perf issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1308) Client Acknowledge not performant

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1308:
-

Github user asfgit closed the pull request at:

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


> Client Acknowledge not performant
> -
>
> Key: ARTEMIS-1308
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1308
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Michael Andre Pearce
>Assignee: Michael Andre Pearce
>Priority: Critical
> Fix For: 2.3.0
>
>
> Artemis recommendation in docs is to use CLIENT_ACKNOWLEDGE instead of 
> AUTO_ACKNOWLEDGE, on perf testing it seems this is not the case.
> On checking code it seems the reason for this is because ActiveMQMessage 
> acknowledge actually calls session.commit, causing a full session commit all 
> the time.
> On checking Core API, calling message.acknowledge it seems to behave as 
> expected, as such believe this to be an issue in JMS api wrapper, that it 
> should just be delegating to the ClientMessage.acknowledge method and this is 
> the cause of the perf issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1286) Server stops responding and throws OutOfDirectMemoryError when sending & receiving lots of 2MB messages.

[Timothy Bish (JIRA)]

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

Timothy Bish commented on ARTEMIS-1286:
---

[~pwjenkins] The folks working an the ActiveMQ project are in many cases 
working on issues on there own time or in coordination with other pressing 
matters in their day jobs.  Pressing people who are volunteering their time and 
energy to fix your problem is usually a good way of annoying people into 
ignoring you.  Artemis is an open source project, you can dive in and try and 
resolve issues as anyone else can, I'd recommend you take some time and try and 
see if you can fix your own issue.  

> Server stops responding and throws OutOfDirectMemoryError when sending & 
> receiving lots of 2MB messages.
> 
>
> Key: ARTEMIS-1286
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1286
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker, MQTT
>Affects Versions: 2.1.0
>Reporter: Phillip Jenkins
>Assignee: Martyn Taylor
>Priority: Blocker
> Fix For: 2.3.0
>
> Attachments: broker.xml, mqtt.zip
>
>
> Originally seen in v2.1 and present in v2.2.
> If you send and receive a lot of 2MB messages in short time thru Artemis via 
> Netty connector, the server throws the following OutOfDirectMemoryError 
> exception. The server stops responding and will not (any longer) accept 
> connections without throwing exceptions in an infinite loop.
> {code:java}
> 11:24:07,434 INFO  [org.apache.activemq.artemis] AMQ241001: HTTP Server 
> started at http://localhost:8161
> 11:24:07,434 INFO  [org.apache.activemq.artemis] AMQ241002: Artemis Jolokia 
> REST API available at http://localhost:8161/jolokia
> 11:58:35,991 WARN  [org.apache.activemq.artemis.core.server] AMQ222151: 
> removing consumer which did not handle a message, consumer=ServerConsumerImpl 
> [id=2229, filter=null, binding=LocalQueueBinding 
> [address=SOAP.S.PRN.ACBCAF6238234680, 
> queue=QueueImpl[name=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680, 
> postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=afa7de73-67e7-11e7-a231-54ee7505882d], 
> temp=false]@46adc2a5, filter=FilterImpl [sfilterString=NOT ((AMQAddress = 
> 'activemq.management') OR (AMQAddress = 'activemq.notifications'))], 
> name=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680, 
> clusterName=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680afa7de73-67e7-11e7-a231-54ee7505882d]],
>  
> message=Reference[3551]:NON-RELIABLE:CoreMessage[messageID=3551,durable=false,userID=null,priority=0,
>  timestamp=0,expiration=0, durable=false, 
> address=SOAP.S.PRN.ACBCAF6238234680,properties=TypedProperties[mqtt.message.retain=false,mqtt.qos.level=0]]@1305748199:
>  io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 3729415 
> byte(s) of direct memory (used: 1070952692, max: 1073741824)
>   at 
> io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:585)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:539)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledUnsafeNoCleanerDirectByteBuf.java:30)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledByteBufAllocator.java:169)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeDirectByteBuf.(UnpooledUnsafeDirectByteBuf.java:68)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledUnsafeNoCleanerDirectByteBuf.java:25)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledByteBufAllocator.java:164)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:73)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:181)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:117)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:828) 
> [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at io.netty.buffer.WrappedByteBuf.readBytes(WrappedByteBuf.java:616) 
> [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> 

[jira] [Commented] (ARTEMIS-1330) [DISCUSS] Run JMS tests over many protocols (through different JMS client libraries)

[Timothy Bish (JIRA)]

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

Timothy Bish commented on ARTEMIS-1330:
---

I believe that the broker does have tests that use the JORAM JMS test suite to 
validate the different JMS clients (and thus protocols) which sounds like what 
you are trying for.  I don't think that changing the tests such as those in 
places like "*/integration/amqp/" which are testing generally very specific 
protocol level interactions should be modified as that will generally result in 
a dumbing down of the tests to use only JMS APIs where these test are usually 
testing a specific issue or targeted protocol / broker interaction.  

> [DISCUSS] Run JMS tests over many protocols (through different JMS client 
> libraries)
> 
>
> Key: ARTEMIS-1330
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1330
> Project: ActiveMQ Artemis
>  Issue Type: Test
>  Components: AMQP, OpenWire
>Affects Versions: 2.3.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Currently, there are three sets of JMS tests in Apache ActiveMQ Artemis 
> codebase (that I know of)
> * 
> activemq-artemis/tests/jms-tests/src/test/java/org/apache/activemq/artemis/jms/tests/*
> * 
> activemq-artemis/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/jms/*
> * 
> activemq-artemis/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/*
> The first two are being run only through the Core JMS client, while the last 
> one is being run through Qpid JMS client (with few exceptions).
> It should be beneficial to be able to run all JMS tests through all three 
> protocols that Artemis supports that have a JMS client, these being
> * Core (artemis-jms-client),
> * OpenWire (activemq-client), and
> * AMQP (qpid-jms-client).
> I made an attempt to convert some of the tests to a parametrized test with 
> changeable connection factory. The way 
> {{org.apache.activemq.artemis.tests.integration.persistence.SyncSendTest}} 
> currently does it. See https://github.com/jdanekrh/activemq-artemis/pull/4
> There are the following obstackes
> * Some tests go beyond the JMS standardized APIs and cast the JMS object to 
> specific implementations in their chosen library.
> * Some tests require specific settings on the connection factory, these are 
> not portable across different JMS clients. There will have to be branching 
> depending on the specific factory currently in use, or something...
> * OpenWire client supports JMS 1.1, while Core and AMQP clients are JMS 2.0, 
> some tests will have to be skipped on OpenWire
> * OpenWire client has different semantics of {{receiver.receiveNoWait()}} 
> call; when there are no messages in prefetch cache, OpenWire returns null, 
> while other clients do a round trip to server to check for new messages 
> before giving up.
> There are some improvements which can be considered later, some of these are 
> partially implemented in various places
> * share broker between individual tests
> * use random name or random suffix for created addresses and queues use 
> suffix for queues/topics to ensure isolation
> * have broker uberconfig for all tests, or group tests by config they need, 
> so that reconfiguring broker is limited
> * that also allows tests to run in parallel
> * use random port for acceptor on broker, can run tests even more parallel, 
> and mitigates environmentally caused failures
> I intend to report the failures I found so far (see the code at the link 
> above) and I am reasonably certain they are actual failures. The rest I plan 
> to note in comments here, one test per comment.
> If you happen to have any comments and suggestions how to do this better, I'd 
> be glad to hear them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (AMQ-6789) Warnning on karaf feature

[Timothy Bish (JIRA)]

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

Timothy Bish closed AMQ-6789.
-
Resolution: Won't Fix

The version 5.12.3 is no longer supported, you need to move to the latest 
release 5.15.0

> Warnning on karaf feature
> -
>
> Key: AMQ-6789
> URL: https://issues.apache.org/jira/browse/AMQ-6789
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: karaf
>Affects Versions: 5.12.3
> Environment: Karaf 3.0.6
>Reporter: Terrien Jean-Yves
>Priority: Minor
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> 2017-08-08 12:52:56,765 | WARN  | l for user karaf | FeatureValidationUtil
> | 20 - org.apache.karaf.features.core - 3.0.6 | Old style feature 
> file without namespace found (URI: 
> mvn:org.apache.activemq/activemq-karaf/5.12.3/xml/features). This format is 
> deprecated and support for it will soon be removed
> 2017-08-08 12:52:56,932 | WARN  | l for user karaf | FeatureValidationUtil
> | 20 - org.apache.karaf.features.core - 3.0.6 | Old style feature 
> file without namespace found (URI: 
> mvn:org.apache.activemq/activemq-karaf/5.12.3/xml/features-core). This format 
> is deprecated and support for it will soon be removed
> solution : replace 
>  by
> http://karaf.apache.org/xmlns/features/v1.2.1; 
> name="activemq-core-5.12.3"> in file activemq-karaf-5.12.3-features-core.xml
> and 
>  by
> http://karaf.apache.org/xmlns/features/v1.2.1; 
> name="activemq-5.12.3"> in file activemq-karaf-5.12.3-features.xml
> Bye



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1328) Delivery guard can take too long

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1328:
-

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

https://github.com/apache/activemq-artemis/pull/1447#discussion_r131907760
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java
 ---
@@ -664,7 +664,7 @@ public void addTail(final MessageReference ref, final 
boolean direct) {
if (intermediateMessageReferences.isEmpty() && 
messageReferences.isEmpty() && !pageIterator.hasNext() && 
!pageSubscription.isPaging()) {
   // We must block on the executor to ensure any async 
deliveries have completed or we might get out of order
   // deliveries
-  if (flushExecutor() && flushDeliveriesInTransit()) {
+  if (internalFlushExecutor(500, false) && 
flushDeliveriesInTransit()) {
--- End diff --

I will change this to no wait at all. 


> Delivery guard can take too long
> 
>
> Key: ARTEMIS-1328
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1328
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.3.0
>
>
> There is a flush on delivery guard flush.
> if it's taking too long it will block the queue for a long period.
> This needs to be a quick check or keep doing async checks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (AMQ-6789) Warnning on karaf feature

[Terrien Jean-Yves (JIRA)]

Terrien Jean-Yves created AMQ-6789:
--

 Summary: Warnning on karaf feature
 Key: AMQ-6789
 URL: https://issues.apache.org/jira/browse/AMQ-6789
 Project: ActiveMQ
  Issue Type: Bug
  Components: karaf
Affects Versions: 5.12.3
 Environment: Karaf 3.0.6
Reporter: Terrien Jean-Yves
Priority: Minor


2017-08-08 12:52:56,765 | WARN  | l for user karaf | FeatureValidationUtil  
  | 20 - org.apache.karaf.features.core - 3.0.6 | Old style feature file 
without namespace found (URI: 
mvn:org.apache.activemq/activemq-karaf/5.12.3/xml/features). This format is 
deprecated and support for it will soon be removed
2017-08-08 12:52:56,932 | WARN  | l for user karaf | FeatureValidationUtil  
  | 20 - org.apache.karaf.features.core - 3.0.6 | Old style feature file 
without namespace found (URI: 
mvn:org.apache.activemq/activemq-karaf/5.12.3/xml/features-core). This format 
is deprecated and support for it will soon be removed


solution : replace 
 by
http://karaf.apache.org/xmlns/features/v1.2.1; 
name="activemq-core-5.12.3"> in file activemq-karaf-5.12.3-features-core.xml
and 
 by
http://karaf.apache.org/xmlns/features/v1.2.1; 
name="activemq-5.12.3"> in file activemq-karaf-5.12.3-features.xml

Bye



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ARTEMIS-1331) JMS test ConnectionTest#testTXTypeInvalid passes with Core JMS (artemis-jms-client) and fails with the other ones

[Jiri Danek (JIRA)]

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

Jiri Danek updated ARTEMIS-1331:

Description: 
Consider 
{{org.apache.activemq.artemis.tests.integration.jms.client.ConnectionTest#testTXTypeInvalid}}.

If you do 

{noformat}
  Session sess = conn.createSession(false, Session.SESSION_TRANSACTED);
{noformat}

then Core JMS does not throw {{javax.jms.JMSException: acknowledgeMode 
SESSION_TRANSACTED cannot be used for an non-transacted Session}}, the other 
JMS clients do.

So either Core or the other clients do something wrong.

(See full reproducer at 
https://github.com/jdanekrh/jms-reproducers/blob/master/src/test/java/org/apache/activemq/artemis/tests/integration/jms/client/ConnectionTest.java)

  was:
Consider 
{{org.apache.activemq.artemis.tests.integration.jms.client.ConnectionTest#testTXTypeInvalid}}.

If you do 

{noformat}
  Session sess = conn.createSession(false, Session.SESSION_TRANSACTED);
{noformat}

then Core JMS does not throw {{javax.jms.JMSException: acknowledgeMode 
SESSION_TRANSACTED cannot be used for an non-transacted Session}}, the other 
JMS clients do.

So either Core or the other clients do something wrong.


> JMS test ConnectionTest#testTXTypeInvalid passes with Core JMS 
> (artemis-jms-client) and fails with the other ones
> -
>
> Key: ARTEMIS-1331
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1331
> Project: ActiveMQ Artemis
>  Issue Type: Test
>Affects Versions: 2.3.0
>Reporter: Jiri Danek
>Priority: Trivial
>
> Consider 
> {{org.apache.activemq.artemis.tests.integration.jms.client.ConnectionTest#testTXTypeInvalid}}.
> If you do 
> {noformat}
>   Session sess = conn.createSession(false, Session.SESSION_TRANSACTED);
> {noformat}
> then Core JMS does not throw {{javax.jms.JMSException: acknowledgeMode 
> SESSION_TRANSACTED cannot be used for an non-transacted Session}}, the other 
> JMS clients do.
> So either Core or the other clients do something wrong.
> (See full reproducer at 
> https://github.com/jdanekrh/jms-reproducers/blob/master/src/test/java/org/apache/activemq/artemis/tests/integration/jms/client/ConnectionTest.java)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ARTEMIS-1331) JMS test ConnectionTest#testTXTypeInvalid passes with Core JMS (artemis-jms-client) and fails with the other ones

[Jiri Danek (JIRA)]

Jiri Danek created ARTEMIS-1331:
---

 Summary: JMS test ConnectionTest#testTXTypeInvalid passes with 
Core JMS (artemis-jms-client) and fails with the other ones
 Key: ARTEMIS-1331
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1331
 Project: ActiveMQ Artemis
  Issue Type: Test
Affects Versions: 2.3.0
Reporter: Jiri Danek
Priority: Trivial


Consider 
{{org.apache.activemq.artemis.tests.integration.jms.client.ConnectionTest#testTXTypeInvalid}}.

If you do 

{noformat}
  Session sess = conn.createSession(false, Session.SESSION_TRANSACTED);
{noformat}

then Core JMS does not throw {{javax.jms.JMSException: acknowledgeMode 
SESSION_TRANSACTED cannot be used for an non-transacted Session}}, the other 
JMS clients do.

So either Core or the other clients do something wrong.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1330) [DISCUSS] Run JMS tests over many protocols (through different JMS client libraries)

[Jiri Danek (JIRA)]

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

Jiri Danek commented on ARTEMIS-1330:
-

{{org.apache.activemq.artemis.tests.integration.amqp.AmqpFlowControlTest#testAddressIsBlockedForOtherProdudersWhenFull}}

Core: no exception is thrown on last send (not ResourceAllocationException nor 
anything else), but contition addressSize >= MAX_SIZE_BYTES_REJECT_THRESHOLD is 
true.
OpenWire: The test is killed by JUnit timeout, there are two broker exceptions 
in the log
{noformat}
[Thread-1 (activemq-netty-threads)] 18:14:10,755 ERROR 
[org.apache.activemq.artemis.core.server] AMQ224048: Failed to remove temporary 
queue 3693b650-d0f6-4b12-8dd2-c9e2adadc01d: java.lang.NullPointerException
at 
org.apache.activemq.artemis.core.server.management.impl.ManagementServiceImpl.unregisterQueue(ManagementServiceImpl.java:260)
 [:]
at 
org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:581)
 [:]
at 
org.apache.activemq.artemis.core.server.impl.QueueImpl.deleteQueue(QueueImpl.java:1487)
 [:]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1745)
 [:]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1702)
 [:]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1682)
 [:]
at 
org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.run(ServerSessionImpl.java:673)
 [:]
at 
org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:688)
 [:]
at 
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.callFailureListeners(OpenWireConnection.java:416)
 [:]
at 
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.disconnect(OpenWireConnection.java:578)
 [:]
at 
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.disconnect(OpenWireConnection.java:392)
 [:]
at 
org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.removeConnection(OpenWireProtocolManager.java:170)
 [:]
at 
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.fail(OpenWireConnection.java:615)
 [:]
at 
org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:210)
 [:]
at 
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:542)
 [:]
at 
org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:753)
 [:]
at 
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelInactive(ActiveMQChannelHandler.java:78)
 [:]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
 [netty-all-4.1.9.Final.jar:4.1.9.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
 [netty-all-4.1.9.Final.jar:4.1.9.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:224)
 [netty-all-4.1.9.Final.jar:4.1.9.Final]
at 
io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:360)
 [netty-all-4.1.9.Final.jar:4.1.9.Final]
at 
io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:325)
 [netty-all-4.1.9.Final.jar:4.1.9.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
 [netty-all-4.1.9.Final.jar:4.1.9.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
 [netty-all-4.1.9.Final.jar:4.1.9.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:224)
 [netty-all-4.1.9.Final.jar:4.1.9.Final]
at 
io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1329)
 [netty-all-4.1.9.Final.jar:4.1.9.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
 [netty-all-4.1.9.Final.jar:4.1.9.Final]
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
 [netty-all-4.1.9.Final.jar:4.1.9.Final]
at 
io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:908)
 [netty-all-4.1.9.Final.jar:4.1.9.Final]
at 

[jira] [Updated] (ARTEMIS-1330) [DISCUSS] Run JMS tests over many protocols (through different JMS client libraries)

[Jiri Danek (JIRA)]

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

Jiri Danek updated ARTEMIS-1330:

Description: 
Currently, there are three sets of JMS tests in Apache ActiveMQ Artemis 
codebase (that I know of)

* 
activemq-artemis/tests/jms-tests/src/test/java/org/apache/activemq/artemis/jms/tests/*
* 
activemq-artemis/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/jms/*
* 
activemq-artemis/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/*

The first two are being run only through the Core JMS client, while the last 
one is being run through Qpid JMS client (with few exceptions).

It should be beneficial to be able to run all JMS tests through all three 
protocols that Artemis supports that have a JMS client, these being

* Core (artemis-jms-client),
* OpenWire (activemq-client), and
* AMQP (qpid-jms-client).

I made an attempt to convert some of the tests to a parametrized test with 
changeable connection factory. The way 
{{org.apache.activemq.artemis.tests.integration.persistence.SyncSendTest}} 
currently does it. See https://github.com/jdanekrh/activemq-artemis/pull/4

There are the following obstackes

* Some tests go beyond the JMS standardized APIs and cast the JMS object to 
specific implementations in their chosen library.
* Some tests require specific settings on the connection factory, these are not 
portable across different JMS clients. There will have to be branching 
depending on the specific factory currently in use, or something...
* OpenWire client supports JMS 1.1, while Core and AMQP clients are JMS 2.0, 
some tests will have to be skipped on OpenWire
* OpenWire client has different semantics of {{receiver.receiveNoWait()}} call; 
when there are no messages in prefetch cache, OpenWire returns null, while 
other clients do a round trip to server to check for new messages before giving 
up.

There are some improvements which can be considered later, some of these are 
partially implemented in various places

* share broker between individual tests
* use random name or random suffix for created addresses and queues use suffix 
for queues/topics to ensure isolation
* have broker uberconfig for all tests, or group tests by config they need, so 
that reconfiguring broker is limited
* that also allows tests to run in parallel
* use random port for acceptor on broker, can run tests even more parallel, and 
mitigates environmentally caused failures

I intend to report the failures I found so far (see the code at the link above) 
and I am reasonably certain they are actual failures. The rest I plan to note 
in comments here, one test per comment.

If you happen to have any comments and suggestions how to do this better, I'd 
be glad to hear them.

  was:
Currently, there are three sets of JMS tests in Apache ActiveMQ Artemis 
codebase (that I know of)

* 
activemq-artemis/tests/jms-tests/src/test/java/org/apache/activemq/artemis/jms/tests/*
* 
activemq-artemis/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/jms/*
* 
activemq-artemis/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/*

The first two are being run only through the Core JMS client, while the last 
one is being run through Qpid JMS client (with few exceptions).

It should be beneficial to be able to run all JMS tests through all three 
protocols that Artemis supports that have a JMS client, these being

* Core (artemis-jms-client),
* OpenWire (activemq-client), and
* AMQP (qpid-jms-client).

I made an attempt to convert some of the tests to a parametrized test with 
changeable connection factory. The way 
{{org.apache.activemq.artemis.tests.integration.persistence.SyncSendTest}} 
currently does it.

There are the following obstackes

* Some tests go beyond the JMS standardized APIs and cast the JMS object to 
specific implementations in their chosen library.
* Some tests require specific settings on the connection factory, these are not 
portable across different JMS clients. There will have to be branching 
depending on the specific factory currently in use, or something...
* OpenWire client supports JMS 1.1, while Core and AMQP clients are JMS 2.0, 
some tests will have to be skipped on OpenWire
* OpenWire client has different semantics of {{receiver.receiveNoWait()}} call; 
when there are no messages in prefetch cache, OpenWire returns null, while 
other clients do a round trip to server to check for new messages before giving 
up.

There are some improvements which can be considered later, some of these are 
partially implemented in various places

* share broker between individual tests
* use random name or random suffix for created addresses and queues use suffix 
for queues/topics to ensure isolation
* have broker uberconfig for all tests, or group tests by config they need, 

[jira] [Reopened] (ARTEMIS-1327) Support checked exceptions from ActiveMQServerPlugin

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon reopened ARTEMIS-1327:
-

> Support checked exceptions from ActiveMQServerPlugin
> 
>
> Key: ARTEMIS-1327
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1327
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
> Fix For: 2.3.0
>
>
> After I was writing a couple custom plugins I realized it would be beneficial 
> to support checked exceptions.  This makes error handling simpler for plugin 
> writers as they can throw various exceptions and not have to always wrap them 
> in a RuntimeException.  Almost every place in the broker where plugin methods 
> are currently called already support handling checked Exceptions so this is 
> pretty simple and mostly we just need to add a "throws Exception" to each of 
> the methods in the ActiveMQServerPlugin interface and make sure the methods 
> used to execute the plugin methods also support it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (ARTEMIS-1327) Support checked exceptions from ActiveMQServerPlugin

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon resolved ARTEMIS-1327.
-
Resolution: Fixed

> Support checked exceptions from ActiveMQServerPlugin
> 
>
> Key: ARTEMIS-1327
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1327
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
> Fix For: 2.3.0
>
>
> After I was writing a couple custom plugins I realized it would be beneficial 
> to support checked exceptions.  This makes error handling simpler for plugin 
> writers as they can throw various exceptions and not have to always wrap them 
> in a RuntimeException.  Almost every place in the broker where plugin methods 
> are currently called already support handling checked Exceptions so this is 
> pretty simple and mostly we just need to add a "throws Exception" to each of 
> the methods in the ActiveMQServerPlugin interface and make sure the methods 
> used to execute the plugin methods also support it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (ARTEMIS-1327) Support checked exceptions from ActiveMQServerPlugin

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon closed ARTEMIS-1327.
---
Resolution: Fixed

> Support checked exceptions from ActiveMQServerPlugin
> 
>
> Key: ARTEMIS-1327
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1327
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
> Fix For: 2.3.0
>
>
> After I was writing a couple custom plugins I realized it would be beneficial 
> to support checked exceptions.  This makes error handling simpler for plugin 
> writers as they can throw various exceptions and not have to always wrap them 
> in a RuntimeException.  Almost every place in the broker where plugin methods 
> are currently called already support handling checked Exceptions so this is 
> pretty simple and mostly we just need to add a "throws Exception" to each of 
> the methods in the ActiveMQServerPlugin interface and make sure the methods 
> used to execute the plugin methods also support it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ARTEMIS-1330) [DISCUSS] Run JMS tests over many protocols (through different JMS client libraries)

[Jiri Danek (JIRA)]

Jiri Danek created ARTEMIS-1330:
---

 Summary: [DISCUSS] Run JMS tests over many protocols (through 
different JMS client libraries)
 Key: ARTEMIS-1330
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1330
 Project: ActiveMQ Artemis
  Issue Type: Test
  Components: AMQP, OpenWire
Affects Versions: 2.3.0
Reporter: Jiri Danek
Priority: Minor


Currently, there are three sets of JMS tests in Apache ActiveMQ Artemis 
codebase (that I know of)

* 
activemq-artemis/tests/jms-tests/src/test/java/org/apache/activemq/artemis/jms/tests/*
* 
activemq-artemis/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/jms/*
* 
activemq-artemis/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/*

The first two are being run only through the Core JMS client, while the last 
one is being run through Qpid JMS client (with few exceptions).

It should be beneficial to be able to run all JMS tests through all three 
protocols that Artemis supports that have a JMS client, these being

* Core (artemis-jms-client),
* OpenWire (activemq-client), and
* AMQP (qpid-jms-client).

I made an attempt to convert some of the tests to a parametrized test with 
changeable connection factory. The way 
{{org.apache.activemq.artemis.tests.integration.persistence.SyncSendTest}} 
currently does it.

There are the following obstackes

* Some tests go beyond the JMS standardized APIs and cast the JMS object to 
specific implementations in their chosen library.
* Some tests require specific settings on the connection factory, these are not 
portable across different JMS clients. There will have to be branching 
depending on the specific factory currently in use, or something...
* OpenWire client supports JMS 1.1, while Core and AMQP clients are JMS 2.0, 
some tests will have to be skipped on OpenWire
* OpenWire client has different semantics of {{receiver.receiveNoWait()}} call; 
when there are no messages in prefetch cache, OpenWire returns null, while 
other clients do a round trip to server to check for new messages before giving 
up.

There are some improvements which can be considered later, some of these are 
partially implemented in various places

* share broker between individual tests
* use random name or random suffix for created addresses and queues use suffix 
for queues/topics to ensure isolation
* have broker uberconfig for all tests, or group tests by config they need, so 
that reconfiguring broker is limited
* that also allows tests to run in parallel
* use random port for acceptor on broker, can run tests even more parallel, and 
mitigates environmentally caused failures

I intend to report the failures I found so far and I am reasonably certain they 
are actual failures. The rest I plan to note in comments here, one test per 
comment.

If you happen to have any comments and suggestions how to do this better, I'd 
be glad to hear them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1327) Support checked exceptions from ActiveMQServerPlugin

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1327:
-

Github user cshannon commented on the issue:

https://github.com/apache/activemq-artemis/pull/1445
  
@clebertsuconic - This looks good to me


> Support checked exceptions from ActiveMQServerPlugin
> 
>
> Key: ARTEMIS-1327
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1327
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
> Fix For: 2.3.0
>
>
> After I was writing a couple custom plugins I realized it would be beneficial 
> to support checked exceptions.  This makes error handling simpler for plugin 
> writers as they can throw various exceptions and not have to always wrap them 
> in a RuntimeException.  Almost every place in the broker where plugin methods 
> are currently called already support handling checked Exceptions so this is 
> pretty simple and mostly we just need to add a "throws Exception" to each of 
> the methods in the ActiveMQServerPlugin interface and make sure the methods 
> used to execute the plugin methods also support it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ARTEMIS-1329) JMS test NoLocalSubscriberTest#testNoLocalReconnect fails with OpenWire protocol (activemq-client JMS library)

[Jiri Danek (JIRA)]

Jiri Danek created ARTEMIS-1329:
---

 Summary: JMS test NoLocalSubscriberTest#testNoLocalReconnect fails 
with OpenWire protocol (activemq-client JMS library)
 Key: ARTEMIS-1329
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1329
 Project: ActiveMQ Artemis
  Issue Type: Test
  Components: OpenWire
Affects Versions: 2.3.0
Reporter: Jiri Danek


Consider test 
org.apache.activemq.artemis.tests.integration.jms.client.NoLocalSubscriberTest#testNoLocalReconnect.

When it is adapted to run with multiple JMS, or when run from the standalone 
reproducer at 
https://github.com/jdanekrh/jms-reproducers/blob/NoLocalSubscriberTest/src/test/java/org/apache/activemq/artemis/tests/integration/jms/client/NoLocalSubscriberTest.java
(the standalone reproducer requires a running broker to connect to), the test 
passes with Core and AMQP protocols,
and fails with Core at assertion

{noformat}
 // now drain the subscription
 // we should not receive message M3, but we should receive message M4
 // However for some reason Artemis doesn't receive either
 TextMessage textMessage = (TextMessage) topicSubscriber.receive(1000);
 assertNotNull(textMessage);
{noformat}

With exception

{noformat}
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:621)
at org.junit.Assert.assertNotNull(Assert.java:631)
at 
org.apache.activemq.artemis.tests.integration.jms.client.NoLocalSubscriberTest.testNoLocalReconnect(NoLocalSubscriberTest.java:178)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at 
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at 
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at 
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ARTEMIS-1329) JMS test NoLocalSubscriberTest#testNoLocalReconnect fails with OpenWire protocol (activemq-client JMS library)

[Jiri Danek (JIRA)]

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

Jiri Danek updated ARTEMIS-1329:

Description: 
Consider test 
org.apache.activemq.artemis.tests.integration.jms.client.NoLocalSubscriberTest#testNoLocalReconnect.

When it is adapted to run with multiple JMS clients, or when run from the 
standalone reproducer at 
https://github.com/jdanekrh/jms-reproducers/blob/NoLocalSubscriberTest/src/test/java/org/apache/activemq/artemis/tests/integration/jms/client/NoLocalSubscriberTest.java
(the standalone reproducer requires a running broker to connect to), the test 
passes with Core and AMQP protocols,
and fails with Core at assertion

{noformat}
 // now drain the subscription
 // we should not receive message M3, but we should receive message M4
 // However for some reason Artemis doesn't receive either
 TextMessage textMessage = (TextMessage) topicSubscriber.receive(1000);
 assertNotNull(textMessage);
{noformat}

With exception

{noformat}
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:621)
at org.junit.Assert.assertNotNull(Assert.java:631)
at 
org.apache.activemq.artemis.tests.integration.jms.client.NoLocalSubscriberTest.testNoLocalReconnect(NoLocalSubscriberTest.java:178)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at 
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at 
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at 
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
{noformat}

  was:
Consider test 
org.apache.activemq.artemis.tests.integration.jms.client.NoLocalSubscriberTest#testNoLocalReconnect.

When it is adapted to run with multiple JMS, or when run from the standalone 
reproducer at 
https://github.com/jdanekrh/jms-reproducers/blob/NoLocalSubscriberTest/src/test/java/org/apache/activemq/artemis/tests/integration/jms/client/NoLocalSubscriberTest.java
(the standalone reproducer requires a running 

[jira] [Commented] (AMQ-6788) ClassNotFoundException PListStoreImpl when trying to start an embedded broker with memory persistence

[Christian Schneider (JIRA)]

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

Christian Schneider commented on AMQ-6788:
--

As a workaround I found that I can do:
broker.setPersistent(false);

Still I think this is a bug.

> ClassNotFoundException PListStoreImpl when trying to start an embedded broker 
> with memory persistence
> -
>
> Key: AMQ-6788
> URL: https://issues.apache.org/jira/browse/AMQ-6788
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.15.0
> Environment: Ubuntu Linux, ActiveMQ 5.15.0
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: 5.15.1
>
>
> I try to start an embedded broker:
> broker = new BrokerService();
> broker.setPersistenceAdapter(new MemoryPersistenceAdapter());
> broker.start();
> java.lang.RuntimeException: java.lang.ClassNotFoundException: 
> org.apache.activemq.store.kahadb.plist.PListStoreImpl
> For details see:
> https://apaste.info/vIkj



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (AMQ-6788) ClassNotFoundException PListStoreImpl when trying to start an embedded broker with memory persistence

[Christian Schneider (JIRA)]

Christian Schneider created AMQ-6788:


 Summary: ClassNotFoundException PListStoreImpl when trying to 
start an embedded broker with memory persistence
 Key: AMQ-6788
 URL: https://issues.apache.org/jira/browse/AMQ-6788
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.15.0
 Environment: Ubuntu Linux, ActiveMQ 5.15.0
Reporter: Christian Schneider
Assignee: Christian Schneider
 Fix For: 5.15.1


I try to start an embedded broker:
broker = new BrokerService();
broker.setPersistenceAdapter(new MemoryPersistenceAdapter());
broker.start();

java.lang.RuntimeException: java.lang.ClassNotFoundException: 
org.apache.activemq.store.kahadb.plist.PListStoreImpl

For details see:
https://apaste.info/vIkj



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1328) Delivery guard can take too long

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1328:
-

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

https://github.com/apache/activemq-artemis/pull/1447#discussion_r131832623
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java
 ---
@@ -664,7 +664,7 @@ public void addTail(final MessageReference ref, final 
boolean direct) {
if (intermediateMessageReferences.isEmpty() && 
messageReferences.isEmpty() && !pageIterator.hasNext() && 
!pageSubscription.isPaging()) {
   // We must block on the executor to ensure any async 
deliveries have completed or we might get out of order
   // deliveries
-  if (flushExecutor() && flushDeliveriesInTransit()) {
+  if (internalFlushExecutor(500, false) && 
flushDeliveriesInTransit()) {
--- End diff --

Why 500 why not 100, if the issue was previously it was taking too long 
surely we want this as small as safely possible?


> Delivery guard can take too long
> 
>
> Key: ARTEMIS-1328
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1328
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.3.0
>
>
> There is a flush on delivery guard flush.
> if it's taking too long it will block the queue for a long period.
> This needs to be a quick check or keep doing async checks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)