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