You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by cronos <vi...@googlemail.com> on 2007/08/03 21:41:09 UTC
Socket Woes
Hello,
I am currently load testing activemq using 1 queue & a variant of the
test.php(stomp) client. I have
probably run up 30 iterations of the test, changing various values in the
xml configuration file, each
time, the thread > ActiveMQ Transport: tcp:///127.0.0.1:xxxx dies within a
DispatchCount and
DequeueCount range of 15,000-15,700. Watching the tcp connections, using
netstat, i can see the
socket going into TIME_WAIT and eventually disconnecting. There are no
exceptions.
Envirnoment
==========
Activemq 4.1.1 (binary)
Stomp php
J2SE 5.0 update 8
Cent OS 4 - version 20060930
Typical Queue Stats at socket disconnection
====================================
ConsumerCount > 1
DequeueCount > 15193
DispatchCount > 15194
EnqueueCount > 15194
MemoryPercentageUsed > 0
QueueSize > 1
Broker Stats at socket disconnection
====================================
Committed Memory > 65MB
Used > 9MB
Peck Threads > 31
Life Threads > 29
Test Client
===================================
<?
include_once ("Stomp.php");
$c = new StompConnection("localhost","51516");
$c->connect();
$c->subscribe("/queue/FOO", array("activemq.prefetchSize"=>"1"));
While(true) {
$c->send("/queue/FOO", "Hello World!");
// Wait for the message to come in..
$result = $c->readFrame();
$c->acknowledge($result->headers["message-id"]);
}
$c->disconnect();
?>
Configuration File
===================================
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:amq="http://activemq.org/config/1.0">
<bean
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"
/>
<amq:broker brokerName="activemq" useJmx="true"
advisorySupport="false" persistent="false">
<amq:destinationPolicy>
<amq:policyMap>
<amq:policyEntries>
<amq:policyEntry queue=">">
<amq:deadLetterStrategy>
<amq:individualDeadLetterStrategy queuePrefix="DLQ."
useQueueForQueueMessages="true" />
</amq:deadLetterStrategy>
</amq:policyEntry>
</amq:policyEntries>
</amq:policyMap>
</amq:destinationPolicy>
<amq:managementContext>
<amq:managementContext rmiServerPort="8100" />
</amq:managementContext>
<amq:memoryManager>
<amq:usageManager limit="120 MB" />
</amq:memoryManager>
<amq:persistenceAdapter>
<amq:journaledJDBC>
<dataDirectory>${java.io.tmpdir}/activemq</dataDirectory>
<journalLogFiles>2</journalLogFiles>
</amq:journaledJDBC>
</amq:persistenceAdapter>
<amq:transportConnectors>
<amq:transportConnector>
<uri>tcp://localhost:61616?soTimeout=0</uri>
</amq:transportConnector>
<amq:transportConnector>
<uri>stomp://localhost:51516?soTimeout=0</uri>
</amq:transportConnector>
</amq:transportConnectors>
</amq:broker>
</beans>
Analysis
=============
One obvious fact is that the broker dispatches a message (number 15194) to
the client
before the disconnection. The client doesn't ack the message, hence the 1
message stuck in
the queue. The question is what is causing the disconnection? Is there
anything we can do
to maintain the connection?
I have tried to specify socket behaviour via the configuration file as
follows:
<uri>tcp://localhost:61616?soTimeout=0</uri>
<uri>tcp://localhost:61616?socketBufferSize=65536 </uri>
uri>tcp://localhost:61616?tcpNoDelayEnabled=false </uri>
and nothing has worked so far. Also the usagemanager has 120 MB of memory.
Has anybody encountered
this problem before? Any insights appreciated.
Thanks
--
View this message in context: http://www.nabble.com/Socket-Woes-tf4214291s2354.html#a11989352
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Socket Woes
Posted by cronos <vi...@googlemail.com>.
MODIFIED Test Client (added usleep function)
===================================
<?
include_once ("Stomp.php");
$c = new StompConnection("localhost","51516");
$c->connect();
$c->subscribe("/queue/FOO", array("activemq.prefetchSize"=>"1"));
While(true) {
$c->send("/queue/FOO", "Hello World!");
// Wait for the message to come in..
usleep(500000);
$result = $c->readFrame();
$c->acknowledge($result->headers["message-id"]);
}
$c->disconnect();
?>
Having added the usleep() function, the message consumption jumped
from 15,000 to 26,000 consistently over many test cycles. I figured
usleep will delay the interval between message production and
consumption. Please, if u are running AMQ 4.1.1, please can u use the
test client (without unsleep) to run at leat one test and post the
result... thanks
--
View this message in context: http://www.nabble.com/Socket-Woes-tf4214291s2354.html#a12010727
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Socket Woes
Posted by cronos <vi...@googlemail.com>.
Just ran another test with the following configuration (transport
connectors). The queue stats for
this test are as follows:
ConsumerCount > 1
DequeueCount > 15117
DispatchCount > 15118
EnqueueCount > 15118
QueueSize > 1
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:amq="http://activemq.org/config/1.0">
<bean
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"
/>
<amq:broker brokerName="activemq" useJmx="true"
advisorySupport="false" persistent="false">
<amq:destinationPolicy>
<amq:policyMap>
<amq:policyEntries>
<amq:policyEntry queue=">">
<amq:deadLetterStrategy>
<amq:individualDeadLetterStrategy queuePrefix="DLQ."
useQueueForQueueMessages="true" />
</amq:deadLetterStrategy>
</amq:policyEntry>
</amq:policyEntries>
</amq:policyMap>
</amq:destinationPolicy>
<amq:managementContext>
<amq:managementContext rmiServerPort="8100" />
</amq:managementContext>
<amq:memoryManager>
<amq:usageManager limit="120 MB" />
</amq:memoryManager>
<amq:persistenceAdapter>
<amq:journaledJDBC>
<dataDirectory>${java.io.tmpdir}/activemq</dataDirectory>
<journalLogFiles>2</journalLogFiles>
</amq:journaledJDBC>
</amq:persistenceAdapter>
<amq:transportConnectors>
<amq:transportConnector>
<uri>tcp://localhost:61616?soTimeout=0;socketBufferSize=65536;trace=true;wireFormat.tcpNoDelayEnabled=true;wireFormat.maxInactivityDuration=0;</uri>
</amq:transportConnector>
<amq:transportConnector>
<uri>stomp://localhost:51516?soTimeout=0;socketBufferSize=65536;trace=true;wireFormat.tcpNoDelayEnabled=true;wireFormat.maxInactivityDuration=0;</uri>
</amq:transportConnector>
</amq:transportConnectors>
</amq:broker>
</beans>
--
View this message in context: http://www.nabble.com/Socket-Woes-tf4214291s2354.html#a11993323
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Socket Woes
Posted by Tom Samplonius <to...@samplonius.org>.
----- "Elliotte Harold" <er...@gmail.com> wrote:
> >
> > There are known bugs in Stomp in 4.1.1. And there were some
> issues with
> > sockets not being cleaned up properly.
> >
> > I would re-test with a 5.0-snapshot.
> >
> > Tom
> >
>
> Could you elaborate on these? This may also apply to some issues the
> python
> folks on my team have been having.
There is a large archive of messages on socket issues. It is impossible to miss.
The worst issue for me with Stomp in 4.1.1, is that you can't apply passwords to queues/topics. The Stomp connector always ignores the password and gives you full access. This issue is not even fixed in the 5.0-snapshots yet, but there is a patch.
> --
> Elliotte Rusty Harold
> erharold@gmail.com
Tom
Re: Socket Woes
Posted by Elliotte Harold <er...@gmail.com>.
On 8/6/07, Tom Samplonius <to...@samplonius.org> wrote:
>
>
> > Envirnoment
> > ==========
> >
> > Activemq 4.1.1 (binary)
> > Stomp php
> > J2SE 5.0 update 8
> > Cent OS 4 - version 20060930
> ...
>
> There are known bugs in Stomp in 4.1.1. And there were some issues with
> sockets not being cleaned up properly.
>
> I would re-test with a 5.0-snapshot.
>
> Tom
>
Could you elaborate on these? This may also apply to some issues the python
folks on my team have been having.
--
Elliotte Rusty Harold
erharold@gmail.com
Re: Socket Woes
Posted by Tom Samplonius <to...@samplonius.org>.
----- "cronos" <vi...@googlemail.com> wrote:
...
> Envirnoment
> ==========
>
> Activemq 4.1.1 (binary)
> Stomp php
> J2SE 5.0 update 8
> Cent OS 4 - version 20060930
...
There are known bugs in Stomp in 4.1.1. And there were some issues with sockets not being cleaned up properly.
I would re-test with a 5.0-snapshot.
Tom