[jira] [Commented] (ARTEMIS-1853) Adding Netty OpenSSL provider test

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1853:
-

GitHub user gaohoward opened a pull request:

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

ARTEMIS-1853 Adding Netty OpenSSL provider test

Added some netty openssl tests
Fix a NPE issue

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

$ git pull https://github.com/gaohoward/activemq-artemis g_openssl2

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

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


commit 246e32d0a1854ce40cabb8e2b3b38344ab532ad6
Author: Howard Gao 
Date:   2018-05-17T22:50:37Z

ARTEMIS-1853 Adding Netty OpenSSL provider test

Added some netty openssl tests
Fix a NPE issue




> Adding Netty OpenSSL provider test
> --
>
> Key: ARTEMIS-1853
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1853
> Project: ActiveMQ Artemis
>  Issue Type: Test
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.7.0
>
>
> Make sure netty's openssl provider works.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1871) Artemis STOMP heartbeater continues after client is gone

[Jon Kranes (JIRA)]

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

Jon Kranes updated ARTEMIS-1871:

Description: 
Under specific conditions the STOMP server continues to execute the heartbeat 
runnable task even after the client connection has closed.  In the extreme case 
this can result in eventual server failure since a new StompConnection and 
associated scheduled task are kept in memory indefinitely and a new one is 
created each time a client connects.  Therefore if a client repeatedly connects 
and triggers the error in a loop, eventually the server will run out of 
resources.

The condition occurs when using STOMP 1.2, if a client sends a duplicate 
subscription ID.  The server correctly sends an ERROR frame to the client and 
closes the connection, but does not properly clean up the heartbeater which 
continues to run indefinitely according to the defined interval, even though 
there is no client to respond.

See the attached integration test for details.  (This is a modified version of 
an existing test for a similar issue that was fixed for version 1.5.3).  The 
test code is 
src/test/java/org/apache/artemis/tests/integration/stomp/v11/StompV11Test.java.

  was:
Under specific conditions the STOMP server continues to execute the heartbeat 
runnable task even after the client connection has closed.  In the extreme case 
this can result in eventual server failure since a new StompConnection and 
associated scheduled task are kept in memory indefinitely and a new one is 
created each time a client connects.  Therefore if a client repeatedly connects 
and triggers the error in a loop, eventually the server will run out of 
resources.

The condition occurs when using STOMP 1.2, if a client sends a duplicate 
subscription ID.  The server correctly sends an ERROR frame to the client and 
closes the connection, but does not properly clean up the heartbeater which 
continues to run indefinitely according to the defined interval, even though 
there is no client to respond.

See the attached integration test for details.  (This is a modified version of 
an existing test for a similar issue that was fixed for version 1.5.3).


> Artemis STOMP heartbeater continues after client is gone
> 
>
> Key: ARTEMIS-1871
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1871
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: STOMP
>Affects Versions: 1.5.3
>Reporter: Jon Kranes
>Assignee: Justin Bertram
>Priority: Major
> Attachments: integration-tests.zip
>
>
> Under specific conditions the STOMP server continues to execute the heartbeat 
> runnable task even after the client connection has closed.  In the extreme 
> case this can result in eventual server failure since a new StompConnection 
> and associated scheduled task are kept in memory indefinitely and a new one 
> is created each time a client connects.  Therefore if a client repeatedly 
> connects and triggers the error in a loop, eventually the server will run out 
> of resources.
> The condition occurs when using STOMP 1.2, if a client sends a duplicate 
> subscription ID.  The server correctly sends an ERROR frame to the client and 
> closes the connection, but does not properly clean up the heartbeater which 
> continues to run indefinitely according to the defined interval, even though 
> there is no client to respond.
> See the attached integration test for details.  (This is a modified version 
> of an existing test for a similar issue that was fixed for version 1.5.3).  
> The test code is 
> src/test/java/org/apache/artemis/tests/integration/stomp/v11/StompV11Test.java.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1871) Artemis STOMP heartbeater continues after client is gone

[Jon Kranes (JIRA)]

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

Jon Kranes updated ARTEMIS-1871:

Description: 
Under specific conditions the STOMP server continues to execute the heartbeat 
runnable task even after the client connection has closed.  In the extreme case 
this can result in eventual server failure since a new StompConnection and 
associated scheduled task are kept in memory indefinitely and a new one is 
created each time a client connects.  Therefore if a client repeatedly connects 
and triggers the error in a loop, eventually the server will run out of 
resources.

The condition occurs when using STOMP 1.2, if a client sends a duplicate 
subscription ID.  The server correctly sends an ERROR frame to the client and 
closes the connection, but does not properly clean up the heartbeater which 
continues to run indefinitely according to the defined interval, even though 
there is no client to respond.

See the attached integration test for details.  (This is a modified version of 
an existing test for a similar issue that was fixed for version 1.5.3).

  was:
Under specific conditions the STOMP server continues to execute the heartbeat 
runnable task even after the client connection has closed.  In the extreme case 
this can result in eventual server failure since a new StompConnection and 
associated objects are kept in memory indefinitely and a new one is created 
each time a client connects.  Therefore if a client repeatedly connects and 
triggers the error in a loop, eventually the server will run out of resources.

The condition occurs when using STOMP 1.2, if a client sends a duplicate 
subscription ID.  The server correctly sends an ERROR frame to the client and 
closes the connection, but does not properly clean up the heartbeater which 
continues to run indefinitely according to the defined interval, even though 
there is no client to respond.

See the attached integration test for details.  (This is a modified version of 
an existing test for a similar issue that was fixed for version 1.5.3).


> Artemis STOMP heartbeater continues after client is gone
> 
>
> Key: ARTEMIS-1871
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1871
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: STOMP
>Affects Versions: 1.5.3
>Reporter: Jon Kranes
>Assignee: Justin Bertram
>Priority: Major
> Attachments: integration-tests.zip
>
>
> Under specific conditions the STOMP server continues to execute the heartbeat 
> runnable task even after the client connection has closed.  In the extreme 
> case this can result in eventual server failure since a new StompConnection 
> and associated scheduled task are kept in memory indefinitely and a new one 
> is created each time a client connects.  Therefore if a client repeatedly 
> connects and triggers the error in a loop, eventually the server will run out 
> of resources.
> The condition occurs when using STOMP 1.2, if a client sends a duplicate 
> subscription ID.  The server correctly sends an ERROR frame to the client and 
> closes the connection, but does not properly clean up the heartbeater which 
> continues to run indefinitely according to the defined interval, even though 
> there is no client to respond.
> See the attached integration test for details.  (This is a modified version 
> of an existing test for a similar issue that was fixed for version 1.5.3).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1871) Artemis STOMP heartbeater continues after client is gone

[Jon Kranes (JIRA)]

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

Jon Kranes updated ARTEMIS-1871:

Description: 
Under specific conditions the STOMP server continues to execute the heartbeat 
runnable task even after the client connection has closed.  In the extreme case 
this can result in eventual server failure since a new StompConnection and 
associated objects are kept in memory indefinitely and a new one is created 
each time a client connects.  Therefore if a client repeatedly connects and 
triggers the error in a loop, eventually the server will run out of resources.

The condition occurs when using STOMP 1.2, if a client sends a duplicate 
subscription ID.  The server correctly sends an ERROR frame to the client and 
closes the connection, but does not properly clean up the heartbeater which 
continues to run indefinitely according to the defined interval, even though 
there is no client to respond.

See the attached integration test for details.  (This is a modified version of 
an existing test for a similar issue that was fixed for version 1.5.3).

  was:
Under specific conditions the STOMP server continues to execute heartbeat logic 
even after the client connection has closed.  In the extreme case this can 
result in eventual server failure since a new StompConnection and associated 
objects are kept in memory indefinitely and a new one is created each time a 
client connects.  Therefore if a client repeatedly connects and triggers the 
error in a loop, eventually the server will run out of resources.

The condition occurs when using STOMP 1.2, if a client sends a duplicate 
subscription ID.  The server correctly sends an ERROR frame to the client and 
closes the connection, but does not properly clean up the heartbeater which 
continues to run indefinitely according to the defined interval, even though 
there is no client to respond.

See the attached integration test for details.  (This is a modified version of 
an existing test for a similar issue that was fixed for version 1.5.3).


> Artemis STOMP heartbeater continues after client is gone
> 
>
> Key: ARTEMIS-1871
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1871
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: STOMP
>Affects Versions: 1.5.3
>Reporter: Jon Kranes
>Assignee: Justin Bertram
>Priority: Major
> Attachments: integration-tests.zip
>
>
> Under specific conditions the STOMP server continues to execute the heartbeat 
> runnable task even after the client connection has closed.  In the extreme 
> case this can result in eventual server failure since a new StompConnection 
> and associated objects are kept in memory indefinitely and a new one is 
> created each time a client connects.  Therefore if a client repeatedly 
> connects and triggers the error in a loop, eventually the server will run out 
> of resources.
> The condition occurs when using STOMP 1.2, if a client sends a duplicate 
> subscription ID.  The server correctly sends an ERROR frame to the client and 
> closes the connection, but does not properly clean up the heartbeater which 
> continues to run indefinitely according to the defined interval, even though 
> there is no client to respond.
> See the attached integration test for details.  (This is a modified version 
> of an existing test for a similar issue that was fixed for version 1.5.3).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARTEMIS-1871) Artemis STOMP heartbeater continues after client is gone

[Jon Kranes (JIRA)]

Jon Kranes created ARTEMIS-1871:
---

 Summary: Artemis STOMP heartbeater continues after client is gone
 Key: ARTEMIS-1871
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1871
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: STOMP
Affects Versions: 1.5.3
Reporter: Jon Kranes
Assignee: Justin Bertram
 Attachments: integration-tests.zip

Under specific conditions the STOMP server continues to execute heartbeat logic 
even after the client connection has closed.  In the extreme case this can 
result in eventual server failure since a new StompConnection and associated 
objects are kept in memory indefinitely and a new one is created each time a 
client connects.  Therefore if a client repeatedly connects and triggers the 
error in a loop, eventually the server will run out of resources.

The condition occurs when using STOMP 1.2, if a client sends a duplicate 
subscription ID.  The server correctly sends an ERROR frame to the client and 
closes the connection, but does not properly clean up the heartbeater which 
continues to run indefinitely according to the defined interval, even though 
there is no client to respond.

See the attached integration test for details.  (This is a modified version of 
an existing test for a similar issue that was fixed for version 1.5.3).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1871) Artemis STOMP heartbeater continues after client is gone

[Jon Kranes (JIRA)]

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

Jon Kranes updated ARTEMIS-1871:

Attachment: integration-tests.zip

> Artemis STOMP heartbeater continues after client is gone
> 
>
> Key: ARTEMIS-1871
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1871
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: STOMP
>Affects Versions: 1.5.3
>Reporter: Jon Kranes
>Assignee: Justin Bertram
>Priority: Major
> Attachments: integration-tests.zip
>
>
> Under specific conditions the STOMP server continues to execute heartbeat 
> logic even after the client connection has closed.  In the extreme case this 
> can result in eventual server failure since a new StompConnection and 
> associated objects are kept in memory indefinitely and a new one is created 
> each time a client connects.  Therefore if a client repeatedly connects and 
> triggers the error in a loop, eventually the server will run out of resources.
> The condition occurs when using STOMP 1.2, if a client sends a duplicate 
> subscription ID.  The server correctly sends an ERROR frame to the client and 
> closes the connection, but does not properly clean up the heartbeater which 
> continues to run indefinitely according to the defined interval, even though 
> there is no client to respond.
> See the attached integration test for details.  (This is a modified version 
> of an existing test for a similar issue that was fixed for version 1.5.3).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1867) Support FQQN in STOMP

[Justin Bertram (JIRA)]

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

Justin Bertram commented on ARTEMIS-1867:
-

To be clear, FQQN consumers are already supported.

> Support FQQN in STOMP
> -
>
> Key: ARTEMIS-1867
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1867
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: STOMP
>Reporter: Justin Bertram
>Priority: Major
>
> Allow STOMP clients to send messages directly to a fully-qualified queue 
> rather than just an address.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (ARTEMIS-1783) Exception in thread "main" java.lang.BootstrapMethodError: java.lang.NoClassDefFoundError: com/google/common/base/Supplier

[clebert suconic (JIRA)]

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

clebert suconic reopened ARTEMIS-1783:
--

> Exception in thread "main" java.lang.BootstrapMethodError: 
> java.lang.NoClassDefFoundError: com/google/common/base/Supplier
> --
>
> Key: ARTEMIS-1783
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1783
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Jiri Daněk
>Assignee: Justin Bertram
>Priority: Trivial
> Fix For: 2.6.0
>
>
> When using my program cli-artemis-jms at 
> https://github.com/rh-messaging/cli-java, which depends on 
> activemq-artemis-jms-client, I get the following stack trace
> {noformat}
> junit5(?) $ java -jar systemtests/client_executable/cli-artemis-jms.jar 
> receiver --address test --log-msgs json --count 0
> Exception in thread "main" java.lang.BootstrapMethodError: 
> java.lang.NoClassDefFoundError: com/google/common/base/Supplier
> at 
> org.apache.activemq.artemis.core.message.impl.CoreMessageObjectPools.(CoreMessageObjectPools.java:26)
> at 
> org.apache.activemq.artemis.core.protocol.ClientPacketDecoder.(ClientPacketDecoder.java:36)
> at 
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createPacketDecoder(ActiveMQClientProtocolManager.java:520)
> at 
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.connect(ActiveMQClientProtocolManager.java:412)
> at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1273)
> at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:891)
> at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:795)
> at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:238)
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:784)
> at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:813)
> at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:277)
> at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:272)
> at 
> com.redhat.mqe.acc.AccConnectionManager.(AccConnectionManager.java:68)
> at 
> com.redhat.mqe.acc.AccConnectionManagerFactory.make(AccConnectionManagerFactory.java:33)
> at 
> com.redhat.mqe.acc.AccConnectionManagerFactory.make(AccConnectionManagerFactory.java:27)
> at com.redhat.mqe.lib.CoreClient.createConnection(CoreClient.java:86)
> at 
> com.redhat.mqe.lib.ReceiverClient.consumeMessage(ReceiverClient.java:170)
> at 
> com.redhat.mqe.lib.ReceiverClient.startClient(ReceiverClient.java:147)
> at com.redhat.mqe.lib.Main.main(Main.java:50)
> at com.redhat.mqe.acc.Main.main(Main.java:74)
> Caused by: java.lang.NoClassDefFoundError: com/google/common/base/Supplier
> ... 20 more
> Caused by: java.lang.ClassNotFoundException: com.google.common.base.Supplier
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 20 more
> {noformat}
> I get this with artemis-jms-client 2.5.0, but not with artemis-jms-client 
> 2.4.0.
> I believe the guilty commit is in ARTEMIS-1586, "794e56da99456e Refactor to 
> make more generic", which introduced usage of Google Guava, without adding it 
> to the package's pom file, causing my maven to miss that transitive 
> dependency when building uberjar.
> The command above runs when triggered from Intellij IDE, where the dependency 
> is on classpath, for some reason.
> Workaround is easy, add Guava to dependencies of your own program which is 
> using the artemis jms library.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (ARTEMIS-1783) Exception in thread "main" java.lang.BootstrapMethodError: java.lang.NoClassDefFoundError: com/google/common/base/Supplier

[clebert suconic (JIRA)]

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

clebert suconic closed ARTEMIS-1783.

Resolution: Fixed

> Exception in thread "main" java.lang.BootstrapMethodError: 
> java.lang.NoClassDefFoundError: com/google/common/base/Supplier
> --
>
> Key: ARTEMIS-1783
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1783
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Jiri Daněk
>Assignee: Justin Bertram
>Priority: Trivial
> Fix For: 2.6.0
>
>
> When using my program cli-artemis-jms at 
> https://github.com/rh-messaging/cli-java, which depends on 
> activemq-artemis-jms-client, I get the following stack trace
> {noformat}
> junit5(?) $ java -jar systemtests/client_executable/cli-artemis-jms.jar 
> receiver --address test --log-msgs json --count 0
> Exception in thread "main" java.lang.BootstrapMethodError: 
> java.lang.NoClassDefFoundError: com/google/common/base/Supplier
> at 
> org.apache.activemq.artemis.core.message.impl.CoreMessageObjectPools.(CoreMessageObjectPools.java:26)
> at 
> org.apache.activemq.artemis.core.protocol.ClientPacketDecoder.(ClientPacketDecoder.java:36)
> at 
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createPacketDecoder(ActiveMQClientProtocolManager.java:520)
> at 
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.connect(ActiveMQClientProtocolManager.java:412)
> at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1273)
> at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:891)
> at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:795)
> at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:238)
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:784)
> at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:813)
> at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:277)
> at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:272)
> at 
> com.redhat.mqe.acc.AccConnectionManager.(AccConnectionManager.java:68)
> at 
> com.redhat.mqe.acc.AccConnectionManagerFactory.make(AccConnectionManagerFactory.java:33)
> at 
> com.redhat.mqe.acc.AccConnectionManagerFactory.make(AccConnectionManagerFactory.java:27)
> at com.redhat.mqe.lib.CoreClient.createConnection(CoreClient.java:86)
> at 
> com.redhat.mqe.lib.ReceiverClient.consumeMessage(ReceiverClient.java:170)
> at 
> com.redhat.mqe.lib.ReceiverClient.startClient(ReceiverClient.java:147)
> at com.redhat.mqe.lib.Main.main(Main.java:50)
> at com.redhat.mqe.acc.Main.main(Main.java:74)
> Caused by: java.lang.NoClassDefFoundError: com/google/common/base/Supplier
> ... 20 more
> Caused by: java.lang.ClassNotFoundException: com.google.common.base.Supplier
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 20 more
> {noformat}
> I get this with artemis-jms-client 2.5.0, but not with artemis-jms-client 
> 2.4.0.
> I believe the guilty commit is in ARTEMIS-1586, "794e56da99456e Refactor to 
> make more generic", which introduced usage of Google Guava, without adding it 
> to the package's pom file, causing my maven to miss that transitive 
> dependency when building uberjar.
> The command above runs when triggered from Intellij IDE, where the dependency 
> is on classpath, for some reason.
> Workaround is easy, add Guava to dependencies of your own program which is 
> using the artemis jms library.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1802) Cannot use the same name for a divert and an address

[Justin Bertram (JIRA)]

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

Justin Bertram updated ARTEMIS-1802:

Priority: Minor  (was: Major)

> Cannot use the same name for a divert and an address
> 
>
> Key: ARTEMIS-1802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1802
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 2.5.0
>Reporter: Lionel Cons
>Priority: Minor
>
> I'm trying to use diverts to emulate ActiveMQ 5's virtual destinations 
> (http://activemq.apache.org/virtual-destinations.html). The use case is a 
> single topic ({{foo}}) bound to two queues ({{foo-test}} and {{foo-prod}}).
> The following configuration snippet almost works:
> {code:xml}
>   
> 
> 
>   
> 
> 
> 
>   
> 
>   
> 
> 
> 
>   
> 
>   
> 
> ...
>   
>   
> 
> 
>   foo
>   foo-test
>   false
> 
> 
> 
>   foo
>   foo-prod
>   false
> 
>   
> {code}
> Artemis give me an error:
> {code}
> AMQ222006: Binding already exists with name foo-test, divert will not be 
> deployed
> {code}
> Changing the divert names fixes the problem.
> Why can't I use the same name both for the queue and the divert feeding the 
> queue?
> Since these are different kinds of objects, I should be able to reuse the 
> same name, shouldn't I?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1802) Cannot use the same name for a divert and an address

[Justin Bertram (JIRA)]

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

Justin Bertram updated ARTEMIS-1802:

Issue Type: Improvement  (was: Bug)

> Cannot use the same name for a divert and an address
> 
>
> Key: ARTEMIS-1802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1802
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 2.5.0
>Reporter: Lionel Cons
>Priority: Major
>
> I'm trying to use diverts to emulate ActiveMQ 5's virtual destinations 
> (http://activemq.apache.org/virtual-destinations.html). The use case is a 
> single topic ({{foo}}) bound to two queues ({{foo-test}} and {{foo-prod}}).
> The following configuration snippet almost works:
> {code:xml}
>   
> 
> 
>   
> 
> 
> 
>   
> 
>   
> 
> 
> 
>   
> 
>   
> 
> ...
>   
>   
> 
> 
>   foo
>   foo-test
>   false
> 
> 
> 
>   foo
>   foo-prod
>   false
> 
>   
> {code}
> Artemis give me an error:
> {code}
> AMQ222006: Binding already exists with name foo-test, divert will not be 
> deployed
> {code}
> Changing the divert names fixes the problem.
> Why can't I use the same name both for the queue and the divert feeding the 
> queue?
> Since these are different kinds of objects, I should be able to reuse the 
> same name, shouldn't I?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ARTEMIS-1869) Cannot consume using STOMP a message published using MQTT

[Justin Bertram (JIRA)]

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

Justin Bertram resolved ARTEMIS-1869.
-
Resolution: Cannot Reproduce

[~lionel.cons], please re-open this issue if you're able to reproduce it as 
currently it seems like it's an issue with your transformer.

> Cannot consume using STOMP a message published using MQTT
> -
>
> Key: ARTEMIS-1869
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1869
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> I have a test MQTT producer that sends a message to an address. There is a 
> queue bound to this address and I can see the message using the web console. 
> Message count is 1.
> I have a test STOMP consumer subscribing to this queue. It does not get the 
> message.
> If I then start a STOMP publisher to send a message to the same address. The 
> message appears in the same queue. Message count is now 2.
> I then start again the STOMP consumer and it does get the STOMP published 
> message (and message count goes down to 1) but it does not get the MQTT 
> published message. Why?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1729) Automatically check for broken documentation links

[Justin Bertram (JIRA)]

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

Justin Bertram updated ARTEMIS-1729:

Priority: Minor  (was: Major)

> Automatically check for broken documentation links
> --
>
> Key: ARTEMIS-1729
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1729
> Project: ActiveMQ Artemis
>  Issue Type: Wish
>Reporter: Lionel Cons
>Priority: Minor
>
> The Artemis GitBook documentation sometimes contains broken (internal) links. 
> See for instance ARTEMIS-1076 or ARTEMIS-1721.
> It would be good to automatically check for broken links as part of the Maven 
> {{test}} task.
> One way to do this would be to have a Maven task to run a webserver serving 
> the generated documentation (Python can trivially do it with '{{python -m 
> SimpleHTTPServer 8000}}' but an equivalent Java-based solution is probably 
> better) and then a crawler checking for broken links ({{wget}} can easily be 
> used for this as described in ARTEMIS-1076 but here again a Java-based 
> solution is maybe better).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1729) Automatically check for broken documentation links

[Justin Bertram (JIRA)]

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

Justin Bertram updated ARTEMIS-1729:

Issue Type: Wish  (was: Bug)

> Automatically check for broken documentation links
> --
>
> Key: ARTEMIS-1729
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1729
> Project: ActiveMQ Artemis
>  Issue Type: Wish
>Reporter: Lionel Cons
>Priority: Major
>
> The Artemis GitBook documentation sometimes contains broken (internal) links. 
> See for instance ARTEMIS-1076 or ARTEMIS-1721.
> It would be good to automatically check for broken links as part of the Maven 
> {{test}} task.
> One way to do this would be to have a Maven task to run a webserver serving 
> the generated documentation (Python can trivially do it with '{{python -m 
> SimpleHTTPServer 8000}}' but an equivalent Java-based solution is probably 
> better) and then a crawler checking for broken links ({{wget}} can easily be 
> used for this as described in ARTEMIS-1076 but here again a Java-based 
> solution is maybe better).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1866) Make wait time for reply configurable once vote goes out to acquire a quorum.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1866:
-

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2089
  
@RaiSaurabh In addition, I have notived the both `ReplicaPolicy` and 
`ReplicatedPolicy` have `quorumVoteWait` mutable and not final, while they are 
not supposed to change that value after construction.


> Make wait time for reply configurable once vote goes out to acquire a quorum.
> -
>
> Key: ARTEMIS-1866
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1866
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Saurabh Rai
>Priority: Major
>
> Quorum voting is used by both the live and the backup to decide what to do if 
> a replication connection is disconnected. Basically, the server will request 
> each live server in the cluster to vote as to whether it thinks the server it 
> is replicating to or from is still alive. You can also configure the time for 
> which the quorum manager will wait for the quorum vote response. Currently, 
> the value is hardcoded as 30 sec. We should change this 30-second wait to be 
> configurable.
> Please find the logs for reference:
> 2018-05-06 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] 
> AMQ221066: Initiating quorum vote: LiveFailoverQuorumVote 2018-05-06 
> 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] AMQ221067: 
> Waiting 30 seconds for quorum vote results. 2018-05-06 11:20:42,914 INFO 
> [org.apache.activemq.artemis.core.server] AMQ221060: Sending quorum vote 
> request to amq2a/10.92.151.33:61716: ServerConnectVote 
> [nodeId=d41a0e0f-50da-11e8-9b2d-005056b01f85, vote=false]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1866) Make wait time for reply configurable once vote goes out to acquire a quorum.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1866:
-

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2089
  
@RaiSaurabh We have an [hacking 
guide](https://activemq.apache.org/artemis/docs/latest/hacking-guide/code.html) 
that explain:

> When you commit your changes you will need to supply a commit message. We 
follow the 50/72 git commit message format. An ActiveMQ Artemis commit message 
should be formatted in the following manner:
> 
> Add the ARTEMIS JIRA (if one exists) followed by a brief description of 
the change in the first line. This line should be limited to 50 characters.
> Insert a single blank line after the first line.
> Provide a detailed description of the change in the following lines, 
breaking paragraphs where needed. These lines should be wrapped at 72 
characters.
> An example correctly formatted commit message:
> 
>   ARTEMIS-123 Add new commit msg format to README
> 
>   Adds a description of the new commit message format as well as examples
>   of well formatted commit messages to the README.md.  This is required 
>   to enable developers to quickly identify what the commit is intended to 
>   do and why the commit was added.


> Make wait time for reply configurable once vote goes out to acquire a quorum.
> -
>
> Key: ARTEMIS-1866
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1866
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Saurabh Rai
>Priority: Major
>
> Quorum voting is used by both the live and the backup to decide what to do if 
> a replication connection is disconnected. Basically, the server will request 
> each live server in the cluster to vote as to whether it thinks the server it 
> is replicating to or from is still alive. You can also configure the time for 
> which the quorum manager will wait for the quorum vote response. Currently, 
> the value is hardcoded as 30 sec. We should change this 30-second wait to be 
> configurable.
> Please find the logs for reference:
> 2018-05-06 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] 
> AMQ221066: Initiating quorum vote: LiveFailoverQuorumVote 2018-05-06 
> 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] AMQ221067: 
> Waiting 30 seconds for quorum vote results. 2018-05-06 11:20:42,914 INFO 
> [org.apache.activemq.artemis.core.server] AMQ221060: Sending quorum vote 
> request to amq2a/10.92.151.33:61716: ServerConnectVote 
> [nodeId=d41a0e0f-50da-11e8-9b2d-005056b01f85, vote=false]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1866) Make wait time for reply configurable once vote goes out to acquire a quorum.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1866:
-

Github user RaiSaurabh commented on the issue:

https://github.com/apache/activemq-artemis/pull/2089
  
@franz1981 I have updated it. Refer the image

![image](https://user-images.githubusercontent.com/22483381/40176581-795ca33a-59f9-11e8-9209-6c66da5c286c.png)



> Make wait time for reply configurable once vote goes out to acquire a quorum.
> -
>
> Key: ARTEMIS-1866
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1866
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Saurabh Rai
>Priority: Major
>
> Quorum voting is used by both the live and the backup to decide what to do if 
> a replication connection is disconnected. Basically, the server will request 
> each live server in the cluster to vote as to whether it thinks the server it 
> is replicating to or from is still alive. You can also configure the time for 
> which the quorum manager will wait for the quorum vote response. Currently, 
> the value is hardcoded as 30 sec. We should change this 30-second wait to be 
> configurable.
> Please find the logs for reference:
> 2018-05-06 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] 
> AMQ221066: Initiating quorum vote: LiveFailoverQuorumVote 2018-05-06 
> 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] AMQ221067: 
> Waiting 30 seconds for quorum vote results. 2018-05-06 11:20:42,914 INFO 
> [org.apache.activemq.artemis.core.server] AMQ221060: Sending quorum vote 
> request to amq2a/10.92.151.33:61716: ServerConnectVote 
> [nodeId=d41a0e0f-50da-11e8-9b2d-005056b01f85, vote=false]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1866) Make wait time for reply configurable once vote goes out to acquire a quorum.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1866:
-

Github user RaiSaurabh commented on the issue:

https://github.com/apache/activemq-artemis/pull/2089
  
@franz1981 I have updated the code as per your suggestion and also updated 
the commit message same as the PR. Could you please review.


> Make wait time for reply configurable once vote goes out to acquire a quorum.
> -
>
> Key: ARTEMIS-1866
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1866
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Saurabh Rai
>Priority: Major
>
> Quorum voting is used by both the live and the backup to decide what to do if 
> a replication connection is disconnected. Basically, the server will request 
> each live server in the cluster to vote as to whether it thinks the server it 
> is replicating to or from is still alive. You can also configure the time for 
> which the quorum manager will wait for the quorum vote response. Currently, 
> the value is hardcoded as 30 sec. We should change this 30-second wait to be 
> configurable.
> Please find the logs for reference:
> 2018-05-06 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] 
> AMQ221066: Initiating quorum vote: LiveFailoverQuorumVote 2018-05-06 
> 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] AMQ221067: 
> Waiting 30 seconds for quorum vote results. 2018-05-06 11:20:42,914 INFO 
> [org.apache.activemq.artemis.core.server] AMQ221060: Sending quorum vote 
> request to amq2a/10.92.151.33:61716: ServerConnectVote 
> [nodeId=d41a0e0f-50da-11e8-9b2d-005056b01f85, vote=false]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1865) Shared Store Cluster Doesn't Work on CIFS

[Francesco Nigro (JIRA)]

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

Francesco Nigro commented on ARTEMIS-1865:
--

Given that currently it just use one file with [5 different 
regions|https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/FileLockNodeManager.java#L36]
 used for:
 * shared state ([LIVE, FAILINGBACK, STARTED, 
NOT_STARTED|[https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/FileLockNodeManager.java#L44])]
 - 1 byte -
 * live lock - 1 byte -
 * backup lock - 1 byte -
 * shared nodeId (UUID) - 16 byte -

I think that it could be splitted into 3 files:
 * one with the shared state and nodeId (server.state)
 * one with the live lock (live.lock)
 * one with the backup lock (backup.lock)

That should avoid strange locking issues to happen due to not obvious CIFS 
configuration.

The only problems I see are related to the retro-compatibility and 
cross-compatibility (ie a new version can't work with an old one etc etc).

I don't have any box to reproduce the CIFS behaviour ATM, but it would be good 
to create 2 simple programs that try to acquire locks on different regions on 
the same remote file and validate that's the real problem.

AFAIK NFS doesn't seem to have similar issues.

 

 

> Shared Store Cluster Doesn't Work on CIFS
> -
>
> Key: ARTEMIS-1865
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1865
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.5.0
> Environment: RHEL 6.2
>Reporter: Ilkka Virolainen
>Priority: Minor
> Attachments: broker_a.xml, broker_b.xml
>
>
> When Artemis is configured as a shared store master/slave -pair with the 
> journal saved on a CIFS share only the first instance is able to start. The 
> instance started later will fail the acquire a lock to journal/server.lock 
> file and will start in an invalid state. Similar shared store master/slave 
> -configuration works correctly with 5.14.5.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)