Hey everyone,

I sincerely hope that this is stupid question with an easy answer. I am
trying to build a somewhat recent version of the rabbitmq-c library to use
with the PHP extension, but that uses the 0-8 protocol since our production
broker is still 1.7.2 (working on upgrading that, but that?s a separate
discussion.)

To do so, I edited the configure file to point to the amqp-rabbitmq-0.8.json
codegen spec, changed the Makefile to not build tools, examples and tests
(those broke,) and tried to un it. According to my server however, its still
trying to use 0-9-1 (Expected 0x000A000A method frame on channel 0, got
frame type 65)

Should this have worked? Am I maybe just installing this wrong? I cleaned
out all librabbitmq.so files and symlinks, so I doubt its the problem, but I
am looking for a sanity check here.

Thanks,
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110228/2aff97ee/attachment.htm>

Search Discussions

  • David Wragg at Feb 28, 2011 at 10:26 pm
    Hi Pieter,

    Pieter de Zwart <pdezwart at rubiconproject.com> writes:
    I sincerely hope that this is stupid question with an easy answer. I am
    trying to build a somewhat recent version of the rabbitmq-c library to use
    with the PHP extension, but that uses the 0-8 protocol since our production
    broker is still 1.7.2 (working on upgrading that, but that?s a separate
    discussion.)

    To do so, I edited the configure file to point to the amqp-rabbitmq-0.8.json
    codegen spec, changed the Makefile to not build tools, examples and tests
    (those broke,) and tried to un it. According to my server however, its still
    trying to use 0-9-1 (Expected 0x000A000A method frame on channel 0, got
    frame type 65)

    Should this have worked? Am I maybe just installing this wrong? I cleaned
    out all librabbitmq.so files and symlinks, so I doubt its the problem, but I
    am looking for a sanity check here.
    There is no intention for this to work. There are AMQP
    version-dependent areas outside of the generated code. You can see the
    complete changes that were involved in the switch of the C client to
    0-9-1 at <http://hg.rabbitmq.com/rabbitmq-c/rev/168205522459>.

    With that said, it's probably not that difficult to revert the changes.
    If you don't care about the changes outside of librabbitmq/, and you
    discard the changes to code that wasn't generated back then but is now,
    it looks to me like there are only a couple of changes relevant (to
    librabbitmq/amqp_socket.c and librabbitmq/codegen.py).

    Perhaps we should be gratified that people are still running the 1.7.2
    broker in production. But I'd strongly recommend you upgrade at the
    earliest opportunity, both for the many enhancements and for the bug
    fixes. You do know that old 0-8 clients can still talk to the latest
    versions of the broker, so you don't have to upgrade your whole AMQP 0-8
    infrastructure at once?

    David

    --
    David Wragg
    Staff Engineer, RabbitMQ
    SpringSource, a division of VMware

    From bogus@does.not.exist.com Mon Feb 21 11:07:19 2011
    From: bogus@does.not.exist.com ()
    Date: Mon, 21 Feb 2011 11:07:19 -0000
    Subject: No subject
    Message-ID: <mailman.0.1299189742.14905.rabbitmq-discuss@lists.rabbitmq.com>

    ubuntu at rabbit2:~$ sudo rabbitmqctl list_queues name messages durable
    Listing queues ...
    jiggleflop 1 false
    ...done.
    ubuntu at rabbit2:~$ irb -rubygems -rbunny
    irb(main):001:0> (b=Bunny.new).start
    => :connected
    irb(main):002:0> b.queue('jiggleflop').pop[:payload]
    => "hello"
    irb(main):003:0> exit

    So far so good. Now, I stop rabbit back on the node where I created the queue:

    ubuntu at rabbit1:~$ sudo rabbitmqctl stop_app
    Stopping node rabbit at rabbit1 ...
    ...done.

    And look again from the other side:

    ubuntu at rabbit2:~$ sudo rabbitmqctl list_queues
    Listing queues ...
    ...done.
    ubuntu at rabbit2:~$

    OK, the queue's gone. It wasn't durable, so I should have the
    all-clear to declare and recreate it?

    ubuntu at rabbit2:~$ irb -rubygems -rbunny
    irb(main):001:0> (b=Bunny.new).start
    => :connected
    irb(main):002:0> b.queue('jiggleflop')
    Bunny::ForcedConnectionCloseError: Error Reply Code: 541
    Error Reply Text: INTERNAL_ERROR

    Not only can I not declare the queue, but even trying to do so has
    hosed my connection to Rabbit:

    irb(main):003:0> b.queue('flappydoodle')
    Bunny::ConnectionError: Not connected to server

    If I reconnect, I can declare a different queue:

    irb(main):004:0> (b=Bunny.new).start
    => :connected
    irb(main):005:0> b.queue('flappydoodle').publish("booya!")
    nil

    But still not the one that used to exist on the downed node:

    irb(main):006:0> b.queue('jiggleflop')
    Bunny::ForcedConnectionCloseError: Error Reply Code: 541
    Error Reply Text: INTERNAL_ERROR

    Below is the contents of rabbit at rabbit2.log corresponding to the above message.

    =ERROR REPORT==== 3-Mar-2011::16:30:43 ==** Generic server <0.31140.23> terminating
    ** Last message in was {init,false}
    ** When Server state == {q,{amqqueue,{resource,<<"/">>,queue,<<"jiggleflop">>},
    false,false,none,[],<0.31140.23>},
    none,false,rabbit_variable_queue,undefined,
    {[],[]},
    {[],[]},
    undefined,undefined,undefined,undefined,
    {state,fine,undefined},
    {dict,0,16,16,8,80,48,
    {[],[],[],[],[],[],[],[],[],[],[],[],[],[],
    [],[]},
    {{[],[],[],[],[],[],[],[],[],[],[],[],[],[],
    [],[]}}},
    undefined,undefined}
    ** Reason for termination =** {bad_return_value,
    {error,
    {badarg,
    [{erlang,is_process_alive,[<3039.17457.20>]},
    {rabbit_amqqueue,'-internal_declare/2-fun-3-',2},
    {rabbit_misc,'-execute_mnesia_tx_with_tail/1-fun-0-',1},
    {mnesia_tm,apply_fun,3},
    {mnesia_tm,execute_transaction,5},
    {worker_pool_worker,handle_call,3},
    {gen_server2,handle_msg,2},
    {proc_lib,wake_up,3}]}}}

    =ERROR REPORT==== 3-Mar-2011::16:30:43 ==** Generic server <0.31098.23> terminating
    ** Last message in was {'$gen_cast',
    {method,
    {'queue.declare',1,<<"jiggleflop">>,false,
    false,false,false,false,[]},
    none}}
    ** When Server state == {ch,running,1,<0.31095.23>,<0.31097.23>,undefined,
    #Fun<rabbit_channel_sup.0.123274458>,none,
    {set,0,16,16,8,80,48,
    {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],
    []},
    {{[],[],[],[],[],[],[],[],[],[],[],[],[],[],
    [],[]}}},
    1,
    {[],[]},
    {[],[]},
    {user,<<"guest">>,true,
    rabbit_auth_backend_internal,
    {internal_user,<<"guest">>,
    <<167,104,147,29,51,174,238,60,197,220,53,
    95,33,74,109,229,87,242,107,47>>,
    true}},
    <<"/">>,<<>>,
    {dict,0,16,16,8,80,48,
    {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],
    []},
    {{[],[],[],[],[],[],[],[],[],[],[],[],[],[],
    [],[]}}},
    {dict,0,16,16,8,80,48,
    {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],
    []},
    {{[],[],[],[],[],[],[],[],[],[],[],[],[],[],
    [],[]}}},
    <0.31093.23>,
    {state,fine,undefined},
    false,1,
    {0,nil},
    []}
    ** Reason for termination =** {{{bad_return_value,
    {error,
    {badarg,
    [{erlang,is_process_alive,[<3039.17457.20>]},
    {rabbit_amqqueue,'-internal_declare/2-fun-3-',2},
    {rabbit_misc,'-execute_mnesia_tx_with_tail/1-fun-0-',1},
    {mnesia_tm,apply_fun,3},
    {mnesia_tm,execute_transaction,5},
    {worker_pool_worker,handle_call,3},
    {gen_server2,handle_msg,2},
    {proc_lib,wake_up,3}]}}},
    {gen_server2,call,[<0.31140.23>,{init,false}]}},
    [{gen_server2,call,2},
    {rabbit_amqqueue,declare,5},
    {rabbit_channel,handle_method,3},
    {rabbit_channel,handle_cast,2},
    {gen_server2,handle_msg,2},
    {proc_lib,wake_up,3}]}

    =ERROR REPORT==== 3-Mar-2011::16:30:43 ==connection <0.31095.23> (running), channel 1 - error:
    {{{bad_return_value,
    {error,
    {badarg,
    [{erlang,is_process_alive,[<3039.17457.20>]},
    {rabbit_amqqueue,'-internal_declare/2-fun-3-',2},
    {rabbit_misc,'-execute_mnesia_tx_with_tail/1-fun-0-',1},
    {mnesia_tm,apply_fun,3},
    {mnesia_tm,execute_transaction,5},
    {worker_pool_worker,handle_call,3},
    {gen_server2,handle_msg,2},
    {proc_lib,wake_up,3}]}}},
    {gen_server2,call,[<0.31140.23>,{init,false}]}},
    [{gen_server2,call,2},
    {rabbit_amqqueue,declare,5},
    {rabbit_channel,handle_method,3},
    {rabbit_channel,handle_cast,2},
    {gen_server2,handle_msg,2},
    {proc_lib,wake_up,3}]}

    =WARNING REPORT==== 3-Mar-2011::16:30:43 ==Non-AMQP exit reason '{{{bad_return_value,
    {error,
    {badarg,
    [{erlang,is_process_alive,[<3039.17457.20>]},
    {rabbit_amqqueue,'-internal_declare/2-fun-3-',2},
    {rabbit_misc,
    '-execute_mnesia_tx_with_tail/1-fun-0-',1},
    {mnesia_tm,apply_fun,3},
    {mnesia_tm,execute_transaction,5},
    {worker_pool_worker,handle_call,3},
    {gen_server2,handle_msg,2},
    {proc_lib,wake_up,3}]}}},
    {gen_server2,call,[<0.31140.23>,{init,false}]}},
    [{gen_server2,call,2},
    {rabbit_amqqueue,declare,5},
    {rabbit_channel,handle_method,3},
    {rabbit_channel,handle_cast,2},
    {gen_server2,handle_msg,2},
    {proc_lib,wake_up,3}]}'

    =INFO REPORT==== 3-Mar-2011::16:30:43 ==closing TCP connection <0.31095.23> from 127.0.0.1:39949

    From bogus@does.not.exist.com Mon Feb 21 11:07:19 2011
    From: bogus@does.not.exist.com ()
    Date: Mon, 21 Feb 2011 11:07:19 -0000
    Subject: No subject
    Message-ID: <mailman.1.1299687041.14905.rabbitmq-discuss@lists.rabbitmq.com>

    d limit to the number of virtual hosts that can be configured within a RabbitMQ cluster, save available disk and memory resources.

    Is this true for a crazy number of virtual hosts, say 10,000? And there's no performance cost for this? Can anyone offer a success story?

    Thanks,
    Brian
    From bogus@does.not.exist.com Mon Feb 21 11:07:19 2011
    From: bogus@does.not.exist.com ()
    Date: Mon, 21 Feb 2011 11:07:19 -0000
    Subject: No subject
    Message-ID: <mailman.2.1299687112.14905.rabbitmq-discuss@lists.rabbitmq.com>

    d limit to the number of virtual hosts that can be configured within a RabbitMQ cluster, save available disk and memory resources.

    Is this true for a crazy number of virtual hosts, say 10,000? And there's no performance cost for this? Can anyone offer a success story?

    Thanks,
    Brian


    From bogus@does.not.exist.com Mon Feb 21 11:07:19 2011
    From: bogus@does.not.exist.com ()
    Date: Mon, 21 Feb 2011 11:07:19 -0000
    Subject: No subject
    Message-ID: <mailman.3.1299764185.14905.rabbitmq-discuss@lists.rabbitmq.com>

    exclusive queues, is that correct? I've tried creating a named,
    durable queue for all consumers to read from, but in this case the
    message can only be consumed once.

    Is there something I'm missing?

    Thank you.
    On Thu, Mar 3, 2011 at 22:07, Michael Bridgen wrote:
    Fabio,

    Aces, glad to hear it's working for you thus far.

    On this:
    Just a final question: the previous README file on github said
    something about including the plugin on the main RabbitMQ code, but I
    figured this had been written some time ago because it mentioned
    version 1.7.1. Is this still in your (and RabbitMQ developers) plans?
    Best regards.
    -- I was referring to the exchange plugin mechanism overall, on which I was
    finishing (largely other people's!) work at the time.  That mechanism has
    been in mainstream rabbitmq since then, and has changed a bit, but is pretty
    stable.

    The Last Value Caching exchange will likely stay a plugin for the
    foreseeable future, rather than being baked into rabbitmq-server.  But if
    you follow this list you'll know this is not the last word ..

    Michael
    Oh.  Looks like github's upload and download system is totally broken.
    (I've
    now tried to upload it a few times).

    I've attached the ez so it can be stopped by mail filters instead.
    Hi Michael.
    Sorry for the extra trouble.

    I've now rebooted my RabbitMQ server and run a few basic tests and
    everything seems to be working as expected. Thank you again for all
    your help and your work on the plugin. I'll keep building my test
    scenarios and I'll let you know if something else comes up.

    Just a final question: the previous README file on github said
    something about including the plugin on the main RabbitMQ code, but I
    figured this had been written some time ago because it mentioned
    version 1.7.1. Is this still in your (and RabbitMQ developers) plans?
    Best regards.
    From bogus@does.not.exist.com Mon Feb 21 11:07:19 2011
    From: bogus@does.not.exist.com ()
    Date: Mon, 21 Feb 2011 11:07:19 -0000
    Subject: No subject
    Message-ID: <mailman.4.1299865805.14905.rabbitmq-discuss@lists.rabbitmq.com>

    to /etc/rabbitmq/rabbitmq.conf.d. Any chance when this config file is done
    away with a .d type implementation can be made to replace it?

    -Brian

    --20cf307ca1dc16a0bb049e388ee9
    Content-Type: text/html; charset=ISO-8859-1
    Content-Transfer-Encoding: quoted-printable

    Many thanks Simon,<div><br></div><div>That did the trick!<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
    <br>
    Finally, can I ask what benefit you&#39;re getting from using the old configuration file? We&#39;d like to do away with it at some point, and it would be nice to be sure we weren&#39;t breaking anything :)<br>
    <br></blockquote><div><br></div><div>Yes, it&#39;s due to the modularity it provides.  Here is my rabbitmq.conf file:</div><div> </div></div><div>for CONFIGFILE in `ls /etc/rabbitmq/rabbitmq.conf.d |sort -r`; do</div><div>
    . /etc/rabbitmq/rabbitmq.conf.d/$CONFIGFILE</div><div>done</div></div><div><br></div><div>From there each plugin package can just install its snippet to  /etc/rabbitmq/rabbitmq.conf.d. Any chance when this config file is done away with a .d type implementation can be made to replace it?</div>
    <div><br></div><div>-Brian</div><div><br></div>

    --20cf307ca1dc16a0bb049e388ee9--

    From bogus@does.not.exist.com Mon Feb 21 11:07:19 2011
    From: bogus@does.not.exist.com ()
    Date: Mon, 21 Feb 2011 11:07:19 -0000
    Subject: No subject
    Message-ID: <mailman.5.1300114914.14905.rabbitmq-discuss@lists.rabbitmq.com>

    Basically the system that consumed messages, for some
    reason, was too slow. That, obviously, put a lot of stress
    on RabbitMQ, and as it was before rabbit 2.0, at some point
    Rabbit just died due to out-of-memory situation.

    Reddit guys were unhappy to see Rabbit go down, but
    in fact Rabbit was not the source of their problems.
    It was just a side-effect of something else misbehaving.

    Cheers,
    Marek
    On Fri, Mar 11, 2011 at 19:30, Marcel Meyer wrote:
    Great! Do you know whether this was documented as some anti-pattern? Is
    there more about the specific issues they faced?
    On Fri, Mar 11, 2011 at 12:13 PM, Alexis Richardson wrote:

    Hi Marcel

    Yes, I believe so.   Matthew went to see them.  As I recall the main
    issues were actually not with Rabbit, but some of how they had used
    messaging was worth discussing.

    alexis


    On Fri, Mar 11, 2011 at 5:07 PM, Marcel Meyer <marcel.meyer at gmail.com>
    wrote:
    Hi there Rabbit Community,
    I am researching queues and found this thread about reddit's gripes
    (http://www.reddit.com/tb/c2spc) and noticed that RabbitMQ Support
    reached
    out to them.
    Were there issues resolved? They upgraded ERTS as a "stopgap" fix, but
    wanted to yank the technology all together. Did they?
    Regards,
    Marcel
    _______________________________________________
    rabbitmq-discuss mailing list
    rabbitmq-discuss at lists.rabbitmq.com
    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
    From bogus@does.not.exist.com Mon Feb 21 11:07:19 2011
    From: bogus@does.not.exist.com ()
    Date: Mon, 21 Feb 2011 11:07:19 -0000
    Subject: No subject
    Message-ID: <mailman.6.1300392174.14905.rabbitmq-discuss@lists.rabbitmq.com>

    exclusive queues, is that correct? I&#39;ve tried creating a named,<br>
    durable queue for all consumers to read from, but in this case the<br>
    message can only be consumed once.<br>
    <br>
    Is there something I&#39;m missing?<br>
    <br>
    Thank you.<br>
    <div><div></div><div class="h5"><br>
    On Thu, Mar 3, 2011 at 22:07, Michael Bridgen &lt;<a href="mailto:mikeb at rabbitmq.com">mikeb at rabbitmq.com</a>&gt; wrote:<br>
    &gt; Fabio,<br>
    &gt;<br>
    &gt; Aces, glad to hear it&#39;s working for you thus far.<br>
    &gt;<br>
    &gt; On this:<br>
    &gt;<br>
    &gt;&gt; Just a final question: the previous README file on github said<br>
    &gt;&gt; something about including the plugin on the main RabbitMQ code, but I<br>
    &gt;&gt; figured this had been written some time ago because it mentioned<br>
    &gt;&gt; version 1.7.1. Is this still in your (and RabbitMQ developers) plans?<br>
    &gt;&gt; Best regards.<br>
    &gt;<br>
    &gt;  -- I was referring to the exchange plugin mechanism overall, on which I was<br>
    &gt; finishing (largely other people&#39;s!) work at the time.  That mechanism has<br>
    &gt; been in mainstream rabbitmq since then, and has changed a bit, but is pretty<br>
    &gt; stable.<br>
    &gt;<br>
    &gt; The Last Value Caching exchange will likely stay a plugin for the<br>
    &gt; foreseeable future, rather than being baked into rabbitmq-server.  But if<br>
    &gt; you follow this list you&#39;ll know this is not the last word ..<br>
    &gt;<br>
    &gt; Michael<br>
    &gt;<br>
    &gt;&gt;&gt; Oh.  Looks like github&#39;s upload and download system is totally broken.<br>
    &gt;&gt;&gt; (I&#39;ve<br>
    &gt;&gt;&gt; now tried to upload it a few times).<br>
    &gt;&gt;&gt;<br>
    &gt;&gt;&gt; I&#39;ve attached the ez so it can be stopped by mail filters instead.<br>
    &gt;&gt;<br>
    &gt;&gt; Hi Michael.<br>
    &gt;&gt; Sorry for the extra trouble.<br>
    &gt;&gt;<br>
    &gt;&gt; I&#39;ve now rebooted my RabbitMQ server and run a few basic tests and<br>
    &gt;&gt; everything seems to be working as expected. Thank you again for all<br>
    &gt;&gt; your help and your work on the plugin. I&#39;ll keep building my test<br>
    &gt;&gt; scenarios and I&#39;ll let you know if something else comes up.<br>
    &gt;&gt;<br>
    &gt;&gt; Just a final question: the previous README file on github said<br>
    &gt;&gt; something about including the plugin on the main RabbitMQ code, but I<br>
    &gt;&gt; figured this had been written some time ago because it mentioned<br>
    &gt;&gt; version 1.7.1. Is this still in your (and RabbitMQ developers) plans?<br>
    &gt;&gt; Best regards.<br>
    &gt;<br>
    &gt;<br>
    </div></div></blockquote></div><br></div>

    --0016e65ae75888dc14049eb30ad3--

    From bogus@does.not.exist.com Mon Feb 21 11:07:19 2011
    From: bogus@does.not.exist.com ()
    Date: Mon, 21 Feb 2011 11:07:19 -0000
    Subject: No subject
    Message-ID: <mailman.7.1300995694.14905.rabbitmq-discuss@lists.rabbitmq.com>

    "There usually is a few weeks lag between a new release and its
    appearance in the central Maven repository. Be patient."

    ;-)

    now to the mailing list too...
    On Thu, Mar 24, 2011 at 8:34 PM, Jon Brisbin wrote:
    Just wondering if the 2.4.0 Java jars are in a Maven repo anywhere? I don't see them in central but didn't know if they were on the SpringSource release repo or something?

    I'm working on updating my Log4J appender to work with the latest stuff...

    Thanks!

    Jon Brisbin

    http://jbrisbin.com
    Twitter: @j_brisbin


    _______________________________________________
    rabbitmq-discuss mailing list
    rabbitmq-discuss at lists.rabbitmq.com
    https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
    From bogus@does.not.exist.com Mon Feb 21 11:07:19 2011
    From: bogus@does.not.exist.com ()
    Date: Mon, 21 Feb 2011 11:07:19 -0000
    Subject: No subject
    Message-ID: <mailman.8.1301054764.14905.rabbitmq-discuss@lists.rabbitmq.com>

    their focus is the ability to deliver a message immediately and report an
    error if they cannot contact the server.

    Implementing messaging from a M2M platform, there will be times when there
    is no communication between the client and the server...but the application
    may still want to submit messages which should be queued until such time as
    the "local queue" so to speak can contact the server and delivery the
    messages.

    In summary, leaving the "retry/retransmission" of message to the
    messaging infrastructure...rather then have the application monitor/poll
    connectivity to the server.

    Is something like this possible?


    Thanks
    Bruce

    --90e6ba6e8be400adb3049f4d6a11
    Content-Type: text/html; charset=ISO-8859-1
    Content-Transfer-Encoding: quoted-printable

    Hi<div><br></div><div>I was wondering what others are doing with regards to &quot;queuing&quot; local messages for deliver when the network is available.</div><div><br></div><div>From my limited experience playing to &quot;rabbitmq-c client&quot; and Python &quot;pika&quot;, their focus is the ability to deliver a message immediately and report an error if they cannot contact the server. </div>
    <div><br></div><div>Implementing messaging from a M2M platform, there will be times when there is no communication between the client and the server...but the application may still want to submit messages which should be queued until such time as the &quot;local queue&quot; so to speak can contact the server and delivery the messages. </div>
    <div><br></div><div>In summary, leaving the &quot;retry/retransmission&quot; of message to the messaging infrastructure...rather then have the application monitor/poll connectivity to the server.</div><div><br></div><div>
    Is something like this possible?</div><div><br></div><div><br></div><div>Thanks</div><div>Bruce</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>

    --90e6ba6e8be400adb3049f4d6a11--

    From bogus@does.not.exist.com Mon Feb 21 11:07:19 2011
    From: bogus@does.not.exist.com ()
    Date: Mon, 21 Feb 2011 11:07:19 -0000
    Subject: No subject
    Message-ID: <mailman.9.1301348035.14905.rabbitmq-discuss@lists.rabbitmq.com>

    reporting by default the maximum file size. You want "ulimit -n"

    Matthew
  • Pieter de Zwart at Mar 1, 2011 at 5:51 pm
    So, I am a mercurial n00b. IS there any chance you can point me to two URLs,
    one for the rabbitmq-c repo, one for the rabbitmq-codegen repo, that I can
    use to generate an 0-8 client library, so that I can then upgrade to 2.3.1.
    The combination of:
    // librabbitmq-0.1-amqp_0_8 tag
    $ hg clone http://hg.rabbitmq.com/rabbitmq-c/rev/ce1eaceaee94
    // rabbitmq_v1_7_2
    $ hg clone http://hg.rabbitmq.com/rabbitmq-codegen/rev/c7c5876a05bb

    Yields what seems to be a 0-9-1 client, since I used the steps below to try
    to compile it, and had to move the 0-9-1 json spec out of the way.

    Thanks for you help.
    Pieter

    On 2/28/11 2:26 PM, "David Wragg" wrote:

    Hi Pieter,

    Pieter de Zwart <pdezwart at rubiconproject.com> writes:
    I sincerely hope that this is stupid question with an easy answer. I am
    trying to build a somewhat recent version of the rabbitmq-c library to use
    with the PHP extension, but that uses the 0-8 protocol since our production
    broker is still 1.7.2 (working on upgrading that, but that?s a separate
    discussion.)

    To do so, I edited the configure file to point to the amqp-rabbitmq-0.8.json
    codegen spec, changed the Makefile to not build tools, examples and tests
    (those broke,) and tried to un it. According to my server however, its still
    trying to use 0-9-1 (Expected 0x000A000A method frame on channel 0, got
    frame type 65)

    Should this have worked? Am I maybe just installing this wrong? I cleaned
    out all librabbitmq.so files and symlinks, so I doubt its the problem, but I
    am looking for a sanity check here.
    There is no intention for this to work. There are AMQP
    version-dependent areas outside of the generated code. You can see the
    complete changes that were involved in the switch of the C client to
    0-9-1 at <http://hg.rabbitmq.com/rabbitmq-c/rev/168205522459>.

    With that said, it's probably not that difficult to revert the changes.
    If you don't care about the changes outside of librabbitmq/, and you
    discard the changes to code that wasn't generated back then but is now,
    it looks to me like there are only a couple of changes relevant (to
    librabbitmq/amqp_socket.c and librabbitmq/codegen.py).

    Perhaps we should be gratified that people are still running the 1.7.2
    broker in production. But I'd strongly recommend you upgrade at the
    earliest opportunity, both for the many enhancements and for the bug
    fixes. You do know that old 0-8 clients can still talk to the latest
    versions of the broker, so you don't have to upgrade your whole AMQP 0-8
    infrastructure at once?

    David
  • Pieter de Zwart at Mar 1, 2011 at 6:29 pm
    Alright, I finally found an old version of the binary that works. I am going
    to get this up and running and then start prepping for the the update to
    2.x.

    Thanks for the help David, sorry to be a PITA.

    me

    On 3/1/11 9:51 AM, "Pieter de Zwart" wrote:

    So, I am a mercurial n00b. IS there any chance you can point me to two
    URLs,
    one for the rabbitmq-c repo, one for the rabbitmq-codegen repo, that I
    can
    use to generate an 0-8 client library, so that I can then upgrade to
    2.3.1.
    The combination of:
    // librabbitmq-0.1-amqp_0_8 tag
    $ hg clone
    // rabbitmq_v1_7_2
    $ hg
    clone http://hg.rabbitmq.com/rabbitmq-codegen/rev/c7c5876a05bb
    Yields what
    seems to be a 0-9-1 client, since I used the steps below to try
    to compile it,
    and had to move the 0-9-1 json spec out of the way.
    Thanks for you
    help.
    Pieter

    On 2/28/11 2:26 PM, "David Wragg" wrote:

    Hi Pieter,

    Pieter de Zwart <pdezwart at rubiconproject.com>
    writes:
    I sincerely hope that this is stupid question with an easy answer. I am
    trying to build a somewhat recent version of the rabbitmq-c library to use
    with the PHP extension, but that uses the 0-8 protocol since our
    production
    broker is still 1.7.2 (working on upgrading that, but that?s a separate
    discussion.)

    To do so, I edited the configure file to point
    to the amqp-rabbitmq-0.8.json
    codegen spec, changed the Makefile to not
    build tools, examples and tests
    (those broke,) and tried to un it.
    According to my server however, its still
    trying to use 0-9-1 (Expected
    0x000A000A method frame on channel 0, got
    frame type 65)

    Should this
    have worked? Am I maybe just installing this wrong? I cleaned
    out all
    librabbitmq.so files and symlinks, so I doubt its the problem, but I
    am
    looking for a sanity check here.

    There is no intention for this to work.
    There are AMQP
    version-dependent areas outside of the generated code. You
    can see the
    complete changes that were involved in the switch of the C
    client to
    0-9-1 at <http://hg.rabbitmq.com/rabbitmq-c/rev/168205522459>.


    With that said, it's probably not that difficult to revert the changes.

    If you don't care about the changes outside of librabbitmq/, and you
    discard
    the changes to code that wasn't generated back then but is now,
    it looks to
    me like there are only a couple of changes relevant (to

    librabbitmq/amqp_socket.c and librabbitmq/codegen.py).

    Perhaps we should
    be gratified that people are still running the 1.7.2
    broker in production.
    But I'd strongly recommend you upgrade at the
    earliest opportunity, both for
    the many enhancements and for the bug
    fixes. You do know that old 0-8
    clients can still talk to the latest
    versions of the broker, so you don't
    have to upgrade your whole AMQP 0-8
    infrastructure at once?


    David

    _______________________________________________
    rabbitmq-discuss
    mailing
    list
    rabbitmq-discuss at lists.rabbitmq.com
    https://lists.rabbitmq.com/cgi-bin/ma
    ilman/listinfo/rabbitmq-discuss

    --
    the rubicon project

    PIETER DE ZWART | LEAD, INTERFACES TEAM
    ??? P 310 207 0272 | x224
    ??? C 408 666 4443
    ??? F 323 466 7119


    1925 S. BUNDY DRIVE
    LOS ANGELES, CALIFORNIA 90025

    WWW.RUBICONPROJECT.COM <http://www.rubiconproject.com/>


    ?MOST INNOVATIVE COMPANY? - AMERICAN BUSINESS AWARDS ?10
    REVV IS OPTIMIZING 1.4 MILLION ADS PER MINUTE
  • David Wragg at Mar 2, 2011 at 5:09 pm
    Hi Pieter,

    Glad to hear from your other email that your were able to solve the
    problem.

    But just to avoid confusion for the record:

    Pieter de Zwart <pdezwart at rubiconproject.com> writes:
    So, I am a mercurial n00b. IS there any chance you can point me to two URLs,
    one for the rabbitmq-c repo, one for the rabbitmq-codegen repo, that I can
    use to generate an 0-8 client library, so that I can then upgrade to 2.3.1.
    The combination of:
    // librabbitmq-0.1-amqp_0_8 tag
    $ hg clone http://hg.rabbitmq.com/rabbitmq-c/rev/ce1eaceaee94
    // rabbitmq_v1_7_2
    $ hg clone http://hg.rabbitmq.com/rabbitmq-codegen/rev/c7c5876a05bb

    Yields what seems to be a 0-9-1 client, since I used the steps below to try
    to compile it, and had to move the 0-9-1 json spec out of the way.
    There's no "out of the box" way to get the current librabbitmq with 0-8
    support.

    You can build the last version of librabbitmq that supported 0-8 by
    doing:

    $ hg clone http://hg.rabbitmq.com/rabbitmq-c/
    $ hg clone http://hg.rabbitmq.com/rabbitmq-codegen/
    $ cd rabbitmq-c
    $ hg update -C amqp_0_8
    $ autoreconf -i && ./configure && make

    But you will find that there are small API differences between that and
    the current librabbitmq.

    As I suggested in my previous email, refitting the current librabbitmq
    with 0-8 support looks reasonably straightforward, but it would involve
    rolling your sleeves up and editing the code.

    David

    --
    David Wragg
    Staff Engineer, RabbitMQ
    SpringSource, a division of VMware

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedFeb 28, '11 at 9:15p
activeMar 2, '11 at 5:09p
posts5
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Pieter de Zwart: 3 posts David Wragg: 2 posts

People

Translate

site design / logo © 2022 Grokbase