[rabbitmq-discuss] Fwd: socket error while using rabbitmq and a NAT (Network address translation)

mysurf mail stammailbox at gmail.com
Wed Mar 2 15:19:37 GMT 2011


Well, two correction.
1. I mentioned I did the with/without tracer check on our application. not
the multicast.
2. the computer which I am running the tests on does not have a NAT. I tried
to narrow it down so I found one of the comp that has that problem and does
not have a nat.

OK, and now for the new interesting part. with evidence :-) .

As you suggested I tried to do a test . with the multicast .
I will describe it

 1. made directroy name RMQTest - put both clients in different folder


2. copied a batch file that has the following command to both folders.

runjava com.rabbitmq.examples.MulticastMain -h -p 1434  -e

3. ran it in both folders (finished one, started the other one. not
simultaneously) .
first the 1.7.0. output

castMain -h -p 1434  -e X1X1X1X1
starting consumer #0
starting producer #0
recving rate: 7950 msg/s, min/avg/max latency: 689/6493/26385 microseconds
sending rate: 9434 msg/s
recving rate: 10537 msg/s, min/avg/max latency: 658/4791/27949 microseconds
sending rate: 10194 msg/s
recving rate: 10390 msg/s, min/avg/max latency: 704/5161/24546 microseconds
sending rate: 10460 msg/s
recving rate: 10278 msg/s, min/avg/max latency: 655/5061/27513 microseconds
sending rate: 10513 msg/s
recving rate: 10834 msg/s, min/avg/max latency: 637/4598/28824 microseconds
sending rate: 10623 msg/s
recving rate: 10554 msg/s, min/avg/max latency: 663/15783/92337 microseconds
sending rate: 10909 msg/s


now the 2.3.1.

castMain -h -p 1434  -e X1X1X1X1
starting consumer #0

thats it. doesn't seem to work.

4. ok. now the trace thing.
added a trace of 2.3.1 and changed the multicast 2.3.1 to link to the

the 2.3.1 command
   runjava com.rabbitmq.examples.MulticastMain -h -p 5672 -e
the trace command will be then
   runjava.bat com.rabbitmq.tools.Tracer 5672 1434

and it was successfull, as you can see with the Tracer.

castMain -h -p 5672 -e X1X1X1X1
starting consumer #0
starting producer #0
recving rate: 0 msg/s, min/avg/max latency: 18896/18896/18896 microseconds
sending rate: 2231 msg/s
recving rate: 1201 msg/s, min/avg/max latency: 16142/352034/545121
sending rate: 2126 msg/s
recving rate: 1309 msg/s, min/avg/max latency: 518532/711257/909513
recving rate: 1353 msg/s, min/avg/max latency: 897258/1088853/1260756
sending rate: 2081 msg/s
recving rate: 1359 msg/s, min/avg/max latency: 1239551/1437173/1637659
sending rate: 2119 msg/s
sending rate: 2140 msg/s
recving rate: 1292 msg/s, min/avg/max latency: 1608518/1833688/2038255

I dont think we need tracer for 1.7.0. because 1.7.0. works even without a

I know it is a long thread so far. But if you will succeed in helping us
solve this.
You will be our hero.

On Wed, Mar 2, 2011 at 4:21 PM, Emile Joubert <emile at rabbitmq.com> wrote:

> Hi,
> On 02/03/11 13:25, mysurf mail wrote:
>> 1. multicast 1.7.0.
>> Ahh.. I was looking for the multicast of 1.7.0. we only kept the (rabbit
>> main jar).
>> Ok, I ran it on the computer with the bad 2.3.1. communication and it
>> ran it without a problem.
>> seemed fine. I added the output (in the 1.txt file ).
>> So, This computer runs multicast 1.7.0 and not 2.3.1. a riddle.
> You previously tried MulticastMain from version 2.3.1 with and without the
> tracer and you saw failures without the tracer. Is this correct?
> Can you try running MulticastMain from version 1.7.0 with and without the
> tracer as well? From your description it doesn't sound like you have
> replicated the test in exactly the same way. You will need to use the tracer
> from the 1.7.0 release for this test.
> Do you have any way of repeating this test with the client and server on
> the same LAN or on the same host, in order to eliminate the network as a
> cause of the problem? I'm assuming that all your tests are still traversing
> the NAT infrastructure.
> Another option is to inspect a network traffic dump. We will need the
> binary capture file produced by wireshark or tcpdump to collect all traffic
> on the port you use for AMQP (1434 in your case) on the client and on the
> broker. Please don't send large binaries to the mailing list though. Rather
> place it somewhere where it can be retrieved from.
>  3. 1.7.0. to 2.3.1. -
>> We decided on an emergency solution for the meanwhile - we run rabbitmq
>> 2.3.1 server with 1.7.0. jars at the clients.
>> so far it seems ok. Are we expecting major problems?
> It is impossible to say without understanding the cause.
> -Emile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110302/3b2f0da1/attachment.htm>

More information about the rabbitmq-discuss mailing list