[jira] [Created] (ACTIVEMQ6-90) ClassNotFoundException when a backup server fails over after having failed back

2015-03-19 Thread Jeff Mesnil (JIRA)
Jeff Mesnil created ACTIVEMQ6-90:


 Summary: ClassNotFoundException when a backup server fails over 
after having failed back
 Key: ACTIVEMQ6-90
 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-90
 Project: Apache ActiveMQ 6
  Issue Type: Bug
Affects Versions: 6.0.0
Reporter: Jeff Mesnil


I'm integrating ActiveMQ 6 in WildFly and testing out its failover features.

My use case is:
2 servers:
  * server #1 with replicated master HA (check-for-live-serve=true)
  * server #2 with replicated slave HA (restart-backup=true)

* both servers are started
  = #1 is master
  = #2 announces it is a backup
* server #1 is stopped
  = #2 fails over and becomes live
* server #1 is restarted
  = #2 detects the live is up again and fails back
* server #1 is stopped again
  = I was expecting server #2 to becomes live again but instead, I got the 
following exception:

{noformat}
16:27:07,528 WARN  [org.apache.activemq.core.server] (AMQ119000: Activation for 
server ActiveMQServerImpl::serverUUID=null) AMQ222080: Error instantiating 
remoting acceptor 
org.apache.activemq.core.remoting.impl.netty.NettyAcceptorFactory: 
java.lang.ClassNotFoundException: 
org.apache.activemq.core.remoting.impl.netty.NettyAcceptorFactory from [Module 
org.wildfly.extension.io:main from local module loader @6e32bb55 (finder: 
local module finder @44a901f8 (roots: 
/Users/jmesnil/Developer/wildfly/dist/target/slave/modules,/Users/jmesnil/Developer/wildfly/dist/target/slave/modules/system/layers/base))]
at 
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:216)
at 
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
at 
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
at 
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
at 
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
at 
org.apache.activemq.core.remoting.server.impl.RemotingServiceImpl.start(RemotingServiceImpl.java:235)
at 
org.apache.activemq.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:1778)
at 
org.apache.activemq.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:280)
at java.lang.Thread.run(Thread.java:744)
{noformat}

The CFNE occurs because WildFly uses a modular class loader.
The SharedNothingBackupActivation runnable is run by creating a new 
backupActivationThread (ActiveMQServerImpl.java:425).
In a modular environment this thread's module has not knowledge of the 
NettyAcceptorFactory class.

To prevent this CFNE, this thread should use the TCCL before loading the 
acceptor factory from its class names.

Additionally, I'm not sure it's a good idea to create new Thread like this. 
ActiveMQ has a threadPool executorService that could be used to run such code. 
Since ActiveMQ supports injection of this threadPool (through the 
serviceRegistry), WildFly could ensure that any code run by this thread pool 
will be using the correct module class loader.
Is there a good reason to use a separate thread for the backup activation?

  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (ACTIVEMQ6-91) ServiceRegistry class is not part of ActiveMQ public API

2015-03-19 Thread Jeff Mesnil (JIRA)
Jeff Mesnil created ACTIVEMQ6-91:


 Summary: ServiceRegistry class is not part of ActiveMQ public API
 Key: ACTIVEMQ6-91
 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-91
 Project: Apache ActiveMQ 6
  Issue Type: Bug
Reporter: Jeff Mesnil


To integrate ActiveMQ 6 in WildFly, I need to inject some instances into 
ActiveMQ 6 using its org.apache.activemq.core.server.impl.ServiceRegistry.

However this class is not part of the impl package and not the public API. This 
class should have an interface that can be obtained from the ActiveMQServer 
interface




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (ACTIVEMQ6-92) Inject divert and bridge transformer classes

2015-03-19 Thread Jeff Mesnil (JIRA)
Jeff Mesnil created ACTIVEMQ6-92:


 Summary: Inject divert and bridge transformer classes
 Key: ACTIVEMQ6-92
 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-92
 Project: Apache ActiveMQ 6
  Issue Type: Improvement
Affects Versions: 6.0.0
Reporter: Jeff Mesnil


Divert and bridges can have a transformer classes.

They are specified in the divert and bridges configuration using class names 
and loads by ActiveMQ when its server is started.
However in a modular environment (such as WildFly), ActiveMQ may not be aware 
of the modules containing the loaded classes (that can come from the user 
space).

It is not suitable to have the ActiveMQ module depends on these user modules 
(as it breaks any modularity). Instead ActiveMQ should be able to use 
transformer *instances* (loaded by WildFly) from the divert and bridge classes.

There is already such a mechanism for loaded classes such as server interceptor 
and connector services through the ServiceRegistry.
This class should be extended to also work with divert and bridge transformers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ACTIVEMQ6-52) Graceful Shutdown

2015-01-29 Thread Jeff Mesnil (JIRA)

[ 
https://issues.apache.org/jira/browse/ACTIVEMQ6-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14296636#comment-14296636
 ] 

Jeff Mesnil commented on ACTIVEMQ6-52:
--

The current implementation of the graceful shutdown expects the shutdown 
timeout to be specified at configuration time.
But depending on the use cases, we would need to have this timeout be specified 
when the administrator wants to stop ActiveMQ 6 (e.g. specify __now__ in case 
of emergency or 8-hour timeout for a planned upgrade).

Would it be possible to add such timeout to the ActiveMQ6 server stop() method?

We would also like to suspend and _resume_ the server. This would modify the 
ActiveMQServer interface) to be able to suspend or pause the acceptors with a 
graceful timeout *and* also resume them without having to restart the whole 
server. 

 Graceful Shutdown
 -

 Key: ACTIVEMQ6-52
 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-52
 Project: Apache ActiveMQ 6
  Issue Type: Bug
Reporter: clebert suconic
Assignee: Justin Bertram
 Fix For: 6.0.0


 We should provide a way for the system to gracefully shutdown connections 
 allowing them to finish their work before the server is going out.
 This could be done by issuing a close from Server to client on all the 
 connections.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ACTIVEMQ6-52) Graceful Shutdown

2015-01-29 Thread Jeff Mesnil (JIRA)

[ 
https://issues.apache.org/jira/browse/ACTIVEMQ6-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14296831#comment-14296831
 ] 

Jeff Mesnil commented on ACTIVEMQ6-52:
--

In the case of using ActiveMQ in an application server, we would also like to 
distinguish between external acceptors (backed by Netty) and in-memory ones.

When the app server suspends its activity, it prevents new external connections 
but should still allow the current existing ones to perform their works.
It should also not prevent new internal connections to be created.

From an API point of view, that means we would be interested to prevent new 
connections from netty acceptors when the app server suspends its activity. 
But this should have no impact on existing external connection and any 
in-memory connections

 Graceful Shutdown
 -

 Key: ACTIVEMQ6-52
 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-52
 Project: Apache ActiveMQ 6
  Issue Type: Bug
Reporter: clebert suconic
Assignee: Justin Bertram
 Fix For: 6.0.0


 We should provide a way for the system to gracefully shutdown connections 
 allowing them to finish their work before the server is going out.
 This could be done by issuing a close from Server to client on all the 
 connections.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (AMQ-4740) heart-beat is disabled when connecting to web socket

2014-06-11 Thread Jeff Mesnil (JIRA)

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

Jeff Mesnil updated AMQ-4740:
-

Affects Version/s: 5.10.0

 heart-beat is disabled when connecting to web socket
 

 Key: AMQ-4740
 URL: https://issues.apache.org/jira/browse/AMQ-4740
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.8.0, 5.10.0
 Environment: Google Chrome29.0.1547.76 (Official Build 223446) 
Reporter: Jeff Mesnil
 Fix For: 5.9.1, 5.10.0

 Attachments: AMQ-4740.patch


 If I use the stomp.js library to connect to ActiveMQ over its WebSocket url 
 (ws://localhost:61614), the CONNECTED frame returns with disabled heart-beat:
 CONNECTED
 heart-beat:0,0
 session:ID:retsina.local-63633-1380117269290-2:1
 server:ActiveMQ/5.8.0
 version:1.1
 If I connect to its TCP socket (localhost:61613), the CONNECT frame will have 
 heart-beat:
 CONNECTED
 heart-beat:1,1
 session:ID:retsina.local-63384-1380115729700-2:12
 server:ActiveMQ/5.8.0
 version:1.1
 In both case, the stomp.js send the same CONNECT frame with heart-beat:
 CONNECT
 login:user
 passcode:password
 accept-version:1.1,1.0
 heart-beat:1,1
 Is heart-beat disabled on purpose for Web Socket? Please note that the 
 stomp.js does support heart-beat (using window.setInterval in a Web browser)



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Reopened] (AMQ-4740) heart-beat is disabled when connecting to web socket

2014-06-11 Thread Jeff Mesnil (JIRA)

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

Jeff Mesnil reopened AMQ-4740:
--

Regression: Regression

Issue is still happening with ActiveMQ 5.10.0.

 heart-beat is disabled when connecting to web socket
 

 Key: AMQ-4740
 URL: https://issues.apache.org/jira/browse/AMQ-4740
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.8.0, 5.10.0
 Environment: Google Chrome29.0.1547.76 (Official Build 223446) 
Reporter: Jeff Mesnil
 Fix For: 5.9.1, 5.10.0

 Attachments: AMQ-4740.patch


 If I use the stomp.js library to connect to ActiveMQ over its WebSocket url 
 (ws://localhost:61614), the CONNECTED frame returns with disabled heart-beat:
 CONNECTED
 heart-beat:0,0
 session:ID:retsina.local-63633-1380117269290-2:1
 server:ActiveMQ/5.8.0
 version:1.1
 If I connect to its TCP socket (localhost:61613), the CONNECT frame will have 
 heart-beat:
 CONNECTED
 heart-beat:1,1
 session:ID:retsina.local-63384-1380115729700-2:12
 server:ActiveMQ/5.8.0
 version:1.1
 In both case, the stomp.js send the same CONNECT frame with heart-beat:
 CONNECT
 login:user
 passcode:password
 accept-version:1.1,1.0
 heart-beat:1,1
 Is heart-beat disabled on purpose for Web Socket? Please note that the 
 stomp.js does support heart-beat (using window.setInterval in a Web browser)



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Comment Edited] (AMQ-4740) heart-beat is disabled when connecting to web socket

2014-06-11 Thread Jeff Mesnil (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027792#comment-14027792
 ] 

Jeff Mesnil edited comment on AMQ-4740 at 6/11/14 2:19 PM:
---

Issue is still happening with ActiveMQ 5.10.0.

In the log:

2014-06-11 15:27:59,776 | WARN  | Transport Connection to: 
StompSocket_1430955985 failed: java.io.IOException | 
org.apache.activemq.broker.TransportConnection.Transport | qtp542980314-29

The corresponding STOMP frames were:

CONNECT
accept-version:1.1,1.0
heart-beat:2,6

CONNECTED
server:ActiveMQ/5.10.0
heart-beat:6,2
session:ID:jeff.local-51540-1402496252734-2:1
version:1.1

And the Web Socket client was sending PING frames every 20 seconds.




was (Author: jmesnil):
Issue is still happening with ActiveMQ 5.10.0.

 heart-beat is disabled when connecting to web socket
 

 Key: AMQ-4740
 URL: https://issues.apache.org/jira/browse/AMQ-4740
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.8.0, 5.10.0
 Environment: Google Chrome29.0.1547.76 (Official Build 223446) 
Reporter: Jeff Mesnil
 Fix For: 5.9.1, 5.10.0

 Attachments: AMQ-4740.patch


 If I use the stomp.js library to connect to ActiveMQ over its WebSocket url 
 (ws://localhost:61614), the CONNECTED frame returns with disabled heart-beat:
 CONNECTED
 heart-beat:0,0
 session:ID:retsina.local-63633-1380117269290-2:1
 server:ActiveMQ/5.8.0
 version:1.1
 If I connect to its TCP socket (localhost:61613), the CONNECT frame will have 
 heart-beat:
 CONNECTED
 heart-beat:1,1
 session:ID:retsina.local-63384-1380115729700-2:12
 server:ActiveMQ/5.8.0
 version:1.1
 In both case, the stomp.js send the same CONNECT frame with heart-beat:
 CONNECT
 login:user
 passcode:password
 accept-version:1.1,1.0
 heart-beat:1,1
 Is heart-beat disabled on purpose for Web Socket? Please note that the 
 stomp.js does support heart-beat (using window.setInterval in a Web browser)



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (AMQ-4740) heart-beat is disabled when connecting to web socket

2013-09-25 Thread Jeff Mesnil (JIRA)

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

Jeff Mesnil updated AMQ-4740:
-

Summary: heart-beat is disabled when connecting to web socket  (was: 
heart-beat is disable when connecting to web socket)

 heart-beat is disabled when connecting to web socket
 

 Key: AMQ-4740
 URL: https://issues.apache.org/jira/browse/AMQ-4740
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.8.0
 Environment: Google Chrome29.0.1547.76 (Official Build 223446) 
Reporter: Jeff Mesnil

 If I use the stomp.js library to connect to ActiveMQ over its WebSocket url 
 (ws://localhost:61614), the CONNECTED frame returns with disabled heart-beat:
 CONNECTED
 heart-beat:0,0
 session:ID:retsina.local-63633-1380117269290-2:1
 server:ActiveMQ/5.8.0
 version:1.1
 If I connect to its TCP socket (localhost:61613), the CONNECT frame will have 
 heart-beat:
 CONNECTED
 heart-beat:1,1
 session:ID:retsina.local-63384-1380115729700-2:12
 server:ActiveMQ/5.8.0
 version:1.1
 In both case, the stomp.js send the same CONNECT frame with heart-beat:
 CONNECT
 login:user
 passcode:password
 accept-version:1.1,1.0
 heart-beat:1,1
 Is heart-beat disabled on purpose for Web Socket? Please note that the 
 stomp.js does support heart-beat (using window.setInterval in a Web browser)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (AMQ-4740) heart-beat is disable when connecting to web socket

2013-09-25 Thread Jeff Mesnil (JIRA)
Jeff Mesnil created AMQ-4740:


 Summary: heart-beat is disable when connecting to web socket
 Key: AMQ-4740
 URL: https://issues.apache.org/jira/browse/AMQ-4740
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.8.0
 Environment: Google Chrome 29.0.1547.76 (Official Build 223446) 
Reporter: Jeff Mesnil


If I use the stomp.js library to connect to ActiveMQ over its WebSocket url 
(ws://localhost:61614), the CONNECTED frame returns with disabled heart-beat:

CONNECTED
heart-beat:0,0
session:ID:retsina.local-63633-1380117269290-2:1
server:ActiveMQ/5.8.0
version:1.1

If I connect to its TCP socket (localhost:61613), the CONNECT frame will have 
heart-beat:

CONNECTED
heart-beat:1,1
session:ID:retsina.local-63384-1380115729700-2:12
server:ActiveMQ/5.8.0
version:1.1

In both case, the stomp.js send the same CONNECT frame with heart-beat:

CONNECT
login:user
passcode:password
accept-version:1.1,1.0
heart-beat:1,1

Is heart-beat disabled on purpose for Web Socket? Please note that the stomp.js 
does support heart-beat (using window.setInterval in a Web browser)


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (AMQ-4200) STOMP 1.1 Over WebSocket

2012-12-03 Thread Jeff Mesnil (JIRA)
Jeff Mesnil created AMQ-4200:


 Summary: STOMP 1.1 Over WebSocket
 Key: AMQ-4200
 URL: https://issues.apache.org/jira/browse/AMQ-4200
 Project: ActiveMQ
  Issue Type: New Feature
  Components: stomp
Affects Versions: 5.7.0
Reporter: Jeff Mesnil
 Attachments: stomp_1.1_over_websocket.patch.txt

Update the websocket example to use the latest stomp.js which supports STOMP 
1.1 (including heart-beating). 

The js file was taken from 
https://raw.github.com/jmesnil/stomp-websocket/master/dist/stomp.js.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (AMQ-4200) STOMP 1.1 Over WebSocket

2012-12-03 Thread Jeff Mesnil (JIRA)

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

Jeff Mesnil updated AMQ-4200:
-

Attachment: stomp_1.1_over_websocket.patch.txt

 STOMP 1.1 Over WebSocket
 

 Key: AMQ-4200
 URL: https://issues.apache.org/jira/browse/AMQ-4200
 Project: ActiveMQ
  Issue Type: New Feature
  Components: stomp
Affects Versions: 5.7.0
Reporter: Jeff Mesnil
 Attachments: stomp_1.1_over_websocket.patch.txt


 Update the websocket example to use the latest stomp.js which supports STOMP 
 1.1 (including heart-beating). 
 The js file was taken from 
 https://raw.github.com/jmesnil/stomp-websocket/master/dist/stomp.js.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira