headers
Brett Cameron | 1 Jul 2012 11:04
Picon
Gravatar

Re: Moving on

Matthew,

 

Congratulations on the new role and best of luck with your future endeavours. You have been instrumental in the creation and evolution of a truly excellent piece of software that continues to grow in popularity - something to be very proud of. I have no doubt that you will continue to make such contributions in your future projects.

 

The AtomizeJS stuff looks interesting, and I am looking forward to watching things develop!

 

Regards,

Brett



On Sat, Jun 30, 2012 at 10:36 AM, Paul Jones <pauljones23-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
+1. Great work on everything you've done!


On Sat, Jun 30, 2012 at 6:58 AM, James Carr <james.r.carr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
+1. Your contributions will be missed!


On Fri, Jun 22, 2012 at 7:41 AM, Matthew Sackman <matthew-mQ7lE4MOPXtWk0Htik3J/w@public.gmane.org> wrote:
As some of you will have noticed, over the last few months, my
contributions to RabbitMQ have decreased fairly sharply. I have been
busying myself with other projects (eg AtomizeJS) and have only really
returned to work on Rabbit to help with knowledge transfer
(active/active HA systems) and other issues that interest me (eg the
Codel AQM experiments). Even that though is now at an end.

Whilst I am staying with VMware, I'm now officially moving on from
working with RabbitMQ to pastures new.

I first started work on RabbitMQ in the summer of 2006 and whilst there
were about 2.5 years in which I did various bits of a PhD and didn't
have anything to do with Rabbit during that time, I've nevertheless been
involved in Rabbit on and off for the last 6 years. When I returned to
LShift early spring 2009, Rabbit was a very much more primitive beast
than it is today - it couldn't hold more messages than could fit in RAM,
there were no plugins, we didn't implement the whole of AMQP 0-8, let
alone 0-9-1, there was no form of HA at all, etc etc. I am very grateful
to have had the opportunity to work on many of those areas and help the
community and guide the direction of Rabbit.

Obviously, Rabbit is in very good hands going forwards, not just with
the remaining members of the original team that came, along with myself,
to VMware from LShift, but with additional recruits, and of course with
the community that has, through bug reports, the creation of many
clients and applications, and through publicity in the form of blog
posts, books, and tweets, helped so much with Rabbit's growth and
continuing popularity.

Thank you, one and all.

Matthew
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss-ETbvJ2rUIr4qBm01orBoR9BPR1lH4CV8@public.gmane.org
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss-ETbvJ2rUIr4qBm01orBoR9BPR1lH4CV8@public.gmane.org
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss



_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss <at> lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


<div>
<p class="MsoNormal"><span lang="EN-NZ">Matthew,</span></p>

<p class="MsoNormal"><span lang="EN-NZ">&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-NZ">Congratulations on the new role and best of
luck with your future endeavours. You have been instrumental in the creation and
evolution of a truly excellent piece of software that continues to grow in
popularity - something to be very proud of. I have no doubt that you will continue to make such contributions
in your future projects. <br></span></p>

<p class="MsoNormal"><span lang="EN-NZ">&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-NZ">The AtomizeJS stuff looks interesting, and I am
looking forward to watching things develop!</span></p>

<p class="MsoNormal"><span lang="EN-NZ">&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-NZ">Regards,</span></p>

<p class="MsoNormal"><span lang="EN-NZ">Brett</span></p>

<br><br><div class="gmail_quote">On Sat, Jun 30, 2012 at 10:36 AM, Paul Jones <span dir="ltr">&lt;<a href="mailto:pauljones23@..." target="_blank">pauljones23@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
+1. Great work on everything you've done!<div class="HOEnZb"><div class="h5">
<br><br><div class="gmail_quote">On Sat, Jun 30, 2012 at 6:58 AM, James Carr <span dir="ltr">&lt;<a href="mailto:james.r.carr@...m" target="_blank">james.r.carr@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">+1. Your contributions will be missed!<div><div>
<br><br><div class="gmail_quote">On Fri, Jun 22, 2012 at 7:41 AM, Matthew Sackman <span dir="ltr">&lt;<a href="mailto:matthew@..." target="_blank">matthew@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">As some of you will have noticed, over the last few months, my<br>
contributions to RabbitMQ have decreased fairly sharply. I have been<br>
busying myself with other projects (eg AtomizeJS) and have only really<br>
returned to work on Rabbit to help with knowledge transfer<br>
(active/active HA systems) and other issues that interest me (eg the<br>
Codel AQM experiments). Even that though is now at an end.<br><br>
Whilst I am staying with VMware, I'm now officially moving on from<br>
working with RabbitMQ to pastures new.<br><br>
I first started work on RabbitMQ in the summer of 2006 and whilst there<br>
were about 2.5 years in which I did various bits of a PhD and didn't<br>
have anything to do with Rabbit during that time, I've nevertheless been<br>
involved in Rabbit on and off for the last 6 years. When I returned to<br>
LShift early spring 2009, Rabbit was a very much more primitive beast<br>
than it is today - it couldn't hold more messages than could fit in RAM,<br>
there were no plugins, we didn't implement the whole of AMQP 0-8, let<br>
alone 0-9-1, there was no form of HA at all, etc etc. I am very grateful<br>
to have had the opportunity to work on many of those areas and help the<br>
community and guide the direction of Rabbit.<br><br>
Obviously, Rabbit is in very good hands going forwards, not just with<br>
the remaining members of the original team that came, along with myself,<br>
to VMware from LShift, but with additional recruits, and of course with<br>
the community that has, through bug reports, the creation of many<br>
clients and applications, and through publicity in the form of blog<br>
posts, books, and tweets, helped so much with Rabbit's growth and<br>
continuing popularity.<br><br>
Thank you, one and all.<br><br>
Matthew<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br><a href="mailto:rabbitmq-discuss@..." target="_blank">rabbitmq-discuss@...</a><br><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</blockquote>
</div>
<br>
</div></div>
<br>_______________________________________________<br>
rabbitmq-discuss mailing list<br><a href="mailto:rabbitmq-discuss@..." target="_blank">rabbitmq-discuss@...</a><br><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br><br>
</blockquote>
</div>
<br>
</div></div>
<br>_______________________________________________<br>
rabbitmq-discuss mailing list<br><a href="mailto:rabbitmq-discuss@...">rabbitmq-discuss <at> lists.rabbitmq.com</a><br><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br><br>
</blockquote>
</div>
<br>
</div>
Permalink | Reply | 0 comments |
headers
Charles Law | 1 Jul 2012 18:42
Favicon
Gravatar

Preserving Order Across Multiple Consumers on a Single Queue

<div></div>
Permalink | Reply | 1 comment |
headers
spronkey | 1 Jul 2012 02:14

Consumer/publisher - last message published does not appear in queue, but appears in firehose trace!?

Hi all,
 
I've got a double pump scenario going on - that is, my application enqueues a broadcast message, that then gets picked up by consumer type 1, and transformed into many singlecast messages on a separate queue that are picked up by consumer type 2. Consumer type 1 also creates and publishes a confirmation message in yet another queue, containing the number of singlecast messages it enqueued.
 
 
What's happening is that Consumer type 1 is operating fine up until it needs to enqueue the confirmation message. The first time any particular type 1 consumer publishes a confirm message, it never ends up in the confirmation queue. All singlecast messages end up correctly in their queues. If the same process is allowed to consume a second broadcast message, the confirmation it publishes does end up in the confirmation queue (seemingly every time, but this could be a red herring). Firehose trace would indicate that the consumer is doing everything it should - it shows all confirm message publishes with correct exchange and routing key, yet confirm queue remains empty.
 
The Consumer/publisher operates as follows:
 
  1. Initiate 2 connections (to same server, currently): "in", and "out"
  2. Create 4 channels:
    1. bound to gn-broadcast
    2. bound to gn-smsout
    3. bound to gn-emailout
    4. bound to msg-broadcast-confirm
  3. Consume loop begins on in channel consuming from broadcast queue
    1. Gather person list from broadcast message body
    2. Start transactions on smsout and emailout channels
    3. Loop through person list. For each, create two AMQP Messages w/ single person and publish to smsout and emailout queues respectively
    4. Once finished looping, commit transaction (assuming all OK)
    5. Create new AMQPMessage with number of persons and publish to msg-broadcast-confirm queue
A copy of the script is here for reference: http://pastebin.com/GH1hr1ph
 
The php-amqplib debug output clearly shows in all cases that the basic_publish message is being sent with the correct contents of the confirmation message. There are no breaks in the connection or exceptions occurring. Likewise, the firehose trace from rabbit publishes a message to trace queue showing the confirm message has been published, with the correct exchange and correct routing key.  However, my confirm queue is completely empty!
 
Why would this occur? Do I need more than 2 connections? (I didn't think I would need more than 1, but the sms and email messages don't seem to publish nicely without a second connection).
 
What on earth is going on? It's doing my head in!
 
Rabbitmq-server version 2.8.2 running in a Turnkey LAMP VM (Ubuntu 10.04). Client is running on Mac OS X 10.6.8 with latest php-amqplib.
 
Regards,
 
Keith
<div>
<div>Hi all,<div>&nbsp;</div>
</div>
<div>I've got a double pump scenario going on - that is, my application enqueues a&nbsp;broadcast message, that then gets picked up by consumer type 1, and transformed into many&nbsp;singlecast messages on a separate queue that are picked up by consumer type 2. Consumer type 1 also creates and publishes a confirmation message in yet another queue, containing the number of singlecast messages it enqueued.<div>&nbsp;</div>
<div>&nbsp;</div>
</div>
<div>What's happening is that Consumer type 1 is operating fine up until it needs to enqueue the confirmation message. The first time any particular type 1 consumer publishes a confirm message, it never ends up in the confirmation queue. All singlecast messages end up correctly in their queues. If the same process is allowed to consume a second broadcast message, the confirmation it publishes does end up in the confirmation queue (seemingly every time, but this could be a red herring). Firehose trace would indicate that the consumer is doing everything it should - it shows all confirm message publishes with correct exchange and routing key, yet confirm queue remains empty.<div>&nbsp;</div>
</div>
<div>The Consumer/publisher operates as follows:<div>&nbsp;</div>
</div>
<ol>
<li>Initiate 2 connections (to same server, currently): "in", and "out"</li>
<li>Create 4 channels:</li>
<ol>
<li>bound to gn-broadcast</li>
<li>bound to gn-smsout</li>
<li>bound to gn-emailout</li>
<li>bound to msg-broadcast-confirm</li>
</ol>
<li>Consume loop begins on&nbsp;in channel consuming from&nbsp;broadcast queue</li>
<ol>
<li>Gather person list from broadcast message body</li>
<li>Start transactions on smsout and&nbsp;emailout channels</li>
<li>Loop through person list. For each, create two AMQP Messages w/ single person and publish to smsout&nbsp;and emailout queues respectively</li>
<li>Once finished looping, commit transaction (assuming all OK)</li>
<li>Create new AMQPMessage with number of persons and publish to msg-broadcast-confirm queue</li>
</ol>
</ol>
<div>A copy of the script is here for reference: <a href="http://pastebin.com/GH1hr1ph">http://pastebin.com/GH1hr1ph</a>
</div>
<div><div>&nbsp;</div></div>
<div>The php-amqplib debug output clearly shows in all cases that the basic_publish message is being sent with the correct contents of the confirmation message. There are no breaks in the connection or exceptions occurring. Likewise, the firehose trace from rabbit publishes a message to trace queue showing the confirm message has been published, with the correct exchange and correct routing key.&nbsp; However, my confirm queue is completely empty!</div>
<div><div>&nbsp;</div></div>
<div>Why would this occur? Do I need more than 2 connections? (I didn't think I would need more than 1, but the sms and email messages don't seem to publish nicely without a second connection).</div>
<div><div>&nbsp;</div></div>
<div>What on earth is going on? It's doing my head in!</div>
<div><div>&nbsp;</div></div>
<div>Rabbitmq-server version 2.8.2 running in a Turnkey LAMP VM (Ubuntu 10.04). Client is running on Mac OS X 10.6.8 with latest php-amqplib.</div>
<div><div>&nbsp;</div></div>
<div>Regards,</div>
<div><div>&nbsp;</div></div>
<div>Keith</div>
</div>
Permalink | Reply | 2 comments |
headers
spronkey | 1 Jul 2012 02:16

Re: Consumer/publisher - last message published does not appear in queue, but appears in firehose trace!?

I should note that in all cases, queues/exchanges are durable, non-exclusive, and without autodelete.

<div><p>I should note that in all cases, queues/exchanges are durable, non-exclusive, and without autodelete.</p></div>
Permalink | Reply | 0 comments |
headers
jonathan augenstine | 1 Jul 2012 20:07
Picon

rabbitmq-c RPC example

I would like to say that rabbitmq is a very nice messaging implementation.  I had to implement a module to coordinate a very large number of processes on Linux and over a one week time period installed rabbitmq, worked out the implementation, and pushed to production.  I expected to have to work out some bugs, but amazingly it just worked.  One or two minor tweaks and it has been running for almost two weeks now with out issue.

That being said, I implemented this using the C library.  I used a basic publish/subscribe approach to the implementation.  The reality is that the design pattern really fits an RPC implementation.  My problem was that I was pressed for time and could not quite get the details worked out for an RPC implementation.  I was wondering if someone had an example of a C implementation of the RPC on rabbitmq?

Jonathan

<div><p>I would like to say that rabbitmq is a very nice messaging implementation.&nbsp; I had to implement a module to coordinate a very large number of processes on Linux and over a one week time period installed rabbitmq, worked out the implementation, and pushed to production.&nbsp; I expected to have to work out some bugs, but amazingly it just worked.&nbsp; One or two minor tweaks and it has been running for almost two weeks now with out issue.<br><br>That being said, I implemented this using the C library.&nbsp; I used a basic publish/subscribe approach to the implementation.&nbsp; The reality is that the design pattern really fits an RPC implementation.&nbsp; My problem was that I was pressed for time and could not quite get the details worked out for an RPC implementation.&nbsp; I was wondering if someone had an example of a C implementation of the RPC on rabbitmq?<br><br>Jonathan<br><br></p></div>
Permalink | Reply | 2 comments |
headers
Matthias Radestock | 1 Jul 2012 20:23
Favicon

Re: Vanishing of persistent messages on durable, auto-deleting queue with dead-lettering

Ernest,

On 29/06/12 17:27, Ernest Staszuk wrote:
> After disconnecting a client from durable, auto-deleting queue with
> dead-lettering-exchange I would expect passing all messages to dead
> letter exchange and then deleting queue. But surprisingly for me
> queue was deleted and messages just vanished into limbo.

That's the defined behaviour. From 
http://www.rabbitmq.com/extensions.html#dead-letter-exchanges
<quote>
A message is dead-lettered when any of the following events occur:
- The message is rejected (basic.reject or basic.nack) with 
requeue=false; or
- The TTL for the message expires.
</quote>

> Is this behavior desirable? Why?

We deliberately kept the set of operations susceptible to dead-lettering 
small, to avoid unintended consequences. It is possible that actions 
like auto-deletion, queue lease expiry, explicit deletion and purging 
should all trigger the dead-letter mechanism, but I'd like to see 
compelling use cases first before making such a change.

> How should I get around this problem? I thought about declare queue
> as non auto deleting and making own monitoring daemon, which could
> handle cleaning queues without consumers. Is there any simpler way of
> achieve my goal?

Perhaps a combination of queue leases and ttl would work. The former has 
the additional advantage of allowing the system to mask temporary 
consumer and connectivity failures.

Regards,

Matthias.
Permalink | Reply | 4 comments |
headers
Matthias Radestock | 1 Jul 2012 20:28
Favicon

Re: Vanishing of persistent messages on durable, auto-deleting queue with dead-lettering

On 01/07/12 19:23, Matthias Radestock wrote:
> On 29/06/12 17:27, Ernest Staszuk wrote:
>> durable, auto-deleting queue

btw, it is somewhat nonsensical to make an auto-delete queue 
non-durable. Durability ensures that a queue survives broker restarts, 
while auto-deletion ensures it gets deleted when the last consumer 
vanishes. But of course restarting the broker causes all consumers to 
vanish, so the queue will disappear. The only exception is when the 
queue hasn't had any consumers yet when the broker stops.

Matthias.
Permalink | Reply | 0 comments |
headers
Matthias Radestock | 1 Jul 2012 20:40
Favicon

Re: Consumer/publisher - last message published does not appear in queue, but appears in firehose trace!?

Keith,

On 01/07/12 01:14, spronkey wrote:
>  3. Consume loop begins on *in* channel consuming from *broadcast* queue
>      1. Gather person list from broadcast message body
>      2. Start transactions on *smsout* and *emailout* channels
>      3. Loop through person list. For each, create two AMQP Messages w/
>         single person and publish to *smsout *and *emailout* queues
>         respectively
>      4. Once finished looping, commit transaction (assuming all OK)
>      5. Create new AMQPMessage with number of persons and publish to
>         *msg-broadcast-confirm* queue

In AMQP, once a channel is put in transactional mode with tx.select(), 
it stays in that mode forever. So the message published in step 5 above 
is part of a new transaction and hence will only end up in queues  at 
the next tx.commit().

Regards,

Matthias.
PS: in future please post to the rabbitmq-discuss mailing list rather 
than the google group.
Permalink | Reply | 0 comments |
headers
Roman Gaufman | 2 Jul 2012 03:09
Picon

Ruby-AMQP with Federation doesn't work?

I'm trying to get the Ruby-AMQP gem working with RabbitMQ's federation plugin.


I have a federation set up as following:
{rabbitmq_federation, [ {exchanges, [[{exchange, "xanview"}, {virtual_host, "/"}, {type, "topic"}, {durable, true}, {auto_delete, false}, {internal, false}, {upstream_set, "my-upstreams"}] ]},
It appears in the web interface as:
Type x-federation Parameters arguments: upstream-set: my-upstreams type: topic durable: true
I try to use it in Ruby in a consumer like this:
exchange = AMQP::Exchange.new(channel, "x-federation", "my-exchange", :durable => true)
However in the RabbitMQ config I get this error:
connection <0.16597.1>, channel 2 - error: {amqp_error,precondition_failed, "inequivalent arg 'type'for exchange 'xanview' in vhost '/': received none but current is the value 'topic' of type 'longstr'", 'exchange.declare'}
It seems something in the Ruby-AMQP gem is preventing me from using an exchange type "x-federation"?

Also when I try to consume messages sent to a federated exchange using your typical:
AMQP.start('amqp://guest:guest <at> localhost:25672') do |connection, open_ok| channel = AMQP::Channel.new(connection) channel.queue("", :durable => true) do |queue| queue.bind('xanview', :routing_key => '#') queue.subscribe do |metadata, payload| puts "Recieved message: #{payload.inspect}." end end end
I get this exception for the first message received:
/usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/table.rb:89:in `decode': NotImplementedError (NotImplementedError) from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/table_value_decoder.rb:144:in `decode_hash' from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/table_value_decoder.rb:46:in `decode_array' from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/table.rb:99:in `decode' from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/client.rb:1560:in `block in decode_properties' from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/client.rb:1543:in `each' from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/client.rb:1543:in `decode_properties' from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/frame.rb:142:in `decode_payload' from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/frame.rb:115:in `body_size' from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-client-0.9.3/lib/amq/client/async/adapter.rb:675:in `content_complete?' from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-client-0.9.3/lib/amq/client/async/adapter.rb:667:in `frameset_complete?' from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-client-0.9.3/lib/amq/client/async/adapter.rb:518:in `receive_frame' from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-client-0.9.3/lib/amq/client/async/adapters/event_machine.rb:327:in `receive_data' from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine' from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run' from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amqp-0.9.6/lib/amqp/connection.rb:38:in `start' from client1.rb:7:in `<main>'
Any advice would be greatly appreciated. Maybe someone has an example of using RabbitMQ Federation with the Ruby-AMQP gem?

Thank you,

Roman
<div>
<p>I'm trying to get the Ruby-AMQP gem working with RabbitMQ's federation plugin.
</p>
<div><br></div>
<div>I have a federation set up as following:</div>
<div>

{rabbitmq_federation,
   [ {exchanges, [[{exchange,     "xanview"},
                   {virtual_host, "/"},
                   {type,         "topic"},
                   {durable,      true},
                   {auto_delete,  false},
                   {internal,     false},
                   {upstream_set, "my-upstreams"}]
                 ]}, </div>
<div>It appears in the web interface as:</div>
<div>

Type    x-federation
Parameters   arguments: upstream-set:   my-upstreams
                                                type:   topic
                         durable:   true</div>
<div>I try to use it in Ruby in a consumer like this:</div>
<div><div>

<span>exchange</span> <span>=</span> <span>AMQP</span><span>::</span><span>Exchange</span><span>.</span><span>new</span><span>(</span><span>channel</span><span>,</span> <span>"x-federation"</span><span>,</span> <span>"my-exchange"</span><span>,</span> <span>:durable</span> <span>=&gt;</span> <span>true</span><span>)</span>
<div><span>However in the RabbitMQ config I get this error:</span></div>
<div><span>

connection &lt;0.16597.1&gt;, channel 2 - error:
{amqp_error,precondition_failed,
            "inequivalent arg 'type'for exchange 'xanview' in vhost '/': received none but current is the value 'topic' of type 'longstr'",
            'exchange.declare'}</span></div>
</div></div>
<div>It seems something in the Ruby-AMQP gem is preventing me from using an exchange type "x-federation"?</div>
<div><br></div>
<div>Also when I try to consume messages sent to a federated exchange using your typical:</div>

<div>

<span>AMQP</span><span>.</span><span>start</span><span>(</span><span>'amqp://guest:guest <at> localhost:25672'</span><span>)</span> <span>do</span> <span>|</span><span>connection</span><span>,</span> <span>open_ok</span><span>|</span>
  <span>channel</span>  <span>=</span> <span>AMQP</span><span>::</span><span>Channel</span><span>.</span><span>new</span><span>(</span><span>connection</span><span>)</span>
  <span>channel</span><span>.</span><span>queue</span><span>(</span><span>""</span><span>,</span> <span>:durable</span> <span>=&gt;</span> <span>true</span><span>)</span> <span>do</span> <span>|</span><span>queue</span><span>|</span>
    <span>queue</span><span>.</span><span>bind</span><span>(</span><span>'xanview'</span><span>,</span> <span>:routing_key</span> <span>=&gt;</span> <span>'#'</span><span>)</span>
    <span>queue</span><span>.</span><span>subscribe</span> <span>do</span> <span>|</span><span>metadata</span><span>,</span> <span>payload</span><span>|</span>
      <span>puts</span> <span>"Recieved message: </span><span>#{</span><span>payload</span><span>.</span><span>inspect</span><span>}</span><span>."</span>
    <span>end</span> 
  <span>end</span> 
<span>end</span>
</div>
<div>I get this exception for the first message received:</div>
<div>

<span>/usr/≤/span><span>local</span><span>/</span><span>rvm</span><span>/</span><span>gems</span><span>/</span><span>ruby</span><span>-</span><span>1</span><span>.</span><span>9</span><span>.</span><span>3</span><span>-</span><span>p194</span><span>/</span><span>gems</span><span>/</span><span>amq</span><span>-</span><span>protocol</span><span>-</span><span>0</span><span>.</span><span>9</span><span>.</span><span>3</span><span>/</span><span>lib</span><span>/</span><span>amq</span><span>/</span><span>protocol</span><span>/</span><span>table</span><span>.</span><span>rb</span><span>:</span><span>89</span><span>:in</span> <span>`decode': NotImplementedError (NotImplementedError)</span>
<span>    from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/table_value_decoder.rb:144:in `</span><span>decode_hash</span><span>'</span>
<span>    from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/table_value_decoder.rb:46:in `decode_array'</span>
    <span>from</span> <span>/usr/≤/span><span>local</span><span>/</span><span>rvm</span><span>/</span><span>gems</span><span>/</span><span>ruby</span><span>-</span><span>1</span><span>.</span><span>9</span><span>.</span><span>3</span><span>-</span><span>p194</span><span>/</span><span>gems</span><span>/</span><span>amq</span><span>-</span><span>protocol</span><span>-</span><span>0</span><span>.</span><span>9</span><span>.</span><span>3</span><span>/</span><span>lib</span><span>/</span><span>amq</span><span>/</span><span>protocol</span><span>/</span><span>table</span><span>.</span><span>rb</span><span>:</span><span>99</span><span>:in</span> <span>`decode'</span>
<span>    from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/client.rb:1560:in `</span><span>block</span> <span>in</span> <span>decode_properties</span><span>'</span>
<span>    from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/client.rb:1543:in `each'</span>
    <span>from</span> <span>/usr/≤/span><span>local</span><span>/</span><span>rvm</span><span>/</span><span>gems</span><span>/</span><span>ruby</span><span>-</span><span>1</span><span>.</span><span>9</span><span>.</span><span>3</span><span>-</span><span>p194</span><span>/</span><span>gems</span><span>/</span><span>amq</span><span>-</span><span>protocol</span><span>-</span><span>0</span><span>.</span><span>9</span><span>.</span><span>3</span><span>/</span><span>lib</span><span>/</span><span>amq</span><span>/</span><span>protocol</span><span>/</span><span>client</span><span>.</span><span>rb</span><span>:</span><span>1543</span><span>:in</span> <span>`decode_properties'</span>
<span>    from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/frame.rb:142:in `</span><span>decode_payload</span><span>'</span>
<span>    from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-protocol-0.9.3/lib/amq/protocol/frame.rb:115:in `body_size'</span>
    <span>from</span> <span>/usr/≤/span><span>local</span><span>/</span><span>rvm</span><span>/</span><span>gems</span><span>/</span><span>ruby</span><span>-</span><span>1</span><span>.</span><span>9</span><span>.</span><span>3</span><span>-</span><span>p194</span><span>/</span><span>gems</span><span>/</span><span>amq</span><span>-</span><span>client</span><span>-</span><span>0</span><span>.</span><span>9</span><span>.</span><span>3</span><span>/</span><span>lib</span><span>/</span><span>amq</span><span>/</span><span>client</span><span>/</span><span>async</span><span>/</span><span>adapter</span><span>.</span><span>rb</span><span>:</span><span>675</span><span>:in</span> <span>`content_complete?'</span>
<span>    from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-client-0.9.3/lib/amq/client/async/adapter.rb:667:in `</span><span>frameset_complete?</span><span>'</span>
<span>    from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/amq-client-0.9.3/lib/amq/client/async/adapter.rb:518:in `receive_frame'</span>
    <span>from</span> <span>/usr/≤/span><span>local</span><span>/</span><span>rvm</span><span>/</span><span>gems</span><span>/</span><span>ruby</span><span>-</span><span>1</span><span>.</span><span>9</span><span>.</span><span>3</span><span>-</span><span>p194</span><span>/</span><span>gems</span><span>/</span><span>amq</span><span>-</span><span>client</span><span>-</span><span>0</span><span>.</span><span>9</span><span>.</span><span>3</span><span>/</span><span>lib</span><span>/</span><span>amq</span><span>/</span><span>client</span><span>/</span><span>async</span><span>/</span><span>adapters</span><span>/</span><span>event_machine</span><span>.</span><span>rb</span><span>:</span><span>327</span><span>:in</span> <span>`receive_data'</span>
<span>    from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `</span><span>run_machine</span><span>'</span>
<span>    from /usr/local/rvm/gems/ruby-1.9.3-p194/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run'</span>
    <span>from</span> <span>/usr/≤/span><span>local</span><span>/</span><span>rvm</span><span>/</span><span>gems</span><span>/</span><span>ruby</span><span>-</span><span>1</span><span>.</span><span>9</span><span>.</span><span>3</span><span>-</span><span>p194</span><span>/</span><span>gems</span><span>/</span><span>amqp</span><span>-</span><span>0</span><span>.</span><span>9</span><span>.</span><span>6</span><span>/</span><span>lib</span><span>/</span><span>amqp</span><span>/</span><span>connection</span><span>.</span><span>rb</span><span>:</span><span>38</span><span>:in</span> <span>`start'</span>
<span>    from client1.rb:7:in `</span><span>&lt;</span><span>main</span><span>&gt;</span><span>'</span>

</div>
<div>Any advice would be greatly appreciated. Maybe someone has an example of using RabbitMQ Federation with the Ruby-AMQP gem?</div>
<div><br></div>
<div>Thank you,</div>
<div><br></div>
<div>Roman</div>
</div>
Permalink | Reply | 3 comments |
headers
Deelo55 | 2 Jul 2012 09:48
Picon

RabbitMQ subscriber loses connection across firewalls after long idle

My RabbitMQ subscriber stops receiving messages when my connection is idle
for more than 300 seconds. I've tested this on the same network and I do not
have this problem. The problem only occurs when I am trying to attempt a
subscription through a firewall (Cisco ASA 5505).

From some research it appears to be a problem with the Cisco ASA 5505. Is
there a workaround for this issue? I'm surprised the connection drops
silently without any warning despite using heartbeats.

		ConnectionFactory factory = new ConnectionFactory();
		factory.setHost(host);
		factory.setRequestedHeartbeat(10);
		
		Connection connection = factory.newConnection();
		
		Channel channel = connection.createChannel();

		channel.exchangeDeclare(exchange, "topic");
		String queueName = channel.queueDeclare().getQueue();
		channel.queueBind(queueName, exchange, topic);
		consumer = new QueueingConsumer(channel);
		channel.basicConsume(queueName, true, consumer);

I've tried adding this to my rabbitmq.config:

[
        {rabbit, [{tcp_listen_options, [{keepalive, true}]}]}
].

but I receive errors as soon as I try to subscribe:

Exception in thread "main" java.io.IOException
	at com.rabbitmq.client.impl.AMQChannel.wrap(AMQChannel.java:106)
	at com.rabbitmq.client.impl.AMQChannel.wrap(AMQChannel.java:102)
	at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.java:353)
	at
com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:516)
	at
com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:533)
	at
vantage.messaging.rabbitmq.RabbitMqPublisher.<init>(RabbitMqPublisher.java:28)
	at vantage.messaging.rabbitmq.TimeoutTest.main(TimeoutTest.java:13)
Caused by: com.rabbitmq.client.ShutdownSignalException: connection error;
reason: java.io.EOFException
	at com.rabbitmq.utility.ValueOrException.getValue(ValueOrException.java:67)
	at
com.rabbitmq.utility.BlockingValueOrException.uninterruptibleGetValue(BlockingValueOrException.java:33)
	at
com.rabbitmq.client.impl.AMQChannel$BlockingRpcContinuation.getReply(AMQChannel.java:343)
	at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.java:306)
	... 4 more
Caused by: java.io.EOFException
	at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:290)
	at com.rabbitmq.client.impl.Frame.readFrom(Frame.java:95)
	at
com.rabbitmq.client.impl.SocketFrameHandler.readFrame(SocketFrameHandler.java:131)
	at
com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:501)

--
View this message in context: http://rabbitmq.1065348.n5.nabble.com/RabbitMQ-subscriber-loses-connection-across-firewalls-after-long-idle-tp20480.html
Sent from the RabbitMQ mailing list archive at Nabble.com.
Permalink | Reply | 13 comments |

Gmane