[
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.
