You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Milton Taylor (JIRA)" <ji...@apache.org> on 2009/05/01 04:22:38 UTC
[jira] Created: (AMQ-2239) Stomp wire format doesn't work with tcp
or nio transport
Stomp wire format doesn't work with tcp or nio transport
--------------------------------------------------------
Key: AMQ-2239
URL: https://issues.apache.org/activemq/browse/AMQ-2239
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 5.2.0
Reporter: Milton Taylor
It appears to us that there is some sort of architectural problem with how stomp has been implemented in ActiveMQ. As we understand it, stomp is an application-level wire protocol. However the implementation seems to combine both wire protocol and it's own transport implementation based directly on the tcp socket factory. Not sure what the reason was for this...but it seems like it compromises the layering of wire protocols over transports.
Why we started looking at this, was we wanted to use NIO with Stomp to get the best scalability. In particular, we don't want a server thread being consumed for every long-lived stomp connection. However, although one sees references in mailing lists to the fact that *stomp://localhost:61613* is equivalent to *tcp://localhost:61613?wireFormat=stomp*, in fact the latter does not work and produces this exception:
{{Exception in thread "BrokerService"
java.lang.ClassCastException: org.apache.activemq.command.BrokerInfo cannot be cast to org.apache.activemq.transport.stomp.StompFrame
at org.apache.activemq.transport.stomp.StompWireFormat.marshal(StompWireFormat.java:64)
at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:166)
at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:233)
at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1207)
at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:793)
at org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:830)
at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
}}
Because of this, it is not possible to specify for example,
{{<transportConnectors>
<transportConnector name="stomp" uri="nio://localhost:61613?wireFormat=stomp"/>
</transportConnectors>
}}
We did try altering the implementation of StompTransportFactory to extend NIOTransportFactory instead of TcpTransportFactory. It compiled OK, but it didn't seem to actually work in our tests...the client gets EOF reading the socket for some reason.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2239) Stomp wire format doesn't work with tcp
or nio transport
Posted by "Milton Taylor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Milton Taylor updated AMQ-2239:
-------------------------------
Description:
It appears to us that there is some sort of architectural problem with how stomp has been implemented in ActiveMQ. As we understand it, stomp is an application-level wire protocol. However the implementation seems to combine both wire protocol and it's own transport implementation based directly on the tcp socket factory. Not sure what the reason was for this...but it seems like it compromises the layering of wire protocols over transports.
Why we started looking at this, was we wanted to use NIO with Stomp to get the best scalability. In particular, we don't want a server thread being consumed for every long-lived stomp connection. However, although one sees references in mailing lists to the fact that *stomp://localhost:61613* is equivalent to *tcp://localhost:61613?wireFormat=stomp*, in fact the latter does not work and produces this exception:
{noformat}
Exception in thread "BrokerService"
java.lang.ClassCastException: org.apache.activemq.command.BrokerInfo cannot be cast to org.apache.activemq.transport.stomp.StompFrame
at org.apache.activemq.transport.stomp.StompWireFormat.marshal(StompWireFormat.java:64)
at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:166)
at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:233)
at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1207)
at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:793)
at org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:830)
at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{noformat}
Because of this, it is not possible to specify for example,
{noformat}
<transportConnectors>
<transportConnector name="stomp" uri="nio://localhost:61613?wireFormat=stomp"/>
</transportConnectors>
{noformat}
We did try altering the implementation of StompTransportFactory to extend NIOTransportFactory instead of TcpTransportFactory. It compiled OK, but it didn't seem to actually work in our tests...the client gets EOF reading the socket for some reason.
was:
It appears to us that there is some sort of architectural problem with how stomp has been implemented in ActiveMQ. As we understand it, stomp is an application-level wire protocol. However the implementation seems to combine both wire protocol and it's own transport implementation based directly on the tcp socket factory. Not sure what the reason was for this...but it seems like it compromises the layering of wire protocols over transports.
Why we started looking at this, was we wanted to use NIO with Stomp to get the best scalability. In particular, we don't want a server thread being consumed for every long-lived stomp connection. However, although one sees references in mailing lists to the fact that *stomp://localhost:61613* is equivalent to *tcp://localhost:61613?wireFormat=stomp*, in fact the latter does not work and produces this exception:
{{Exception in thread "BrokerService"
java.lang.ClassCastException: org.apache.activemq.command.BrokerInfo cannot be cast to org.apache.activemq.transport.stomp.StompFrame
at org.apache.activemq.transport.stomp.StompWireFormat.marshal(StompWireFormat.java:64)
at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:166)
at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:233)
at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1207)
at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:793)
at org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:830)
at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
}}
Because of this, it is not possible to specify for example,
{{<transportConnectors>
<transportConnector name="stomp" uri="nio://localhost:61613?wireFormat=stomp"/>
</transportConnectors>
}}
We did try altering the implementation of StompTransportFactory to extend NIOTransportFactory instead of TcpTransportFactory. It compiled OK, but it didn't seem to actually work in our tests...the client gets EOF reading the socket for some reason.
> Stomp wire format doesn't work with tcp or nio transport
> --------------------------------------------------------
>
> Key: AMQ-2239
> URL: https://issues.apache.org/activemq/browse/AMQ-2239
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.2.0
> Reporter: Milton Taylor
>
> It appears to us that there is some sort of architectural problem with how stomp has been implemented in ActiveMQ. As we understand it, stomp is an application-level wire protocol. However the implementation seems to combine both wire protocol and it's own transport implementation based directly on the tcp socket factory. Not sure what the reason was for this...but it seems like it compromises the layering of wire protocols over transports.
> Why we started looking at this, was we wanted to use NIO with Stomp to get the best scalability. In particular, we don't want a server thread being consumed for every long-lived stomp connection. However, although one sees references in mailing lists to the fact that *stomp://localhost:61613* is equivalent to *tcp://localhost:61613?wireFormat=stomp*, in fact the latter does not work and produces this exception:
> {noformat}
> Exception in thread "BrokerService"
> java.lang.ClassCastException: org.apache.activemq.command.BrokerInfo cannot be cast to org.apache.activemq.transport.stomp.StompFrame
> at org.apache.activemq.transport.stomp.StompWireFormat.marshal(StompWireFormat.java:64)
> at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:166)
> at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:233)
> at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
> at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1207)
> at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:793)
> at org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:830)
> at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
> at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> Because of this, it is not possible to specify for example,
> {noformat}
> <transportConnectors>
> <transportConnector name="stomp" uri="nio://localhost:61613?wireFormat=stomp"/>
> </transportConnectors>
> {noformat}
> We did try altering the implementation of StompTransportFactory to extend NIOTransportFactory instead of TcpTransportFactory. It compiled OK, but it didn't seem to actually work in our tests...the client gets EOF reading the socket for some reason.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-2239) Stomp wire format doesn't work with
tcp or nio transport
Posted by "Milton Taylor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51472#action_51472 ]
Milton Taylor commented on AMQ-2239:
------------------------------------
Have analysed this further. We changed the implementation of the stomp factory to extend from NIO rather than from tcp. However unit test code crashed trying to allocate huge amounts of memory from the heap! Further investigation shows that the NIO implementation is openwire-predicated. i.e., it has code in it that sets up buffer lengths etc based on openwire packet framing headers etc. Arggh! The TCP stuff does not make such assumptions; it works a different way anyway in terms of buffer management.
So we hacked it a bit more to get beyond this design issue to see how far we could get. A lot of unit tests passed. (Did not try them all). A real-world test rig with a load test client was then tried.
Two unsavoury discoveries:
* The performance was totally lousy - much much worse than the original stomp implementation ever was. There is probably simple explanation for this, but we ran of time to investigate further.
* It still uses one thread per connection on the server, despite the fact that the NIO code does have code to create worker threads that look after a whole set of channels.
Also failed to shut down properly after that...I think there may be open issues concerning NIO on this front?
Would be interested to hear if there are others interested in an NIO implementation of stomp...we may look at reworking this code. (It also doesn't take advantage of NIO features as well as it could anyway).
> Stomp wire format doesn't work with tcp or nio transport
> --------------------------------------------------------
>
> Key: AMQ-2239
> URL: https://issues.apache.org/activemq/browse/AMQ-2239
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.2.0
> Reporter: Milton Taylor
>
> It appears to us that there is some sort of architectural problem with how stomp has been implemented in ActiveMQ. As we understand it, stomp is an application-level wire protocol. However the implementation seems to combine both wire protocol and it's own transport implementation based directly on the tcp socket factory. Not sure what the reason was for this...but it seems like it compromises the layering of wire protocols over transports.
> Why we started looking at this, was we wanted to use NIO with Stomp to get the best scalability. In particular, we don't want a server thread being consumed for every long-lived stomp connection. However, although one sees references in mailing lists to the fact that *stomp://localhost:61613* is equivalent to *tcp://localhost:61613?wireFormat=stomp*, in fact the latter does not work and produces this exception:
> {noformat}
> Exception in thread "BrokerService"
> java.lang.ClassCastException: org.apache.activemq.command.BrokerInfo cannot be cast to org.apache.activemq.transport.stomp.StompFrame
> at org.apache.activemq.transport.stomp.StompWireFormat.marshal(StompWireFormat.java:64)
> at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:166)
> at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:233)
> at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
> at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1207)
> at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:793)
> at org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:830)
> at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
> at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> Because of this, it is not possible to specify for example,
> {noformat}
> <transportConnectors>
> <transportConnector name="stomp" uri="nio://localhost:61613?wireFormat=stomp"/>
> </transportConnectors>
> {noformat}
> We did try altering the implementation of StompTransportFactory to extend NIOTransportFactory instead of TcpTransportFactory. It compiled OK, but it didn't seem to actually work in our tests...the client gets EOF reading the socket for some reason.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-2239) Stomp wire format doesn't work with
tcp or nio transport
Posted by "Dejan Bosanac (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54147#action_54147 ]
Dejan Bosanac commented on AMQ-2239:
------------------------------------
I spoke (and committed) too soon. As of svn revision 813722 we have a scalable stomp+nio transport
> Stomp wire format doesn't work with tcp or nio transport
> --------------------------------------------------------
>
> Key: AMQ-2239
> URL: https://issues.apache.org/activemq/browse/AMQ-2239
> Project: ActiveMQ
> Issue Type: New Feature
> Components: Transport
> Affects Versions: 5.2.0
> Reporter: Milton Taylor
> Assignee: Dejan Bosanac
> Fix For: 5.3.0
>
>
> It appears to us that there is some sort of architectural problem with how stomp has been implemented in ActiveMQ. As we understand it, stomp is an application-level wire protocol. However the implementation seems to combine both wire protocol and it's own transport implementation based directly on the tcp socket factory. Not sure what the reason was for this...but it seems like it compromises the layering of wire protocols over transports.
> Why we started looking at this, was we wanted to use NIO with Stomp to get the best scalability. In particular, we don't want a server thread being consumed for every long-lived stomp connection. However, although one sees references in mailing lists to the fact that *stomp://localhost:61613* is equivalent to *tcp://localhost:61613?wireFormat=stomp*, in fact the latter does not work and produces this exception:
> {noformat}
> Exception in thread "BrokerService"
> java.lang.ClassCastException: org.apache.activemq.command.BrokerInfo cannot be cast to org.apache.activemq.transport.stomp.StompFrame
> at org.apache.activemq.transport.stomp.StompWireFormat.marshal(StompWireFormat.java:64)
> at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:166)
> at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:233)
> at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
> at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1207)
> at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:793)
> at org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:830)
> at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
> at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> Because of this, it is not possible to specify for example,
> {noformat}
> <transportConnectors>
> <transportConnector name="stomp" uri="nio://localhost:61613?wireFormat=stomp"/>
> </transportConnectors>
> {noformat}
> We did try altering the implementation of StompTransportFactory to extend NIOTransportFactory instead of TcpTransportFactory. It compiled OK, but it didn't seem to actually work in our tests...the client gets EOF reading the socket for some reason.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-2239) Stomp wire format doesn't work with tcp
or nio transport
Posted by "Dejan Bosanac (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dejan Bosanac resolved AMQ-2239.
--------------------------------
Resolution: Fixed
Fix Version/s: 5.3.0
Just committed initial implementation of stomp over nio transport connector. It's based on Mindaugas work described in this thread
http://www.nabble.com/Improved-NIO-support%2C-Stomp-enabled-with-NIO-td9986180.html#a9986180
unfortunately this approach does not help much with scalability, but should have better performances. I'll create another issue for tracking the work of using selectors and minimizing the number of threads.
> Stomp wire format doesn't work with tcp or nio transport
> --------------------------------------------------------
>
> Key: AMQ-2239
> URL: https://issues.apache.org/activemq/browse/AMQ-2239
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.2.0
> Reporter: Milton Taylor
> Assignee: Dejan Bosanac
> Fix For: 5.3.0
>
>
> It appears to us that there is some sort of architectural problem with how stomp has been implemented in ActiveMQ. As we understand it, stomp is an application-level wire protocol. However the implementation seems to combine both wire protocol and it's own transport implementation based directly on the tcp socket factory. Not sure what the reason was for this...but it seems like it compromises the layering of wire protocols over transports.
> Why we started looking at this, was we wanted to use NIO with Stomp to get the best scalability. In particular, we don't want a server thread being consumed for every long-lived stomp connection. However, although one sees references in mailing lists to the fact that *stomp://localhost:61613* is equivalent to *tcp://localhost:61613?wireFormat=stomp*, in fact the latter does not work and produces this exception:
> {noformat}
> Exception in thread "BrokerService"
> java.lang.ClassCastException: org.apache.activemq.command.BrokerInfo cannot be cast to org.apache.activemq.transport.stomp.StompFrame
> at org.apache.activemq.transport.stomp.StompWireFormat.marshal(StompWireFormat.java:64)
> at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:166)
> at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:233)
> at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
> at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1207)
> at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:793)
> at org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:830)
> at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
> at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> Because of this, it is not possible to specify for example,
> {noformat}
> <transportConnectors>
> <transportConnector name="stomp" uri="nio://localhost:61613?wireFormat=stomp"/>
> </transportConnectors>
> {noformat}
> We did try altering the implementation of StompTransportFactory to extend NIOTransportFactory instead of TcpTransportFactory. It compiled OK, but it didn't seem to actually work in our tests...the client gets EOF reading the socket for some reason.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-2239) Stomp wire format doesn't work with
tcp or nio transport
Posted by "Dejan Bosanac (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54141#action_54141 ]
Dejan Bosanac commented on AMQ-2239:
------------------------------------
A placeholder for future work: https://issues.apache.org/activemq/browse/AMQ-2386
> Stomp wire format doesn't work with tcp or nio transport
> --------------------------------------------------------
>
> Key: AMQ-2239
> URL: https://issues.apache.org/activemq/browse/AMQ-2239
> Project: ActiveMQ
> Issue Type: New Feature
> Components: Transport
> Affects Versions: 5.2.0
> Reporter: Milton Taylor
> Assignee: Dejan Bosanac
> Fix For: 5.3.0
>
>
> It appears to us that there is some sort of architectural problem with how stomp has been implemented in ActiveMQ. As we understand it, stomp is an application-level wire protocol. However the implementation seems to combine both wire protocol and it's own transport implementation based directly on the tcp socket factory. Not sure what the reason was for this...but it seems like it compromises the layering of wire protocols over transports.
> Why we started looking at this, was we wanted to use NIO with Stomp to get the best scalability. In particular, we don't want a server thread being consumed for every long-lived stomp connection. However, although one sees references in mailing lists to the fact that *stomp://localhost:61613* is equivalent to *tcp://localhost:61613?wireFormat=stomp*, in fact the latter does not work and produces this exception:
> {noformat}
> Exception in thread "BrokerService"
> java.lang.ClassCastException: org.apache.activemq.command.BrokerInfo cannot be cast to org.apache.activemq.transport.stomp.StompFrame
> at org.apache.activemq.transport.stomp.StompWireFormat.marshal(StompWireFormat.java:64)
> at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:166)
> at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:233)
> at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
> at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1207)
> at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:793)
> at org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:830)
> at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
> at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> Because of this, it is not possible to specify for example,
> {noformat}
> <transportConnectors>
> <transportConnector name="stomp" uri="nio://localhost:61613?wireFormat=stomp"/>
> </transportConnectors>
> {noformat}
> We did try altering the implementation of StompTransportFactory to extend NIOTransportFactory instead of TcpTransportFactory. It compiled OK, but it didn't seem to actually work in our tests...the client gets EOF reading the socket for some reason.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AMQ-2239) Stomp wire format doesn't work with tcp
or nio transport
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies reassigned AMQ-2239:
-------------------------------
Assignee: Dejan Bosanac
> Stomp wire format doesn't work with tcp or nio transport
> --------------------------------------------------------
>
> Key: AMQ-2239
> URL: https://issues.apache.org/activemq/browse/AMQ-2239
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.2.0
> Reporter: Milton Taylor
> Assignee: Dejan Bosanac
>
> It appears to us that there is some sort of architectural problem with how stomp has been implemented in ActiveMQ. As we understand it, stomp is an application-level wire protocol. However the implementation seems to combine both wire protocol and it's own transport implementation based directly on the tcp socket factory. Not sure what the reason was for this...but it seems like it compromises the layering of wire protocols over transports.
> Why we started looking at this, was we wanted to use NIO with Stomp to get the best scalability. In particular, we don't want a server thread being consumed for every long-lived stomp connection. However, although one sees references in mailing lists to the fact that *stomp://localhost:61613* is equivalent to *tcp://localhost:61613?wireFormat=stomp*, in fact the latter does not work and produces this exception:
> {noformat}
> Exception in thread "BrokerService"
> java.lang.ClassCastException: org.apache.activemq.command.BrokerInfo cannot be cast to org.apache.activemq.transport.stomp.StompFrame
> at org.apache.activemq.transport.stomp.StompWireFormat.marshal(StompWireFormat.java:64)
> at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:166)
> at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:233)
> at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
> at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1207)
> at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:793)
> at org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:830)
> at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
> at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> Because of this, it is not possible to specify for example,
> {noformat}
> <transportConnectors>
> <transportConnector name="stomp" uri="nio://localhost:61613?wireFormat=stomp"/>
> </transportConnectors>
> {noformat}
> We did try altering the implementation of StompTransportFactory to extend NIOTransportFactory instead of TcpTransportFactory. It compiled OK, but it didn't seem to actually work in our tests...the client gets EOF reading the socket for some reason.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2239) Stomp wire format doesn't work with tcp
or nio transport
Posted by "Dejan Bosanac (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dejan Bosanac updated AMQ-2239:
-------------------------------
Issue Type: New Feature (was: Bug)
> Stomp wire format doesn't work with tcp or nio transport
> --------------------------------------------------------
>
> Key: AMQ-2239
> URL: https://issues.apache.org/activemq/browse/AMQ-2239
> Project: ActiveMQ
> Issue Type: New Feature
> Components: Transport
> Affects Versions: 5.2.0
> Reporter: Milton Taylor
> Assignee: Dejan Bosanac
> Fix For: 5.3.0
>
>
> It appears to us that there is some sort of architectural problem with how stomp has been implemented in ActiveMQ. As we understand it, stomp is an application-level wire protocol. However the implementation seems to combine both wire protocol and it's own transport implementation based directly on the tcp socket factory. Not sure what the reason was for this...but it seems like it compromises the layering of wire protocols over transports.
> Why we started looking at this, was we wanted to use NIO with Stomp to get the best scalability. In particular, we don't want a server thread being consumed for every long-lived stomp connection. However, although one sees references in mailing lists to the fact that *stomp://localhost:61613* is equivalent to *tcp://localhost:61613?wireFormat=stomp*, in fact the latter does not work and produces this exception:
> {noformat}
> Exception in thread "BrokerService"
> java.lang.ClassCastException: org.apache.activemq.command.BrokerInfo cannot be cast to org.apache.activemq.transport.stomp.StompFrame
> at org.apache.activemq.transport.stomp.StompWireFormat.marshal(StompWireFormat.java:64)
> at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:166)
> at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:233)
> at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
> at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1207)
> at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:793)
> at org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:830)
> at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
> at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> Because of this, it is not possible to specify for example,
> {noformat}
> <transportConnectors>
> <transportConnector name="stomp" uri="nio://localhost:61613?wireFormat=stomp"/>
> </transportConnectors>
> {noformat}
> We did try altering the implementation of StompTransportFactory to extend NIOTransportFactory instead of TcpTransportFactory. It compiled OK, but it didn't seem to actually work in our tests...the client gets EOF reading the socket for some reason.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.