HornetQ support for STOMP (version, headers etc)

[eustache]

Hi there,

I've read the docs so far but found very few information regarding STOMP support in HornetQ.

Namely:

1/ Does-it support STOMP 1.1 (inc. heartbeat frames to revive connection TTL) ?

- from my experience it does not [1]

- in order to write persistent subscribers, this implies to send arbitrary frames to a dummy queue and/or to detect connection errors and try to reconnect automatically

2/ Which STOMP headers does it handles (e.g. durable-subscriber-name) ?

- again, I couldn't make 'durable-subscriber-name' work [2]

- how can I know by which means I can make the sequence described in [2] work with STOMP ?

- what about 'stomp_subscriber-id' on connection ?

Thanks for any insights,

Eustache

[1] see stacktrace:

"""

[Old I/O server worker (parentId: 1806276996, [id: 0x6ba99984, /0.0.0.0:61613])] 10:35:12,387 SEVERE [org.hornetq.core.protocol.stomp.StompProtocolManager]  Failed to decode

org.hornetq.core.protocol.stomp.StompException: Invalid STOMP frame: S,T,O,M,P,10,a,c,c,e,p,t,-,v,e,r,s,i,o,n,:,1,.,1,10,h,e,a,r,t,-,b,e,a,t,:,1,0,0,,,1,0,0,10,10,0,

    at org.hornetq.core.protocol.stomp.StompDecoder.throwInvalid(StompDecoder.java:566)

    at org.hornetq.core.protocol.stomp.StompDecoder.decode(StompDecoder.java:375)

    at org.hornetq.core.protocol.stomp.StompProtocolManager.handleBuffer(StompProtocolManager.java:161)

    at org.hornetq.core.protocol.stomp.StompConnection.bufferReceived(StompConnection.java:269)

    at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:459)

    at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:73)

    at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:100)

    at org.jboss.netty.channel.StaticChannelPipeline.sendUpstream(StaticChannelPipeline.java:362)

    at org.jboss.netty.channel.StaticChannelPipeline.sendUpstream(StaticChannelPipeline.java:357)

...

"""

[2] the following sequence fails at step:

"""

0. client-1 connects

1. client-1 subscribe to the topic with header 'durable-subscriber-name' set

2. client-2 sends message-1 to the topic

3. client-1 receives message-1

4. client-1 disconnects

5. client-2 sends message-2 to the topic

6. client-1 connects

7. client-1 subscribe to the topic with header 'durable-subscriber-name' set

8. client-1 receives message-2 # not working

"""

[gaohoward]

Stomp 1.1 support is already implemented on trunk, although it hasn't been made into any releases yet.

[jmesnil]

eustache wrote:

[2] the following sequence fails at step:

"""

0. client-1 connects

1. client-1 subscribe to the topic with header 'durable-subscriber-name' set

2. client-2 sends message-1 to the topic

3. client-1 receives message-1

4. client-1 disconnects

5. client-2 sends message-2 to the topic

6. client-1 connects

7. client-1 subscribe to the topic with header 'durable-subscriber-name' set

8. client-1 receives message-2 # not working

"""

Stomp does not specify topic subscription and it is not well documented. In case of doubt, we tried to stay as close as possible to JMS specification.

This test corresponds to your use case: https://github.com/hornetq/hornetq/blob/master/tests/integration-tests/src/test/java/org/hornetq/tests/integration/stomp/StompTest.java#L1051

When client-1 connects, it MUST pass a client-id header to its CONNECT frame to identify itself.

It's the combination of this connection's client-id *and* the durable-subscriber-name that uniquely identify the subscription.

hope that helps,

jeff

[eustache]

Hi Jeff,

thanks for your reply.

I'm trying to reproduce exactly what you describe (client-id + durable-subscriber-name), but it fails

More precisely, here is what I do:

1. send CONNECT frame with 'client-id' header set to some value

2. send SUBSCRIBE frame with 'durable-subscriber-name' set to some other value

this yields the following error:

"""

----Received Frame----

>>command: ERROR

>>headers: {'message': 'Cannot create a subscriber on the durable subscription if the client-id of the connection is not set', 'content-length': '1749'}

>>body: java.lang.IllegalStateException: Cannot create a subscriber on the durable subscription if the client-id of the connection is not set

    at org.hornetq.core.protocol.stomp.StompSession.addSubscription(StompSession.java:195)

    at org.hornetq.core.protocol.stomp.StompProtocolManager.onSubscribe(StompProtocolManager.java:351)

    at org.hornetq.core.protocol.stomp.StompProtocolManager.handleBuffer(StompProtocolManager.java:195)

    at org.hornetq.core.protocol.stomp.StompConnection.bufferReceived(StompConnection.java:269)

...

-----

"""

As if the server didn't receive/look for the client-id header in the CONNECT frame

I tried to repeat the same 'client-id' header on the SUBSCRIBE frame with no luck...

Any ideas welcome...

E/

[eustache]

@Jeff,

After reading the unit-test you mentionned, I notice a small difference with what I do : in the utest the client acknowledges the message while in my code I let the acknowledge policy to 'auto'.

Do you think that it could matter ?

Thanks,

Eustache

[jmesnil]

eustache wrote:

@Jeff,

After reading the unit-test you mentionned, I notice a small difference with what I do : in the utest the client acknowledges the message while in my code I let the acknowledge policy to 'auto'.

Nope, the test also use auto ack. I check the "receipt" of a STOMP frame but that's different. It's just to be sure that the server correctly receives the STOMP frame (the UNSUBSCRIBE frame in that case).

That said, I checked on HornetQ 2.2.18. What's your HornetQ version again? iirc, clebert told me that they fixed some time ago a bug related to durable subscriber.

--jeff

[eustache]

"2.2.5.Final" here ...

Thanks,

E/