9:26 p.m.
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.ji...
]
Abdel Dridi commented on JBMESSAGING-1693:
------------------------------------------
Hello Andy,
I took a build from the trunk today and I still see the problem happening.
In my case I need to ack (CLIENT_ACK) for each consumed message.
I am using a Linux-64bits for testing.
Any comments are highly appreciated.
Thanks.
-------------------------------------------------------------------------------------------------------------
Aug 6, 2009 12:17:02 PM org.jboss.messaging.core.logging.Logger warn
WARNING: Connection failure has been detected: Did not receive ping from server for
org.jboss.messaging.integration.transports.netty.NettyConnection@10f102d3[local=
/192.168.1.35:46762, remote=c1/192.168.1.35:5445] [code=3]
Aug 6, 2009 12:17:02 PM org.jboss.messaging.core.logging.Logger warn
WARNING: Connection failure has been detected: Did not receive ping from server for
org.jboss.messaging.integration.transports.netty.NettyConnection@d24111a[local=
/192.168.1.35:46764, remote=c1/192.168.1.35:5445] [code=3]
Aug 6, 2009 12:17:02 PM org.jboss.messaging.core.logging.Logger warn
WARNING: Connection failure has been detected: Did not receive ping from server for
org.jboss.messaging.integration.transports.netty.NettyConnection@58e41bc3[local=
/192.168.1.35:46763, remote=c1/192.168.1.35:5445] [code=3]
Aug 6, 2009 12:17:02 PM org.jboss.messaging.core.logging.Logger warn
WARNING: Connection failure has been detected: Did not receive ping from server for
org.jboss.messaging.integration.transports.netty.NettyConnection@178aab40[local=
/192.168.1.35:46761, remote=c1/192.168.1.35:5445] [code=3]
Aug 6, 2009 12:17:02 PM org.jboss.messaging.core.logging.Logger error
SEVERE: Failed to handle failover
MessagingException[errorCode=0 message=null]
at
org.jboss.messaging.core.remoting.impl.wireformat.MessagingExceptionMessage.decodeBody(MessagingExceptionMessage.java:88)
at
org.jboss.messaging.core.remoting.impl.wireformat.PacketImpl.decode(PacketImpl.java:213)
at org.jboss.messaging.core.remoting.impl.PacketDecoder.decode(PacketDecoder.java:444)
at
org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:332)
at
org.jboss.messaging.core.client.impl.ConnectionManagerImpl$DelegatingBufferHandler.bufferReceived(ConnectionManagerImpl.java:1180)
at
org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.messageReceived(MessagingChannelHandler.java:75)
at
org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:105)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:385)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:324)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:306)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:223)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:342)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:329)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:330)
at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:282)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:203)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:113)
at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:53)
at
org.jboss.messaging.integration.transports.netty.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:184)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Aug 6, 2009 12:17:02 PM org.jboss.messaging.core.logging.Logger error
SEVERE: Failed to handle failover
Unable to consume more than 777,000 messages
---------------------------------------------
Key: JBMESSAGING-1693
URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 2.0.0.beta4
Environment: Windows Vista, 32 bit, 2GB RAM
Reporter: Bijith Kumar
Assignee: Andy Taylor
Fix For: 2.0.0
Attachments: JMSBase.java, JMSConsumer.java, JMSSender.java, src.rar,
TestCunsumer.java, TestSender.java
Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers
(Threads) . Consumption hangs after consuming 777,000 messages. i.e. even though I am
able to see the messages from JConsole, Consumers does not read any. Below given are the
memory settings for the Queue
<global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes>
Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of
the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million
messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745
messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read
from "myQQ"
4) Observe from JConsole that the messages are getting consumed. i.e. values of
MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while, consumption hangs (i.e.values of MessageCount and
MessageAdded attributes does not change). I calculated the number of messages consumed by
subtracting MessageCount from messagesAdded. Following are the values I got for last
three runs
Messages Consumed = messagesAdded - MessageCount
a) 800246 - 23246 = 777000
b) 799037 - 22037 = 777000
c) 799037 - 22037 = 777000
It seems the number of messages consumed (777000 in above case) is driven by message size
(and Queue size). Because, when I tried another message, the consumption hanged after
780,000 messages.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira