-
1. Re: .NET Clients for HornetQ
lato1 Nov 27, 2010 7:32 AM (in response to shayf)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.
-
2. Re: .NET Clients for HornetQ
lato1 Nov 27, 2010 9:01 AM (in response to lato1)Another observation: even if I add the element <connection-ttl-override> in the server configuration the Somp connections still remain indefinitely.
-
3. Re: .NET Clients for HornetQ
clebert.suconic Nov 29, 2010 10:10 AM (in response to lato1)1 of 1 people found this helpfulCan you please take a look how svn trunk would behave in regard to this?
-
4. Re: .NET Clients for HornetQ
lato1 Nov 30, 2010 3:59 AM (in response to clebert.suconic)Clebert,
Will do that and will report the results.
-
5. Re: .NET Clients for HornetQ
lato1 Dec 5, 2010 9:06 AM (in response to 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)