.NET Clients for HornetQ

[shayf]

Hello.

I am using a .NET clients ( Apache NMS, with STOMP Connection) to connect to a HornetQ server.

I am able to connect, and create core topics.

However, the problem is that it seems the producer is not working.

I am trying to publish (Actually I am sending with a producer) a message, so all subscribers will be able to recieve it.

But it seems that thae producer does not send the message at all (and I get no error).

This is very strange, since I am using the same code for creating topics, and its working.

I can upload the proper line of codes if it will help ( C++/CLI usnig Apache NMS)

Best Regards,

Shay.

[lato1]

Hi,

I have been trying to connect to HornetQ from .NET too, using Apache.NMS and Apache.NMS.Stomp libraries v1.4.0. Initially I had the problem that the Stomp connector was always adding "/queue/" and "/topic/" in front of the names I supplied. Probably that works with ActiveMQ but it doesn't work with HornetQ. I removed that from the source (Apache.NMS.Stomp.Commands.Destination class) and compiled the libraries and now I am able to send and receive messages from a .NET application with the Stomp protocol.

There is another problem though: if the .net client does not close the connections properly they remain in HornetQ and never get removed. So the ConsumerCount attribute of a queue will always show, say 2-3. Then when I run the .NET client again it can publish messages but then only consume a part of them so eventually the queue will end up with a lot of messages that cannot be consumed until I restart the server.

There might be a problem with the Apache.NMS client and I plan to investigate that, however I believe HornetQ should be removing dead connections. It does it very well when I use the Java netty clients. Could it be a problem of how Stomp connections are handled?

It would be great if someone could provide more insight.

[lato1]

Another observation: even if I add the element <connection-ttl-override> in the server configuration the Somp connections still remain indefinitely.

[clebert.suconic]

Can you please take a look how svn trunk would behave in regard to this?

[lato1]

Clebert,

Will do that and will report the results.

[lato1]

Clebert,

I did some tests with the hornet version from trunk and can confirm that remaining Stomp connections that have not been closed properly by the client DO get removed on the server. There is another problem though.

When a client connection dies and then I create a new one and try to receive the remaining messages, hornetq throws the exception below for each remaining message that I try to receive. Nothing is received on the client. If I wait until old connections are removed on the server I can receive all the messages.

Basically until there are client connections that have not been closed property, new Stopm connections cannot receive messages and the server throws the error below. When I close the client and wait for the server to remove the hanging connections then I can receive the messages.

Is this a bug or this is how it should work?

[Old I/O server worker (parentId: 10311571, channelId: 22915961, null => localhost/127.0.0.1:61613)] 13:48:09,657 SEVERE [org.hornetq.core.protocol.stomp.StompProtocolManager]  Failed to decode
org.hornetq.core.protocol.stomp.StompException: Invalid STOMP frame: 10,10,10,10,10,10,10,10,10,
    at org.hornetq.core.protocol.stomp.StompDecoder.throwInvalid(StompDecoder.java:494)
    at org.hornetq.core.protocol.stomp.StompDecoder.decode(StompDecoder.java:297)
    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:464)
    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)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
    at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:90)
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
    at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46)
    at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:181)
    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)