From rnickel at scea.com Sat May 1 00:01:43 2010 From: rnickel at scea.com (Robert Nickel) Date: Fri, 30 Apr 2010 16:01:43 -0700 Subject: [rabbitmq-discuss] Really bizarre startup issue... Message-ID: <20100430230143.GR7977@coinelement.989studios.com> First, thank you. I have two hosts (sdcloudsh01 and sdcloudsh02) with the following specifications: CentOS 5.1 erlang R13B03 rabbitmq-server 1.7.2 selinux is disabled Both are identically configured using puppet. 02 works fine but 01 has interesting startup issues. On sdcloudsh01, contents of /etc/rabbitmq files: rabbitmq.conf: NODENAME=regsvc at sdcloudsh01 rabbitmq.config: [ {rabbit, []} ]. rabbitmq_cluster.config: [ 'regsvc at sdcloudsh01','regsvc at sdcloudsh02' ]. When starting the rabbitmq server using /sbin/service rabbitmq-server start, the service fails and the following outputs are in /var/log/rabbitmq/startup_err and log: _log: Starting all nodes... Starting node regsvc at sdcloudsh01... _err: Error: {node_start_failed,normal} When the node fails, there is not erl_dump file to be found and the epmd process is running. After a bunch of troubleshooting, I noticed that if I strace the above command, everything works fine: strace -f /sbin/service rabbitmq-server start Terminating the strace leaves the rabbit server running happily. I have no idea what this could be. Any pointers are greatly appreciated. Thank you! --Robert From tjgillies at gmail.com Sun May 2 12:55:52 2010 From: tjgillies at gmail.com (tyler gillies) Date: Sun, 2 May 2010 04:55:52 -0700 Subject: [rabbitmq-discuss] binding Message-ID: how do you protect a someone from binding a queue you've already bound? -- Everyone Loves Tea http://www.everyonelovestea.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100502/d854247d/attachment.htm From lists at zopyx.com Sun May 2 17:59:09 2010 From: lists at zopyx.com (Andreas Jung) Date: Sun, 02 May 2010 18:59:09 +0200 Subject: [rabbitmq-discuss] [MacOSX]Can't set long node name!\nPlease check your configuration Message-ID: <4BDDAF5D.5060204@zopyx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Starting RabbitMQ 1.7.2 on Snow Leopard now gives me this: ajung at suxmac2:~/sandboxes/occ bin/rabbitmq-server {error_logger,{{2010,5,2},{18,57,44}},"Can't set long node name!\nPlease check your configuration\n",[]} {error_logger,{{2010,5,2},{18,57,44}},crash_report,[[{initial_call,{net_kernel,init,['Argument__1']}},{pid,<0.21.0>},{registered_name,[]},{error_info,{exit,{error,badarg},[{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}},{ancestors,[net_sup,kernel_sup,<0.10.0>]},{messages,[]},{links,[<0.18.0>]},{dictionary,[{longnames,true}]},{trap_exit,true},{status,running},{heap_size,377},{stack_size,24},{reductions,749}],[]]} {error_logger,{{2010,5,2},{18,57,44}},supervisor_report,[{supervisor,{local,net_sup}},{errorContext,start_error},{reason,{'EXIT',nodistribution}},{offender,[{pid,undefined},{name,net_kernel},{mfa,{net_kernel,start_link,[[rabbit,longnames]]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]}]} {error_logger,{{2010,5,2},{18,57,44}},supervisor_report,[{supervisor,{local,kernel_sup}},{errorContext,start_error},{reason,shutdown},{offender,[{pid,undefined},{name,net_sup},{mfa,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]}]} {error_logger,{{2010,5,2},{18,57,44}},std_info,[{application,kernel},{exited,{shutdown,{kernel,start,[normal,[]]}}},{type,permanent}]} {"Kernel pid terminated",application_controller,"{application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}"} Crash dump was written to: erl_crash.dump Kernel pid terminated (application_controller) ({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}) The start script is as follows: ajung at suxmac2:~/sandboxes/occ cat bin/rabbitmq-server #!/bin/sh NODENAME=rabbit NODE_IP_ADDRESS=0.0.0.0 NODE_PORT=5672 SERVER_ERL_ARGS="+K true +A30 -kernel inet_default_listen_options [{nodelay,true},{sndbuf,16384},{recbuf,4096}] -kernel inet_default_connect_options [{nodelay,true}]" CLUSTER_CONFIG_FILE=/Users/ajung/sandboxes/occ/etc/rabbitmq_cluster.config LOG_BASE=/Users/ajung/sandboxes/occ/var/log/rabbitmq MNESIA_BASE=/Users/ajung/sandboxes/occ/var SERVER_START_ARGS= [ -f /Users/ajung/sandboxes/occ/etc/rabbitmq.conf ] && . /Users/ajung/sandboxes/occ/etc/rabbitmq.conf [ "x" = "x$RABBITMQ_NODENAME" ] && RABBITMQ_NODENAME=${NODENAME} [ "x" = "x$RABBITMQ_NODE_IP_ADDRESS" ] && RABBITMQ_NODE_IP_ADDRESS=${NODE_IP_ADDRESS} [ "x" = "x$RABBITMQ_NODE_PORT" ] && RABBITMQ_NODE_PORT=${NODE_PORT} [ "x" = "x$RABBITMQ_SERVER_ERL_ARGS" ] && RABBITMQ_SERVER_ERL_ARGS=${SERVER_ERL_ARGS} [ "x" = "x$RABBITMQ_CLUSTER_CONFIG_FILE" ] && RABBITMQ_CLUSTER_CONFIG_FILE=${CLUSTER_CONFIG_FILE} [ "x" = "x$RABBITMQ_LOG_BASE" ] && RABBITMQ_LOG_BASE=${LOG_BASE} [ "x" = "x$RABBITMQ_MNESIA_BASE" ] && RABBITMQ_MNESIA_BASE=${MNESIA_BASE} [ "x" = "x$RABBITMQ_SERVER_START_ARGS" ] && RABBITMQ_SERVER_START_ARGS=${SERVER_START_ARGS} [ "x" = "x$RABBITMQ_MNESIA_DIR" ] && RABBITMQ_MNESIA_DIR=${MNESIA_DIR} [ "x" = "x$RABBITMQ_MNESIA_DIR" ] && RABBITMQ_MNESIA_DIR=${RABBITMQ_MNESIA_BASE}/${RABBITMQ_NODENAME} ## Log rotation [ "x" = "x$RABBITMQ_LOGS" ] && RABBITMQ_LOGS=${LOGS} [ "x" = "x$RABBITMQ_LOGS" ] && RABBITMQ_LOGS="${RABBITMQ_LOG_BASE}/${RABBITMQ_NODENAME}.log" [ "x" = "x$RABBITMQ_SASL_LOGS" ] && RABBITMQ_SASL_LOGS=${SASL_LOGS} [ "x" = "x$RABBITMQ_SASL_LOGS" ] && RABBITMQ_SASL_LOGS="${RABBITMQ_LOG_BASE}/${RABBITMQ_NODENAME}-sasl.log" [ "x" = "x$RABBITMQ_BACKUP_EXTENSION" ] && RABBITMQ_BACKUP_EXTENSION=${BACKUP_EXTENSION} [ "x" = "x$RABBITMQ_BACKUP_EXTENSION" ] && RABBITMQ_BACKUP_EXTENSION=".1" [ -f "${RABBITMQ_LOGS}" ] && cat "${RABBITMQ_LOGS}" >> "${RABBITMQ_LOGS}${RABBITMQ_BACKUP_EXTENSION}" [ -f "${RABBITMQ_SASL_LOGS}" ] && cat "${RABBITMQ_SASL_LOGS}" >> "${RABBITMQ_SASL_LOGS}${RABBITMQ_BACKUP_EXTENSION}" if [ -f "$RABBITMQ_CLUSTER_CONFIG_FILE" ]; then RABBITMQ_CLUSTER_CONFIG_OPTION="-rabbit cluster_config "$RABBITMQ_CLUSTER_CONFIG_FILE"" else RABBITMQ_CLUSTER_CONFIG_OPTION="" fi RABBITMQ_START_RABBIT= [ "x" = "x$RABBITMQ_NODE_ONLY" ] && RABBITMQ_START_RABBIT='-noinput -s rabbit' # we need to turn off path expansion because some of the vars, notably # RABBITMQ_SERVER_ERL_ARGS, contain terms that look like globs and # there is no other way of preventing their expansion. set -f exec /usr/bin/erl \ -pa "/Users/ajung/sandboxes/occ/parts/rabbitmq/ebin" \ ${RABBITMQ_START_RABBIT} \ -name ${RABBITMQ_NODENAME} \ -boot start_sasl \ +W w \ ${RABBITMQ_SERVER_ERL_ARGS} \ -rabbit tcp_listeners '[{"'${RABBITMQ_NODE_IP_ADDRESS}'", '${RABBITMQ_NODE_PORT}'}]' \ -sasl errlog_type error \ -kernel error_logger '{file,"'${RABBITMQ_LOGS}'"}' \ -sasl sasl_error_logger '{file,"'${RABBITMQ_SASL_LOGS}'"}' \ -os_mon start_cpu_sup true \ -os_mon start_disksup false \ -os_mon start_memsup false \ -os_mon start_os_sup false \ -os_mon memsup_system_only true \ -os_mon system_memory_high_watermark 0.95 \ -mnesia dir "\"${RABBITMQ_MNESIA_DIR}\"" \ ${RABBITMQ_CLUSTER_CONFIG_OPTION} \ ${RABBITMQ_SERVER_START_ARGS} \ "$@" Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvdr10ACgkQCJIWIbr9KYyJZgCgr06rg3lukCrroKaYQk25vsdN OtAAn1/vNfOcppwLsJyc6c6s+ISZhjpO =Ku+i -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: lists.vcf Type: text/x-vcard Size: 316 bytes Desc: not available Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100502/38a9aa88/attachment.vcf From jasonjwwilliams at gmail.com Sun May 2 18:13:32 2010 From: jasonjwwilliams at gmail.com (Jason J. W. Williams) Date: Sun, 2 May 2010 11:13:32 -0600 Subject: [rabbitmq-discuss] binding In-Reply-To: References: Message-ID: Have to make a private queue. Sent via iPhone Is your e-mail Premiere? On May 2, 2010, at 5:55, tyler gillies wrote: > how do you protect a someone from binding a queue you've already > bound? > > -- > Everyone Loves Tea > http://www.everyonelovestea.com > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100502/8c7fd266/attachment.htm From matthias at rabbitmq.com Sun May 2 19:17:35 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Sun, 02 May 2010 19:17:35 +0100 Subject: [rabbitmq-discuss] [MacOSX]Can't set long node name!\nPlease check your configuration In-Reply-To: <4BDDAF5D.5060204@zopyx.com> References: <4BDDAF5D.5060204@zopyx.com> Message-ID: <4BDDC1BF.7080102@rabbitmq.com> Andreas, Andreas Jung wrote: > Starting RabbitMQ 1.7.2 on Snow Leopard now gives me this: > > ajung at suxmac2:~/sandboxes/occ bin/rabbitmq-server > {error_logger,{{2010,5,2},{18,57,44}},"Can't set long node name!\nPlease > check your configuration\n",[]} > [...] > The start script is as follows: [...] That startup script has been modified in quite a few places from what we ship with rabbitmq. So, rather unsurprisingly, it doesn't work ;) Specifically, the error you are seeing is due to ... > -name ${RABBITMQ_NODENAME} \ having been changed from "-sname ...". As a result the node name needs to be set to a fully qualified name (e.g. rabbit at host.domain.com). Regards, Matthias. From mlin at admob.com Mon May 3 19:25:15 2010 From: mlin at admob.com (Mark Lin) Date: Mon, 3 May 2010 11:25:15 -0700 Subject: [rabbitmq-discuss] shovel terminating, channel.flow_ok? Message-ID: <3E976A21-45BF-4E72-8F75-87D6C66B93FF@admob.com> Getting the following errors when shovel terminates. Once this starts to happen, shovel would just keep retrying connection until rabbit-server quits. Has anyone seen this? Thanks, mlin =WARNING REPORT==== 1-May-2010::01:06:12 === Channel 1 closing: server sent error {amqp_error,channel_error, "expected 'channel.open'", 'channel.flow_ok'} =ERROR REPORT==== 1-May-2010::01:06:12 === ** Generic server <0.23822.0> terminating ** Last message in was {channel_exit,1, {amqp_error,channel_error, "expected 'channel.open'",'channel.flow_ok'}} ** When Server state == {c_state,1,<0.23821.0>,<0.23823.0>,<0.23823.0>, direct, {[{{<0.23821.0>,#Ref<0.0.104.106352>}, {'channel.open',<<>>}, none}], []}, {[],[]}, {dict,0,16,16,8,80,48, {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[], []}, {{[],[],[],[],[],[],[],[],[],[],[],[],[],[], [],[]}}}, false,none,true,none, {dict,0,16,16,8,80,48, {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[], []}, {{[],[],[],[],[],[],[],[],[],[],[],[],[],[], [],[]}}}} ** Reason for termination == ** {server_initiated_close,504,"expected 'channel.open'"} =ERROR REPORT==== 1-May-2010::01:06:12 === ** Generic server <0.23821.0> terminating ** Last message in was {command,{open_channel,none}} ** When Server state == {dc_state, {amqp_params,<<"guest">>,<<"guest">>,<<"/">>, undefined,5672,0,0,0,none,[]}, false, [{<<"product">>,longstr,<<"RabbitMQ">>}, {<<"version">>,longstr,<<"1.7.2">>}, {<<"platform">>,longstr,<<"Erlang/OTP">>}, {<<"copyright">>,longstr, <<"Copyright (C) 2007-2010 LShift Ltd., Cohesive Financial Technologies L LC., and Rabbit Technologies Ltd.">>}, {<<"information">>,longstr, <<"Licensed under the MPL. See http://www.rabbitmq.com/">>}], {{0,nil}, {dict,0,16,16,8,80,48, {[],[],[],[],[],[],[],[],[],[],[],[],[],[], [],[]}, {{[],[],[],[],[],[],[],[],[],[],[],[],[],[], [],[]}}}}} ** Reason for termination == ** {{server_initiated_close,504,"expected 'channel.open'"}, {gen_server,call, [<0.23822.0>,{call,{'channel.open',<<>>},none},infinity]}} From daniel at rimspace.net Tue May 4 11:29:59 2010 From: daniel at rimspace.net (Daniel Pittman) Date: Tue, 04 May 2010 20:29:59 +1000 Subject: [rabbitmq-discuss] RabbitMQ and a two-site deployment connected via WAN. Message-ID: <874oioot7c.fsf@rimspace.net> G'day. I am looking at deploying RabbitMQ to provide messaging services inside, and between, our two sites using both the AMQP and STOMP interfaces. As far as I can tell we have two choices for deploying this: 1. Use an Erlang cluster over the WAN, as a single instance of RabbitMQ 2. Use the 'shovel' extension to push messages between two distinct RabbitMQ clusters, one at each site. The only real discussion I can find about this is from 35 weeks ago, where the comment was that using shovel might better handle a situation where the WAN was down, but that it was not production ready. My impression is that, generally speaking, we are likely to be best served by using an Erlang cluster over the network: the WAN is fairly reliable, and will soon have two redundant paths, further reducing the risk of a split cluster. Am I correct in my understanding that using RabbitMQ in this way means: Clients will connect to their local RabbitMQ node, and when they create a queue it will exist only on that specific node. Erlang will route messages to the correct node, either inside the site or over the WAN as required. Erlang and/or RabbitMQ will ensure that only one copy of a message traverses the WAN, even if there are multiple recipients at the remote site. Erlang and RabbitMQ will recover from a brief interruption of clustering, such as a reboot of the server at one site, without manual intervention. Further, is there anything useful that I can read about Erlang and RabbitMQ WAN clustering? My research, to date, has not given me much to learn from, which makes me wonder what hidden complexity I might be risking... Daniel -- ? Daniel Pittman ? daniel at rimspace.net ? +61 401 155 707 ? made with 100 percent post-consumer electrons From simon at rabbitmq.com Tue May 4 13:56:08 2010 From: simon at rabbitmq.com (Simon MacMullen) Date: Tue, 04 May 2010 13:56:08 +0100 Subject: [rabbitmq-discuss] RabbitMQ and a two-site deployment connected via WAN. In-Reply-To: <874oioot7c.fsf@rimspace.net> References: <874oioot7c.fsf@rimspace.net> Message-ID: <4BE01968.9000906@rabbitmq.com> Hi Daniel. On 04/05/10 11:29, Daniel Pittman said: > G'day. > > I am looking at deploying RabbitMQ to provide messaging services inside, and > between, our two sites using both the AMQP and STOMP interfaces. > > As far as I can tell we have two choices for deploying this: > > 1. Use an Erlang cluster over the WAN, as a single instance of RabbitMQ > > 2. Use the 'shovel' extension to push messages between two distinct RabbitMQ > clusters, one at each site. > > The only real discussion I can find about this is from 35 weeks ago, where the > comment was that using shovel might better handle a situation where the WAN > was down, but that it was not production ready. As an aside, Matthew now tells me that the shovel is "production ready", although at the moment it still requires compiling the broker, Erlang client and shovel from source. > My impression is that, generally speaking, we are likely to be best served by > using an Erlang cluster over the network: the WAN is fairly reliable, and will > soon have two redundant paths, further reducing the risk of a split cluster. > > > Am I correct in my understanding that using RabbitMQ in this way means: > > Clients will connect to their local RabbitMQ node, and when they create a > queue it will exist only on that specific node. Yes. > Erlang will route messages to the correct node, either inside the site or over > the WAN as required. Yes. > Erlang and/or RabbitMQ will ensure that only one copy of a message traverses > the WAN, even if there are multiple recipients at the remote site. Not in 1.7.2. Versions of this optimisation existed in previous versions of RabbitMQ, but have since been disabled since they broke some ordering guarantees. There's a new, correct, version of this optimisation on branch bug19844 in Mercurial (so, err, requiring you to compile from source again). It's in a fairly reasonable state and hopefully should get merged into the default branch soon and thus find its way into the next release. You are very welcome, and indeed encouraged, to test it out before that happens. > Erlang and RabbitMQ will recover from a brief interruption of clustering, such > as a reboot of the server at one site, without manual intervention. I believe so. > Further, is there anything useful that I can read about Erlang and RabbitMQ > WAN clustering? My research, to date, has not given me much to learn from, > which makes me wonder what hidden complexity I might be risking... I assume you've seen the clustering guide: http://www.rabbitmq.com/clustering.html (but that's pretty basic, I admit), and the Distributed Erlang manpage: http://www.erlang.org/doc/reference_manual/distributed.html (or at least the section on security). Yes, we could probably do with more documentation... Cheers, Simon -- Simon MacMullen Staff Engineer, RabbitMQ SpringSource, a division of VMware From daniel at rimspace.net Tue May 4 14:11:38 2010 From: daniel at rimspace.net (Daniel Pittman) Date: Tue, 04 May 2010 23:11:38 +1000 Subject: [rabbitmq-discuss] RabbitMQ and a two-site deployment connected via WAN. References: <874oioot7c.fsf@rimspace.net> <4BE01968.9000906@rabbitmq.com> Message-ID: <87hbmnolpx.fsf@rimspace.net> Simon MacMullen writes: > On 04/05/10 11:29, Daniel Pittman said: >> G'day. >> >> I am looking at deploying RabbitMQ to provide messaging services inside, and >> between, our two sites using both the AMQP and STOMP interfaces. >> >> As far as I can tell we have two choices for deploying this: >> >> 1. Use an Erlang cluster over the WAN, as a single instance of RabbitMQ >> >> 2. Use the 'shovel' extension to push messages between two distinct RabbitMQ >> clusters, one at each site. >> >> The only real discussion I can find about this is from 35 weeks ago, where the >> comment was that using shovel might better handle a situation where the WAN >> was down, but that it was not production ready. > > As an aside, Matthew now tells me that the shovel is "production ready", > although at the moment it still requires compiling the broker, Erlang > client and shovel from source. At least help from another user here, and a bunch of struggling, got me as far as building rabbitmq-stomp from source to a Debian package, so building those wouldn't be too terrible, if needs be. I figured in most of a year things might have moved on; is it still likely that shovel will avoid losing messages across a WAN split where Erlang clustering would lose them? >> My impression is that, generally speaking, we are likely to be best served by >> using an Erlang cluster over the network: the WAN is fairly reliable, and will >> soon have two redundant paths, further reducing the risk of a split cluster. [...] >> Erlang and/or RabbitMQ will ensure that only one copy of a message >> traverses the WAN, even if there are multiple recipients at the remote >> site. > > Not in 1.7.2. Versions of this optimisation existed in previous versions > of RabbitMQ, but have since been disabled since they broke some ordering > guarantees. OK. Given I do value stability and correctness over performance, in 1.7.2 is this going to be one copy per subscriber on the remote node over the WAN? > There's a new, correct, version of this optimisation on branch bug19844 > in Mercurial (so, err, requiring you to compile from source again). It's > in a fairly reasonable state and hopefully should get merged into the > default branch soon and thus find its way into the next release. You are > very welcome, and indeed encouraged, to test it out before that happens. Depending, I might well do so ? but given we are testing the message queue system, we are very unlikely to actually find problems with this. [...] >> Further, is there anything useful that I can read about Erlang and RabbitMQ >> WAN clustering? My research, to date, has not given me much to learn from, >> which makes me wonder what hidden complexity I might be risking... > > I assume you've seen the clustering guide: > http://www.rabbitmq.com/clustering.html Yup. Very useful, and a good guide. I felt quite comfortable that it covered pretty much everything RabbitMQ-specific I needed to know about clustering. > (but that's pretty basic, I admit), and the Distributed Erlang manpage: > http://www.erlang.org/doc/reference_manual/distributed.html > (or at least the section on security). Yup. Again, useful, though I need to invest a little more time in understanding how best to set and share the cookie if I do go down this path. What I am missing is not so much a reference or admin guide, but a practical implementation FAQ: I want to understand better what, for example, high latency or low bandwidth links mean in the context of a WAN Erlang cluster: if latency gets high enough, do messages time-out and get retried? Is this congestion-controlled? When the Erlang messages start to back up, do they take down the cluster? I *think* the answer is that Erlang is good about this, and time-out control is application specific, but there doesn't seem to be a good guide to what there is that I *should* be worrying about. > Yes, we could probably do with more documentation... The RabbitMQ documentation is actually pretty darn good, as far as I am concerned; a large part of why your implementation was the one I chose to trial was that it was easy to understand from what you have written. Now, the Erlang platform, that could do with a guidebook in addition to the reference manual. :) Daniel -- ? Daniel Pittman ? daniel at rimspace.net ? +61 401 155 707 ? made with 100 percent post-consumer electrons From simon at rabbitmq.com Tue May 4 16:07:56 2010 From: simon at rabbitmq.com (Simon MacMullen) Date: Tue, 04 May 2010 16:07:56 +0100 Subject: [rabbitmq-discuss] RabbitMQ and a two-site deployment connected via WAN. In-Reply-To: <87hbmnolpx.fsf@rimspace.net> References: <874oioot7c.fsf@rimspace.net> <4BE01968.9000906@rabbitmq.com> <87hbmnolpx.fsf@rimspace.net> Message-ID: <4BE0384C.6050100@rabbitmq.com> On 04/05/10 11:29, Daniel Pittman said: > I figured in most of a year things might have moved on; is it still likely > that shovel will avoid losing messages across a WAN split where Erlang > clustering would lose them? Yeees, but it's really two different concepts. The clustered case is really a big RabbitMQ server; when a node vanishes it's as if that node's queues just don't exist. The shovel case is two separate servers. For your case the shovel is more reliable, since messages can back up in either broker if the other is not visible; BUT it makes the topology of the whole thing visible to clients (and something you have to manage). This may not be a problem of course. >> Not in 1.7.2. Versions of this optimisation existed in previous versions >> of RabbitMQ, but have since been disabled since they broke some ordering >> guarantees. > > OK. Given I do value stability and correctness over performance, in 1.7.2 is > this going to be one copy per subscriber on the remote node over the WAN? Yes. >> There's a new, correct, version of this optimisation on branch bug19844 >> in Mercurial (so, err, requiring you to compile from source again). It's >> in a fairly reasonable state and hopefully should get merged into the >> default branch soon and thus find its way into the next release. You are >> very welcome, and indeed encouraged, to test it out before that happens. > > Depending, I might well do so ? but given we are testing the message queue > system, we are very unlikely to actually find problems with this. Fair enough :) > I want to understand better what, for example, high latency or low bandwidth > links mean in the context of a WAN Erlang cluster: if latency gets high > enough, do messages time-out and get retried? Is this congestion-controlled? > > When the Erlang messages start to back up, do they take down the cluster? > > I *think* the answer is that Erlang is good about this, and time-out control > is application specific, but there doesn't seem to be a good guide to what > there is that I *should* be worrying about. No, there isn't :( To answer your specific questions: If the latency gets very high, but a node is not down/disconnected, messages will back up indefinitely, so they don't retry per se, but don't get dropped either. In very high load / latency situations Erlang can decide that the other node is down depending on the "ticktime" - see this thread for more: http://markmail.org/message/wakptvfyogtgqnen Hope this helps. Cheers, Simon -- Simon MacMullen Staff Engineer, RabbitMQ SpringSource, a division of VMware From andrey at sent.com Tue May 4 22:53:46 2010 From: andrey at sent.com (Andrey P) Date: Tue, 4 May 2010 14:53:46 -0700 (PDT) Subject: [rabbitmq-discuss] Publishing to a non-existing exchange Message-ID: <28453539.post@talk.nabble.com> Testing the the version 1.7.2 I found that if a message is published to a non-existing exchange, the basicPublish method completes without exceptions, but instead the whole channel gets shut down after a moment. Is this a right behavior? Is there any way to keep the channel alive in these circumstances? Thanks a lot, ~ Andrey -- View this message in context: http://old.nabble.com/Publishing-to-a-non-existing-exchange-tp28453539p28453539.html Sent from the RabbitMQ mailing list archive at Nabble.com. From ivdelchev at gmail.com Wed May 5 13:08:10 2010 From: ivdelchev at gmail.com (Ivan Delchev) Date: Wed, 5 May 2010 14:08:10 +0200 Subject: [rabbitmq-discuss] rabbitmq-jsonrpc "shortcut" HTTP calls? In-Reply-To: References: <14f55851003150951s206bdcb9r5160f73fedbd3926@mail.gmail.com> <4BABDA08.8070506@lshift.net> Message-ID: Hi Tony, any thoughts for the future about optimizing the HTTP adapter? Some thoughs were listed previously in this thread but never got any reply.. Cheers, Ivan On Sun, Mar 28, 2010 at 1:20 PM, Ivan Delchev wrote: > Hi Tony, > > Nice to hear that! Anyway, I didn't have in mind changing the AMQP > protocol, I can imagine that there are plenty of people that use it in > its current form. In case of the HTTP impl I think the following > simple steps could help and can be easily accomodated in the server > impl: > > 1. Combine the "system.describe" calls to /rpc/rabbitmq and > /rpc/{service_hash}. Return a different hash in the "name" parameter > if the URL is already in use, otherwise return the same. ?Thus the 2 > "system.describe" calls can become 1. > > 2. Bundle calls that do not depend on each other in one call - e.g by > providing an array of method calls, that should be executed in the > same order. > > If no anonymous declarations are used, this should be acceptable: > > {"version":"1.1","id":5,"methods" : [ > ? ?{"method":"open","params":["2","5b3beb2605605b9ebf5055f3e9e29754",120,null]} > ? ?{"method":"call","params":["access.request",["/data",false,true,true,true,true]]}, > ? ?{"method":"call","params":["exchange.declare",[1,"exchange1","fanout",false,false,true,false,false,{}]]}, > ? ?{"method":"call","params":["queue.declare",[1,"queue1",false,false,true,true,false,{}]]}, > ? ?{"method":"call","params":["queue.bind",[1,"queue1","exchange1","",false,{}]]} > ? ?]} > > Another options is in case of anonymous declarations to nest the > declarations and compute the internal results first and use them as > arguments for the upper ones: > > {"version":"1.1","id":5,"methods" : [ > ? ?{"method":"open","params":["2","5b3beb2605605b9ebf5055f3e9e29754",120,null]} > ? ?{"method":"call","params":["access.request",["/data",false,true,true,true,true]]}, > ? ?{"method":"call","params":["queue.bind",[1, > ? ? ? ?{"method":"call","params":["queue.declare",[1,"",false,false,true,true,false,{}]]}, > ? ? ? ?{"method":"call","params":["exchange.declare",[1,"","fanout",false,false,true,false,false,{}]]}, > ? ? ? ?"",false,{}]]} > ? ?]} > > That should be possible and I think and will save quite some HTTP > roundtrips. If you provide the server-side I can try to deliver the > javascript client :) > > Cheers, > Ivan > > On Thu, Mar 25, 2010 at 10:47 PM, Tony Garnock-Jones wrote: >> Hi Ivan, >> >> I like the idea. I like it not only for HTTP but also for AMQP's native >> wire protocol. I don't have time to work on it at the moment, but >> perhaps we can discuss it here: do you have any concrete suggestions for >> what it might look like? Maybe start with the HTTP setting and we can >> generalise to the AMQP wire protocol later. And of course if you had a >> prototype/proof-of-concept implementation, that'd be very welcome in >> terms of getting the ball rolling :-) >> >> Regards, >> ?Tony >> >> Ivan Delchev wrote: >>> Hi guys, >>> >>> I have a question about RabbitMQ and more specifically >>> rabbitmq-jsonrpc. I know that this is an experimental download and is >>> basically translation of AMQP to HTTP, but is there a way to optimize >>> a typical process of e.g. authenticating yourself, declaring an >>> exchange and declaring a queue? Currently this takes 7-8 requests in a >>> row, which puts unnecessary load on the server. Does anyone know about >>> "shortcut" HTTP requests that bundle multiple AMQP calls in one >>> request in order to minimize overhead? >>> >>> @RabbitGuys Do you have any plans to implement and support such features? >>> >>> >>> Thanks a lot, >>> Ivan >>> >>> _______________________________________________ >>> rabbitmq-discuss mailing list >>> rabbitmq-discuss at lists.rabbitmq.com >>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> > From matthias at rabbitmq.com Wed May 5 16:32:20 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Wed, 05 May 2010 16:32:20 +0100 Subject: [rabbitmq-discuss] STOMP support - production ready? In-Reply-To: <87zl0lmvee.fsf@rimspace.net> References: <877hnta33v.fsf@rimspace.net> <4BDA2683.9060509@lshift.net> <87zl0lmvee.fsf@rimspace.net> Message-ID: <4BE18F84.1010204@rabbitmq.com> Daniel, Daniel Pittman wrote: > I see that there is a bit of Debian packaging ephemera in the stomp Mercurial > repository, and that the rabbitmq-public-umbrella module also includes some > support for it. > > I couldn't see, though, any advice on the site or the list archives about how > best to go ahead and build a Debian package for the extension. > > Is that documented somewhere, or am I going to have to troll through the build > system and work that out myself? The latter, I'm afraid. We are planning to make binary releases of some plug-ins available, but that is still some way off. Regards, Matthias. From david at rabbitmq.com Wed May 5 16:38:14 2010 From: david at rabbitmq.com (David Wragg) Date: Wed, 05 May 2010 16:38:14 +0100 Subject: [rabbitmq-discuss] Publishing to a non-existing exchange In-Reply-To: <28453539.post@talk.nabble.com> (Andrey P.'s message of "Tue\, 4 May 2010 14\:53\:46 -0700 \(PDT\)") References: <28453539.post@talk.nabble.com> Message-ID: Hi Andrei, Andrey P writes: > Testing the the version 1.7.2 I found that if a message is published to a > non-existing exchange, the basicPublish method completes without exceptions, > but instead the whole channel gets shut down after a moment. Is this a right > behavior? Is there any way to keep the channel alive in these circumstances? It's defined to work that way by AMQP (at least in version 0.8 of the protocol, as implemented by RabbitM 1.7.2; I'm not closely familiar with later versions of the protocol, but I expect one of my colleagues will comment if the situation changes significantly in later protocol versions). An AMQP client sends basic.publish to the server without waiting for a response. If the exchange does not exist, the 0.8 spec says that this is reported by raising a channel exception. This involves the server sending a channel.close to the client, with fields indicating the nature of the exception, i.e. by closing the channel. David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware From andrey at sent.com Wed May 5 17:08:09 2010 From: andrey at sent.com (Andrey P) Date: Wed, 5 May 2010 09:08:09 -0700 (PDT) Subject: [rabbitmq-discuss] Publishing to a non-existing exchange In-Reply-To: References: <28453539.post@talk.nabble.com> Message-ID: <28462892.post@talk.nabble.com> David, Thank you for your reply. ~ Andrey -- View this message in context: http://old.nabble.com/Publishing-to-a-non-existing-exchange-tp28453539p28462892.html Sent from the RabbitMQ mailing list archive at Nabble.com. From mikeb at lshift.net Wed May 5 17:23:23 2010 From: mikeb at lshift.net (Michael Bridgen) Date: Wed, 05 May 2010 17:23:23 +0100 Subject: [rabbitmq-discuss] ordering semantics In-Reply-To: <392922E81643B245A905B42E3E34C2401496EE3025@EXCH-MBX-1.vmware.com> References: <392922E81643B245A905B42E3E34C2401496EE3025@EXCH-MBX-1.vmware.com> Message-ID: <4BE19B7B.4000609@lshift.net> Jim, > I'm trying to get a handle on ordering semantics on the topic exchange. > > Assume there are two publishers, each on their own channel. Publishers > produce a stream of messages. So: > > Publisher A produces A1, A2, A3 (in that order) Publisher B produces B1, > B2, B3 (in that order) > > There is a single subscriber on a queue that all the messages produced > by both publishers are targeted to. > > Questions: > > 1. Messages A1, A2, A3 are received in that order. Messages B1, B2, B3 > are received in that order. Correct? Yes, in the absence of relivery due to e.g., recover. > 2. Messages from A can be interleaved from B as in: A1, A2, B1, B2, B3, > A3. (Still subject to the constraint from question 1 above) Correct? Yes. > 3. In the event of a failure of a node in a cluster, messages may be > lost, but do they still obey the strict ordering, even though messages > may travel a different route in the cluster? At the minute queues in a RabbitMQ cluster are located on a node; so, if the node was lost, the queue would be lost, and the ordering moot. > 4. I?m assuming that the ordering semantics guaranteed per-channel, correct? The spirit of the ordering guarantee is more like "along a single route, ordering between a single publisher and a single consumer is preserved". Generally, the other consistency guarantees in AMQP 0-8/0-9-1 are scoped to channels, though. > 5.Can a subscriber determine a unique ID of the actual sender (i.e., can > a subscriber know if a message was sent by A or B)? One can use, for example, the message header "correlation-id" to label messages from a particular publisher -- the broker won't touch it. Regards, Michael From lists at zopyx.com Wed May 5 18:51:35 2010 From: lists at zopyx.com (Andreas Jung) Date: Wed, 05 May 2010 19:51:35 +0200 Subject: [rabbitmq-discuss] Sematics of ACK/REQUEUE/DISCARD on a message Message-ID: <4BE1B027.5080407@zopyx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Using RabbitMQ together with the Carrot Python bindings. Two questions: - - assuming a consumer could process a message with success - what is the difference in the message handling inside the queue between acknowledging it or discarding it - it will be removed from the queue in both cases?! - - assuming a consumer could not process a message properly (e.g. some database backend down) and is interested to re-try this message later. In this case I would requeue the message. At which position in the queue will the message be inserted? At the end of the queue? Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvhsCcACgkQCJIWIbr9KYzkJQCgmxkaLsChoHib6seEpXpNfUsF WTkAoKtFUfI/CaDUXTTmDs5FU0JSDC0M =OVc9 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: lists.vcf Type: text/x-vcard Size: 316 bytes Desc: not available Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100505/41b1bb9b/attachment.vcf From matthew at lshift.net Wed May 5 20:03:22 2010 From: matthew at lshift.net (Matthew Sackman) Date: Wed, 5 May 2010 20:03:22 +0100 Subject: [rabbitmq-discuss] Sematics of ACK/REQUEUE/DISCARD on a message In-Reply-To: <4BE1B027.5080407@zopyx.com> References: <4BE1B027.5080407@zopyx.com> Message-ID: <20100505190321.GA15462@wellquite.org> On Wed, May 05, 2010 at 07:51:35PM +0200, Andreas Jung wrote: > Two questions: > > - - assuming a consumer could process a message with success - what is > the difference in the message handling inside the queue between > acknowledging it or discarding it - it will be removed from the queue > in both cases?! If you don't ack it, it will be retained by RabbitMQ and will be redelivered to some other consumer eventually when your current consumer cancels/dies. > - - assuming a consumer could not process a message properly (e.g. some > database backend down) and is interested to re-try this message later. > In this case I would requeue the message. At which position in the > queue will the message be inserted? At the end of the queue? Basic.reject is not implemented. Calling basic.recover{requeue=true} will requeue all non-acknowledged messages outstanding on the current *channel*. Note this is not queue specific. The specification is silent as to where in the queues the messages should be reentered and you should not rely on any particular behaviour. Currently RabbitMQ requeues messages at the end of the queue (i.e. they behave like new publishes), but that can change. Matthew From alexis at rabbitmq.com Wed May 5 20:58:28 2010 From: alexis at rabbitmq.com (Alexis Richardson) Date: Wed, 5 May 2010 20:58:28 +0100 Subject: [rabbitmq-discuss] request for help! Message-ID: Hi everyone, As part of an ongoing drive to "be more open" as well as to "get to 1.0" the AMQP Working Group has published the 1-0 PR3 draft on the webs for Public Comment: http://www.amqp.org/confluence/download/attachments/2523279/amqp_1-0_PR3.pdf I would be thrilled if the whole community could take a look at this. Please: - Be quick! We need comments asap. - Be brutal. Don't hold back. Anything goes. - Be constructive. Your suggestions will help AMQP. Comment here or on blogs or tweet. Public comment is essential. Over to you (all)... alexis From contact at a-net-user.com Wed May 5 23:11:01 2010 From: contact at a-net-user.com (Roaan Vos) Date: Thu, 6 May 2010 00:11:01 +0200 Subject: [rabbitmq-discuss] Unbinding when not bound Message-ID: <001301caec9f$dc4ed6f0$94ec84d0$@com> Hi, I currently allow clients to "bind" and "unbind" to various topics as needed using the .net client. However, when the client "unbinds" without first having done a bind, RabbitMQ throws an exception and the connection seems to disappear. Is there a way for it to keep the connection (or not throw an exception)? Thanks Roaan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100506/a9898b46/attachment-0001.htm From mikeb at lshift.net Wed May 5 23:38:18 2010 From: mikeb at lshift.net (Michael Bridgen) Date: Wed, 05 May 2010 23:38:18 +0100 Subject: [rabbitmq-discuss] Unofficial guide to AMQP 1.0 PR3 Message-ID: <4BE1F35A.2060904@lshift.net> All, I'd like to second Alexis's request for eyes on the new AMQP 1.0 spec ("PR3"). To help out, here is a brief guide to the spec, with reference to the AMQP 0-8 implemented in RabbitMQ. I've left out a lot of details, so I encourage everyone to read the spec in depth, and simply use this guide as a map of the territory to get started. I'll *emphasise* anything that's a 1.0 term, and leave 0-8 terms in roman. Book I Messaging Model The core AMQP 1.0 spec abstracts, to a large extent, away from the purely client-broker model of previous specs. Since we're referring to 0-8, take *Container* or "peer" (and other synonyms) to mean Broker or Application + Client library, but bear in mind that it's aimed at something more general. A *Node* is something that's addressed in a *Container*. For a broker that would be an exchange or queue. For an application, that's a consumer or (oddly, in 0-8) a publisher. *Links* are a generalisation of a publication or consumption relationship between *Nodes*. So on the consuming side, i.e., with basic.consume, this has a queue name (addressing a queue) at one end and a consumer tag at the other (addressing, probably, some kind of buffer from which the application will retrieve messages). In 0-8, there's no declaration of a publication relation, one just mentions the target in the basic.publish method (or not, in the case of the default exchange). In PR3, publication is treated as symmetric to consumption. *Credit* is like a combination of channel.flow and basic.qos. I'll come back to it later. For *Sessions* think channels. One difference is that things aren't necessarily scoped to *session* lifetimes; in particular, *Links* can be resumed after a connection drop. Book II Data types This represents something more ambitious than the codec in 0-8; it is a data type system as well. But for the purpose of this guide, it's the codec. Book III Transport Connections and framing are much the same as they are in 0-8. This section talks about *channels*, but doesn't mean 0-8 channels, instead it's more like a "session handle". *Sessions* are opened by saying "I'm going start a session called xyz, I'll be speaking on channel 4" and hearing back "ok, I'll talk about xyz on channel 7" -- so each party now can use a number to refer to the *session*. *Transfer* is used in the place of both basic.publish (which clients use) and basic.deliver (which clients receive), because they both happen over a *link*. Unlike 0-8, publishing can be acked (though this may not be required) -- a *link endpoint* (i.e., the state of the *link* kept in the broker and in the client) maintains a replay buffer, and can resend messages that haven't been acked. Similarly, the receiving *link endpoint* can keep a deduplication filter. *Disposition* is used to report the state of messages, e.g., "consider this acknowledged". Resuming *links* is something like what basic.recover tries to achieve, resending messages that aren't known to have been processed. Flow control acts like a more fine-grained channel.flow for publishers, and like basic.qos for consumers; in each case, the receiving side issues *credit*, which the sending side uses up by transferring messages. To do something like a basic.get, a consumer issues a single unit of *credit*, and waits for the single message to come in. Book IV Messaging In 0-8, exchanges route messages to all matching bindings, while queues deliver messages to only one consumer. In PR3, *non-destructive links* convey messages while leaving them available for other links (like exchanges do), and *destructive links* acquire messages and so make them unavailable for other links (like queues do). In principle these can be mixed. Both kinds of *links* can have *filters*, which are like exchange types in addition to binding keys, in that they each specify an algorithm and the particulars; a bit like if bindings could be "topic:ticker.nyse.*". Book V Transactions In PR3, transactions are decoupled from *sessions*, which is unlike 0-8 in which the transactional behaviour is determined per channel. Transactions can also cover publication, message acknowledgement (or rejection), /and/ deliveries, unlike 0-8 in which publication and acknowledgement only are covered. Book VI Security TLS is negotiated after a special protocol header is sent over the normal AMQP port 5672, instead of being established first on a different port as in RabbitMQ. SASL does much the same thing, using a special protocol header then negotiation, and replaces in part the connection.{start,start-ok,secure,secure-ok} methods in 0-8. From rnickel at scea.com Thu May 6 00:22:45 2010 From: rnickel at scea.com (Robert Nickel) Date: Wed, 5 May 2010 16:22:45 -0700 Subject: [rabbitmq-discuss] Really bizarre startup issue... In-Reply-To: <20100430230143.GR7977@coinelement.989studios.com> References: <20100430230143.GR7977@coinelement.989studios.com> Message-ID: <20100505232245.GA29873@coinelement.989studios.com> On 2010.04.30 16:01:43 -0700, Robert Nickel wrote: > First, thank you. > > I have two hosts (sdcloudsh01 and sdcloudsh02) with the following specifications: > CentOS 5.1 > erlang R13B03 > rabbitmq-server 1.7.2 > selinux is disabled Still no luck figuring out what is going on with this machine. Can someone advise me on how to get erlang to do a debug trace of some sort? I have zero experience with erlang programming and would rather not delve into it at this time. That said, the lack of any kind of useful error is driving me nuts. Some additional information surrounding this issue: * rabbitmq-server was downloaded from http://www.rabbitmq.com/releases/rabbitmq-server/v1.7.2/rabbitmq-server-1.7.2-1.i386.rpm $ rpm -qi rabbitmq-server Name : rabbitmq-server Relocations: (not relocatable) Version : 1.7.2 Vendor: (none) Release : 1 Build Date: Mon 15 Feb 2010 08:02:10 AM PST Install Date: Wed 05 May 2010 02:30:56 PM PDT Build Host: debian Group : Development/Libraries Source RPM: rabbitmq-server-1.7.2-1.src.rpm Size : 706344 License: MPLv1.1 Signature : DSA/SHA1, Mon 15 Feb 2010 08:07:35 AM PST, Key ID f7b8cea6056e8e56 URL : http://www.rabbitmq.com/ Summary : The RabbitMQ server Description : RabbitMQ is an implementation of AMQP, the emerging standard for high performance enterprise messaging. The RabbitMQ server is a robust and scalable implementation of an AMQP broker. Adding set -x to /usr/lib/bin/rabbitmq-multi at the top yeilds the following output in /var/lib/rabbitmq/startup_err: + for arg in '"$@"' ++ sed -e 's/"/\\"/g' + arg=start_all + CMDLINE=' "start_all"' + for arg in '"$@"' ++ sed -e 's/"/\\"/g' + arg=1 + CMDLINE=' "start_all" "1"' + cd /var/lib/rabbitmq ++ basename /usr/sbin/rabbitmq-multi + SCRIPT=rabbitmq-multi ++ id -u + '[' 0 = 0 ']' + su rabbitmq -s /bin/sh -c '/usr/lib/rabbitmq/bin/rabbitmq-multi "start_all" "1"' + NODENAME=rabbit ++ dirname /usr/lib/rabbitmq/bin/rabbitmq-multi + SCRIPT_HOME=/usr/lib/rabbitmq/bin + PIDS_FILE=/var/lib/rabbitmq/pids + MULTI_ERL_ARGS= + MULTI_START_ARGS= + CONFIG_FILE=/etc/rabbitmq/rabbitmq ++ dirname /usr/lib/rabbitmq/bin/rabbitmq-multi + . /usr/lib/rabbitmq/bin/rabbitmq-env ++ SCRIPT_PATH=/usr/lib/rabbitmq/bin/rabbitmq-multi ++ '[' -h /usr/lib/rabbitmq/bin/rabbitmq-multi ']' +++ readlink -f /usr/lib/rabbitmq/bin/rabbitmq-multi ++ FULL_PATH=/usr/lib/rabbitmq/lib/rabbitmq_server-1.7.2/sbin/rabbitmq-multi ++ '[' 0 '!=' 0 ']' ++ SCRIPT_PATH=/usr/lib/rabbitmq/lib/rabbitmq_server-1.7.2/sbin/rabbitmq-multi ++ '[' -h /usr/lib/rabbitmq/lib/rabbitmq_server-1.7.2/sbin/rabbitmq-multi ']' +++ dirname /usr/lib/rabbitmq/lib/rabbitmq_server-1.7.2/sbin/rabbitmq-multi ++ SCRIPT_DIR=/usr/lib/rabbitmq/lib/rabbitmq_server-1.7.2/sbin ++ RABBITMQ_HOME=/usr/lib/rabbitmq/lib/rabbitmq_server-1.7.2/sbin/.. ++ '[' -f /etc/rabbitmq/rabbitmq.conf ']' ++ . /etc/rabbitmq/rabbitmq.conf +++ NODENAME=regsvc at sdcloudsh01 + DEFAULT_NODE_IP_ADDRESS=0.0.0.0 + DEFAULT_NODE_PORT=5672 + '[' x = x ']' + '[' x '!=' x ']' + '[' x = x ']' + '[' x '!=' x ']' + '[' x = x ']' + '[' x '!=' x ']' + '[' x = x ']' + RABBITMQ_NODENAME=regsvc at sdcloudsh01 + '[' x = x ']' + RABBITMQ_SCRIPT_HOME=/usr/lib/rabbitmq/bin + '[' x = x ']' + RABBITMQ_PIDS_FILE=/var/lib/rabbitmq/pids + '[' x = x ']' + RABBITMQ_MULTI_ERL_ARGS= + '[' x = x ']' + RABBITMQ_MULTI_START_ARGS= + '[' x = x ']' + RABBITMQ_CONFIG_FILE=/etc/rabbitmq/rabbitmq + export RABBITMQ_NODENAME RABBITMQ_NODE_IP_ADDRESS RABBITMQ_NODE_PORT RABBITMQ_SCRIPT_HOME RABBITMQ_PIDS_FILE RABBITMQ_CONFIG_FILE + env + RABBITMQ_CONFIG_ARG= + '[' -f /etc/rabbitmq/rabbitmq.config ']' + RABBITMQ_CONFIG_ARG='-config /etc/rabbitmq/rabbitmq' + set -f + exec erl -pa /usr/lib/rabbitmq/lib/rabbitmq_server-1.7.2/sbin/../ebin -noinput -hidden -sname rabbitmq_multi32076 -config /etc/rabbitmq/rabbitmq -s rabbit_multi -extra start_all 1 Error: {node_start_failed,normal} Thanks in advance for any help. --Robert From chen650 at yahoo.com Thu May 6 00:35:44 2010 From: chen650 at yahoo.com (alex chen) Date: Wed, 5 May 2010 16:35:44 -0700 (PDT) Subject: [rabbitmq-discuss] socket read timeout in rabbitmq-c Message-ID: <131339.14680.qm@web31812.mail.mud.yahoo.com> Hi, We are using rabbitmq-c. It seems to me most of the functions such as amqp_login and amqp_channel_open call amqp_simple_rpc, which sends the request and waits for response. There seems to be no way to specify timeout value for waiting the response. the amqp_socket.c::wait_frame_inner() calls read() and it may block forever if the response is net received. I am wondering if it can support specifying a time out (e.g. amqp_set_timeout(int timeout)), and add select(timeout) before the read() in wait_frame? We found in several cases that amqp_channel_open hanged while doing read() in wait_frame_inner(). here is the stack trace: (gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xf7fbc69b in __read_nocancel () from /lib/tls/libpthread.so.0 #2 0xf7fdf3e3 in wait_frame_inner (state=0x8053938, decoded_frame=0xf7732180) at amqp_socket.c:147 #3 0xf7fdf64f in amqp_simple_rpc (state=0x8053938, channel=1, request_id=1310730, expected_reply_ids=0xf77321f8, decoded_request_method=0xf77321f0) at amqp_socket.c:251 #4 0xf7fdff3b in amqp_channel_open (state=0x8053938, channel=1) at amqp_api.c:22 thanks. -alex From scott at beamdog.com Thu May 6 01:33:36 2010 From: scott at beamdog.com (Scott Brooks) Date: Wed, 5 May 2010 18:33:36 -0600 Subject: [rabbitmq-discuss] socket read timeout in rabbitmq-c In-Reply-To: <131339.14680.qm@web31812.mail.mud.yahoo.com> References: <131339.14680.qm@web31812.mail.mud.yahoo.com> Message-ID: This may not solve your exact problem but it may help You can pull the socket out of rabbitmq-c with amqp_get_sockfd and then you can query amqp_data_in_buffer If amqp_data_in_buffer returns true, then the next read will return a packet from inside it's internal buffer, and not check the network If it returns false, select on the sockfd from amqp_get_sockfd to see if there is data to be retrieved. Only then call a possibly blocking function. Scott On Wed, May 5, 2010 at 5:35 PM, alex chen wrote: > > Hi, > > We are using rabbitmq-c. ?It seems to me most of the functions such as amqp_login and amqp_channel_open call amqp_simple_rpc, which sends the request and waits for response. ?There seems to be no way to specify timeout value for waiting the response. ?the amqp_socket.c::wait_frame_inner() calls read() and it may block forever if the response is net received. > > I am wondering if it can support specifying a time out (e.g. amqp_set_timeout(int timeout)), and add select(timeout) before the read() in wait_frame? ?We found in several cases that amqp_channel_open hanged while doing read() in wait_frame_inner(). ?here is the stack trace: > > (gdb) where > #0 ?0xffffe410 in __kernel_vsyscall () > #1 ?0xf7fbc69b in __read_nocancel () from /lib/tls/libpthread.so.0 > #2 ?0xf7fdf3e3 in wait_frame_inner (state=0x8053938, decoded_frame=0xf7732180) at amqp_socket.c:147 > #3 ?0xf7fdf64f in amqp_simple_rpc (state=0x8053938, channel=1, request_id=1310730, expected_reply_ids=0xf77321f8, > decoded_request_method=0xf77321f0) at amqp_socket.c:251 > #4 ?0xf7fdff3b in amqp_channel_open (state=0x8053938, channel=1) at > amqp_api.c:22 > > thanks. > > -alex > > > > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From chen650 at yahoo.com Thu May 6 01:44:11 2010 From: chen650 at yahoo.com (alex chen) Date: Wed, 5 May 2010 17:44:11 -0700 (PDT) Subject: [rabbitmq-discuss] socket read timeout in rabbitmq-c In-Reply-To: References: <131339.14680.qm@web31812.mail.mud.yahoo.com> Message-ID: <146232.66629.qm@web31809.mail.mud.yahoo.com> thanks Scott for the suggestion! We actually use amqp_data_in_buffer+select to wait for the frames to be consumed. However, it is not easy to this for rpc like calls such as login/channel_open, because they call send+wait inside the function. there is no way to insert the select() between the send_method and wait_frame(). -alex ----- Original Message ---- > From: Scott Brooks > To: alex chen > Cc: rabbitmq-discuss at lists.rabbitmq.com > Sent: Wed, May 5, 2010 5:33:36 PM > Subject: Re: [rabbitmq-discuss] socket read timeout in rabbitmq-c > > This may not solve your exact problem but it may help You can pull the > socket out of rabbitmq-c with amqp_get_sockfd and then you can > query amqp_data_in_buffer If amqp_data_in_buffer returns true, then > the next read will return a packet from inside it's internal buffer, and not > check the network If it returns false, select on the sockfd from > amqp_get_sockfd to see if there is data to be retrieved. Only then > call a possibly blocking function. Scott From matthias at rabbitmq.com Thu May 6 05:56:56 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Thu, 06 May 2010 05:56:56 +0100 Subject: [rabbitmq-discuss] Really bizarre startup issue... In-Reply-To: <20100430230143.GR7977@coinelement.989studios.com> References: <20100430230143.GR7977@coinelement.989studios.com> Message-ID: <4BE24C18.80008@rabbitmq.com> Robert, Robert Nickel wrote: > On sdcloudsh01, contents of /etc/rabbitmq files: > rabbitmq.conf: > NODENAME=regsvc at sdcloudsh01 > rabbitmq.config: > [ > {rabbit, []} > ]. > rabbitmq_cluster.config: > [ 'regsvc at sdcloudsh01','regsvc at sdcloudsh02' ]. > > When starting the rabbitmq server using /sbin/service rabbitmq-server start, > the service fails Does rabbit start up fine if you a) remove all the above configuration files, and b) delete the database directory (usually /var/lib/rabbitmq/mnesia)? > the following outputs are in /var/log/rabbitmq/startup_err and log: > > _log: > Starting all nodes... > Starting node regsvc at sdcloudsh01... > _err: > Error: {node_start_failed,normal} Are there any other non-empty log files in /var/log/rabbitmq? > After a bunch of troubleshooting, I noticed that if I strace the above > command, everything works fine: > > strace -f /sbin/service rabbitmq-server start > > Terminating the strace leaves the rabbit server running happily. That would suggest some sort of race / timing issue. Strange. Regards, Matthias. From lists at zopyx.com Thu May 6 06:09:42 2010 From: lists at zopyx.com (Andreas Jung) Date: Thu, 06 May 2010 07:09:42 +0200 Subject: [rabbitmq-discuss] Sematics of ACK/REQUEUE/DISCARD on a message In-Reply-To: <20100505190321.GA15462@wellquite.org> References: <4BE1B027.5080407@zopyx.com> <20100505190321.GA15462@wellquite.org> Message-ID: <4BE24F16.1040708@zopyx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Sackman wrote: > On Wed, May 05, 2010 at 07:51:35PM +0200, Andreas Jung wrote: >> Two questions: >> >> - - assuming a consumer could process a message with success - what is >> the difference in the message handling inside the queue between >> acknowledging it or discarding it - it will be removed from the queue >> in both cases?! > > If you don't ack it, it will be retained by RabbitMQ and will be > redelivered to some other consumer eventually when your current > consumer cancels/dies. Got it. Since the consumer is called through a call-back it will get the same message again (after restarting and if it is the only consumer) if the consumer dies without ack-ing the message. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkviTxYACgkQCJIWIbr9KYyQvQCfYwJcJG6nKetDvM1AWaZp8ih8 n/IAn0cJJpqZu5XsaVjG6fb8odksiGov =WkPT -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: lists.vcf Type: text/x-vcard Size: 316 bytes Desc: not available Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100506/be787a40/attachment-0001.vcf From matthias at rabbitmq.com Thu May 6 06:17:44 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Thu, 06 May 2010 06:17:44 +0100 Subject: [rabbitmq-discuss] Sematics of ACK/REQUEUE/DISCARD on a message In-Reply-To: <20100505190321.GA15462@wellquite.org> References: <4BE1B027.5080407@zopyx.com> <20100505190321.GA15462@wellquite.org> Message-ID: <4BE250F8.7000601@rabbitmq.com> Matthew Sackman wrote: > On Wed, May 05, 2010 at 07:51:35PM +0200, Andreas Jung wrote: >> Two questions: >> >> - - assuming a consumer could process a message with success - what is >> the difference in the message handling inside the queue between >> acknowledging it or discarding it - it will be removed from the queue >> in both cases?! > > If you don't ack it, it will be retained by RabbitMQ and will be > redelivered to some other consumer eventually when your current > consumer cancels/dies. Careful here - cancelling a consumer with basic.cancel does *not* cause unack'ed messages to be requeued/redelivered. For that to happen the channel needs to be closed (explicitly, or implicitly via a connection closure or termination). Matthias. From lists at zopyx.com Thu May 6 06:28:25 2010 From: lists at zopyx.com (Andreas Jung) Date: Thu, 06 May 2010 07:28:25 +0200 Subject: [rabbitmq-discuss] Sematics of ACK/REQUEUE/DISCARD on a message In-Reply-To: <4BE250F8.7000601@rabbitmq.com> References: <4BE1B027.5080407@zopyx.com> <20100505190321.GA15462@wellquite.org> <4BE250F8.7000601@rabbitmq.com> Message-ID: <4BE25379.6010205@zopyx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthias Radestock wrote: > Matthew Sackman wrote: >> On Wed, May 05, 2010 at 07:51:35PM +0200, Andreas Jung wrote: >>> Two questions: >>> >>> - - assuming a consumer could process a message with success - what is >>> the difference in the message handling inside the queue between >>> acknowledging it or discarding it - it will be removed from the queue >>> in both cases?! >> If you don't ack it, it will be retained by RabbitMQ and will be >> redelivered to some other consumer eventually when your current >> consumer cancels/dies. > > Careful here - cancelling a consumer with basic.cancel does *not* cause > unack'ed messages to be requeued/redelivered. For that to happen the > channel needs to be closed (explicitly, or implicitly via a connection > closure or termination). Fair enough. Using Python you would ensure that the related code is properly enclosed within a context manager. For the case the consumer dies for whatever reasons: the channel would be closed and the action taken by the queue as you described it. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkviU3kACgkQCJIWIbr9KYzqvQCg0cKzg0E88SjtvG3Lhe4mild7 SKsAn2+jenlIMbf1csVxZMOTHhKpxf0W =hzu3 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: lists.vcf Type: text/x-vcard Size: 316 bytes Desc: not available Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100506/5a37d3d6/attachment.vcf From davorin.rusevljan at gmail.com Thu May 6 07:16:05 2010 From: davorin.rusevljan at gmail.com (Davorin Rusevljan) Date: Thu, 6 May 2010 08:16:05 +0200 Subject: [rabbitmq-discuss] Unofficial guide to AMQP 1.0 PR3 In-Reply-To: <4BE1F35A.2060904@lshift.net> References: <4BE1F35A.2060904@lshift.net> Message-ID: On Thu, May 6, 2010 at 12:38 AM, Michael Bridgen wrote: > All, > > I'd like to second Alexis's request for eyes on the new AMQP 1.0 spec > ("PR3"). > > To help out, here is a brief guide to the spec, with reference to the > AMQP 0-8 implemented in RabbitMQ. I've left out a lot of details, so I > encourage everyone to read the spec in depth, and simply use this guide > as a map of the territory to get started. > > Hi, and thank you for the summary. I am afraid that I am still new to AMQP 0.8, not to mention 1.0. But to my inexperienced eyes, I do not see much connection between the two, as if they are completely different standards :) This of course raises the question should I invest my time in learning 0.8 and products that use it, or try to jump the wagon of 1.0. What would you say, in what state is 1.0 specs is it about to be published soon, and what are the plans for RabbitMQ support for it? Thanks! Davorin Rusevljan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100506/25ae8ff1/attachment.htm From sustrik at 250bpm.com Thu May 6 09:11:47 2010 From: sustrik at 250bpm.com (Martin Sustrik) Date: Thu, 06 May 2010 10:11:47 +0200 Subject: [rabbitmq-discuss] request for help! In-Reply-To: References: Message-ID: <4BE279C3.6020903@250bpm.com> Alexis, > As part of an ongoing drive to "be more open" as well as to "get to > 1.0" the AMQP Working Group has published the 1-0 PR3 draft on the > webs for Public Comment: > http://www.amqp.org/confluence/download/attachments/2523279/amqp_1-0_PR3.pdf Great you are bringing this to the public attention! We've discussed this before, so I'm going to repeat myself for the sake of people on the mailing list... From my point of view there are two crucial issues with AMQP/1.0: 1. Messy layering. Almost every concept is discussed at multiple places. It's very hard to understand the specification in its current form. (To be fair, one piece is nicely and consistently separated. The codec.) 2. Assumption that messages are stored on the node in unordered fashion shifts AMQP from being message queueing protocol to being database protocol. This blurs AMQP's mission, makes it compete with SQL and causes implementation to be extremely costly and complex. We should follow the good old "do one thing and do it well" principle and focus on defining MQ behaviour rather than DB behaviour. Martin From alexis.richardson at gmail.com Thu May 6 09:50:52 2010 From: alexis.richardson at gmail.com (Alexis Richardson) Date: Thu, 6 May 2010 09:50:52 +0100 Subject: [rabbitmq-discuss] Unofficial guide to AMQP 1.0 PR3 In-Reply-To: References: <4BE1F35A.2060904@lshift.net> Message-ID: Davorin On Thu, May 6, 2010 at 7:16 AM, Davorin Rusevljan wrote: > > This of course raises the question should I invest my time in learning 0.8 > and products that use it, or try to jump the wagon of 1.0. > > What would you say, in what state is 1.0 specs is it about to be published > soon, and what are the plans for RabbitMQ support for it? The easiest path is to learn 0-8 or 0-91 which is very similar and better. 1-0 implementations of production quality are still some way off. alexis > Thanks! > > Davorin Rusevljan > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > From davorin.rusevljan at gmail.com Thu May 6 10:21:34 2010 From: davorin.rusevljan at gmail.com (Davorin Rusevljan) Date: Thu, 6 May 2010 11:21:34 +0200 Subject: [rabbitmq-discuss] request for help! In-Reply-To: References: Message-ID: I hope you do not mind beginner "how would I xxx in amqp1.0" type questions. They are not direct comments on the standard specs, but maybe some of them could eventually lead to the points that could be better explained, so answering them might not be a complete waste of time. (but if you do mind please let me know so that I can stop). So, as far as I see consumer issues a credits to the link, and if I am reading it correctly, it can stop the delivery of the messages to him that way. Now is there a way (automatic or programmed) for a broker or producer to get rid of the consumer if the number of messages awaiting for him to consume gets to high? Motivation for that would be preventing some ill intended client from DOSing the producer broker by forcing it to store large number of messages. Thanks! davorin rusevljan http://www.cloud208.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100506/6f3c4535/attachment.htm From rob.j.godfrey at gmail.com Thu May 6 11:43:30 2010 From: rob.j.godfrey at gmail.com (Robert Godfrey) Date: Thu, 6 May 2010 12:43:30 +0200 Subject: [rabbitmq-discuss] request for help! In-Reply-To: References: <4BE279C3.6020903@250bpm.com> <4BE2970B.9070208@250bpm.com> Message-ID: Sorry - had meant this e-mail exchange to be on list (should really learn to read the To: list before sending :-) ) -- Rob ---------- Forwarded message ---------- From: Robert Godfrey Date: 6 May 2010 12:35 Subject: Re: [rabbitmq-discuss] request for help! To: Martin Sustrik Oops - just noticed that this mail only went to you and not the Rabbit list... would you be OK if I posted it back onto the list - which was my original intent? Som more comments in-line below: On 6 May 2010 12:16, Martin Sustrik wrote: > > Hi Rob, > >> On 6 May 2010 10:11, Martin Sustrik > wrote: >> >>> ? ?Great you are bringing this to the public attention! >>> >>> ? ?We've discussed this before, so I'm going to repeat myself for the sake >>> ? ?of people on the mailing list... >>> >>> ? ? From my point of view there are two crucial issues with AMQP/1.0: >>> >>> ? ?1. Messy layering. Almost every concept is discussed at multiple places. >>> ? ?It's very hard to understand the specification in its current form. (To >>> ? ?be fair, one piece is nicely and consistently separated. The codec.) >> >> >> Would be glad to understand this comment in more detail. ?At least >> conceptually I think the layering in 1-0 is a lot better defined with >> concerns separated than in previous versions. ?Are your concerns >> around the ?model, or the documentation of it? > > It's much better than it used to be. Anyway, I volunteer to help with this. > My idea is to start with moving pieces of the specification around to make > it easier to follow without changing the wire protocol. Will get in touch with > you shortly! > >>> ? ?2. Assumption that messages are stored on the node in unordered fashion >>> ? ?shifts AMQP from being message queueing protocol to being database >>> ? ?protocol. This blurs AMQP's mission, makes it compete with SQL and >>> ? ?causes implementation to be extremely costly and complex. We should >>> ? ?follow the good old "do one thing and do it well" principle and focus on >>> ? ?defining MQ behaviour rather than DB behaviour. >> >> >> It's not that we assume the messages are unordered at the node... but that >> the *transport* makes *no* assumptions about message ordering within a >> node (because it doesn't need to). ?It would be perfectly valid for an >> implementation to be built with nodes that store messages strictly in order >> - and that's certainly how I expect most "Queues" inside "Brokers" to work >> (having said that we already see things in AMQP implementations such >> as priority queues, last value queues, etc. that violate this notion of "strict" >> ordering). > > It's wider than ordering alone. Node with unordered messages is basically a > database table. A Node with unordered messages would be some sort of Bag I would think... Unlike a DB table there would be no natural notion of a primary key, or necessarily any notion of a way to select the messages (though I guess the node *may* support certain AMQP1-0 filter types). Again, there is no requirement on implementers to write such a Node type (unless Michael has secretly put that in the document he is currently writing ;-) )... All that the core spec is doing is saying is "it's perfectly valid to have nodes that give FIFO ordering, LIFO ordering, or any other (non-)ordering you like".? This is actually removing a burden on implementers rather than adding one (although the requirement for the same sort of pseudo-FIFO that 0-x requires will probably also be a requirement for AMQP 1-0 *Brokers*). > > However, there are also other DB concepts in the spec. Say a concept of > non-destructive link -- which boils down to a SELECT statement. Or, say, > it seems implied that a message cannot silently disappear from a node > same way as record cannot silently disappear from a DB table. There is absolutely no intent to prevent a node from silently "disappearing" a message that it is holding.? All that "non-destructive" means is that the act of sending the message to the receiver does not in itself cause the message to be "disappeared". The two major use cases this functionality is designed for are Queue "browsing" (i.e. the ability to look at what is in your queue without consuming the messages) and the ability to implement "Topics" as a single entity (rather than the AMQP 0-x way of having a queue per consumer).? The Topic case is potentially more interesting as a Topic node would have a policy that says "when all connected consumers have moved beyond a message in the *ordered* Topic, then the message may be deleted".? This obviously requires some notion of ordering at the (Topic) node.? Having implemented this functionality elsewhere, it certainly doesn't require a database table like data-structure - all it requires is that you hold pointers into the queue. > > Compare this witch 0-9 exchanges where message is dropped when it > cannot be routed. Etc. ?My belief is that an 0-x exchange would be a perfectly valid node in AMQP. >> Subsequent pieces of the AMQP specification will define the required >> node types that need to be supported by applications acting as >> "AMQP Brokers". ?Michael may be able to talk more to that as that's >> his area of responsibility :-) hope this helps, Rob From emile at rabbitmq.com Thu May 6 12:23:56 2010 From: emile at rabbitmq.com (Emile Joubert) Date: Thu, 06 May 2010 12:23:56 +0100 Subject: [rabbitmq-discuss] Unbinding when not bound In-Reply-To: <001301caec9f$dc4ed6f0$94ec84d0$@com> References: <001301caec9f$dc4ed6f0$94ec84d0$@com> Message-ID: <4BE2A6CC.4080904@rabbitmq.com> Hi Roaan, The broker is required to raise a connection exception if an unbind fails, so you are witnessing expected behaviour. Duplicate bindings will be ignored, so you can prevent the exception by performing a (possibly duplicate) binding immediately prior to unbind. The client is expected to keep track of bindings under normal circumstances though. I assume this is impossible in your case - can you explain why? -Emile Roaan Vos wrote: > Hi, > > > > I currently allow clients to ?bind? and ?unbind? to various topics as > needed using the .net client. > > However, when the client ?unbinds? without first having done a bind, > RabbitMQ throws an exception and the connection seems to disappear. > > Is there a way for it to keep the connection (or not throw an exception)? > > > > Thanks > > > > Roaan > > > ------------------------------------------------------------------------ > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From sustrik at 250bpm.com Thu May 6 12:34:27 2010 From: sustrik at 250bpm.com (Martin Sustrik) Date: Thu, 06 May 2010 13:34:27 +0200 Subject: [rabbitmq-discuss] request for help! In-Reply-To: References: <4BE279C3.6020903@250bpm.com> <4BE2970B.9070208@250bpm.com> Message-ID: <4BE2A943.6070305@250bpm.com> Hi Rob, First of all I would like to define what's MQ and what's DB. It'll be helpful to get the discussion more focused IMO: With DB data are long-lived while queries are transient one-off events. With MQ data are transient one-off events while queries are stable long-lived entities. Terminology: Data = record (DB) = message (MQ) Query = SQL statement (DB) = subscription (MQ) >> It's wider than ordering alone. Node with unordered messages is basically a >> database table. > > A Node with unordered messages would be some sort of Bag I would > think... Unlike a DB table there would be no natural notion of a > primary key, or necessarily any notion of a way to select the messages > (though I guess the node *may* support certain AMQP1-0 filter types). > Again, there is no requirement on implementers to write such a Node > type (unless Michael has secretly put that in the document he is > currently writing ;-) )... All that the core spec is doing is saying > is "it's perfectly valid to have nodes that give FIFO ordering, LIFO > ordering, or any other (non-)ordering you like". This is actually > removing a burden on implementers rather than adding one (although the > requirement for the same sort of pseudo-FIFO that 0-x requires will > probably also be a requirement for AMQP 1-0 *Brokers*). Yes. Explicitly not defining how the messages are stored and leaving it to layer above is perfectly valid approach. However, it should be done more consistently, see below... >> However, there are also other DB concepts in the spec. Say a concept of >> non-destructive link -- which boils down to a SELECT statement. Or, say, >> it seems implied that a message cannot silently disappear from a node >> same way as record cannot silently disappear from a DB table. > > There is absolutely no intent to prevent a node from silently > "disappearing" a message that it is holding. All that > "non-destructive" means is that the act of sending the message to the > receiver does not in itself cause the message to be "disappeared". > The two major use cases this functionality is designed for are Queue > "browsing" (i.e. the ability to look at what is in your queue without > consuming the messages) and the ability to implement "Topics" as a > single entity (rather than the AMQP 0-x way of having a queue per > consumer). The Topic case is potentially more interesting as a Topic > node would have a policy that says "when all connected consumers have > moved beyond a message in the *ordered* Topic, then the message may be > deleted". This obviously requires some notion of ordering at the > (Topic) node. Having implemented this functionality elsewhere, it > certainly doesn't require a database table like data-structure - all > it requires is that you hold pointers into the queue. Let me give you just one example of what problems we are facing here: Destructive vs. non-destructive semantics break "stability" of message dispatch algorithm. In other words, which messages you get is not fully determined by your subscription, rather it depends on ordering of subscriptions in the broker. If destructive subscription is matched first, non-destructive subscription won't get the message. If they are matched in reverse order, both get the message. You do expect such behaviour with DB system -- ordering of SQL statements effects the results -- however, you don't want it to happen with MQ system. My suggestion would be to stretch the abstraction of ignoring the internal node state/algorithms to fully cover the node behaviour: 1. Node is a named endpoint for links and that's it. 2. There's no concept of message being resident on a node. 3. There's no message ordering defined. This follows from the above. 4. There's no message state machine. This follows from 2. 3. There are no destructive/non-destructive links, just "links". Adopting the points above would make core specification much cleaner. The burden of defining storage/ordering/routing etc. is left to "broker behaviour" specification. Martin From alexis at rabbitmq.com Thu May 6 12:44:38 2010 From: alexis at rabbitmq.com (Alexis Richardson) Date: Thu, 6 May 2010 12:44:38 +0100 Subject: [rabbitmq-discuss] request for help! In-Reply-To: References: Message-ID: Davorin On Thu, May 6, 2010 at 10:21 AM, Davorin Rusevljan wrote: > I hope you do not mind beginner "how would I xxx in amqp1.0" type questions. We do not mind at all! alexis > They are not direct comments on the standard specs, but maybe some of them > could eventually lead to the points that could be better explained, so > answering them might not be a complete waste of time. (but if you do mind > please let me know so that I can stop). > > So, as far as I see consumer issues a credits to the link, and if I am > reading it correctly, it can stop the delivery of the messages to him that > way. Now is there a way (automatic or programmed) for a broker or producer > to get rid of the consumer if the number of messages awaiting for him to > consume gets to high? Motivation for that would be preventing some ill > intended client from DOSing the producer broker by forcing it to store large > number of messages. > > Thanks! > > davorin rusevljan > http://www.cloud208.com/ > > From matthias at rabbitmq.com Thu May 6 13:14:17 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Thu, 06 May 2010 13:14:17 +0100 Subject: [rabbitmq-discuss] Unbinding when not bound In-Reply-To: <4BE2A6CC.4080904@rabbitmq.com> References: <001301caec9f$dc4ed6f0$94ec84d0$@com> <4BE2A6CC.4080904@rabbitmq.com> Message-ID: <4BE2B299.2060807@rabbitmq.com> Emile Joubert wrote: > The broker is required to raise a connection exception if an unbind > fails, so you are witnessing expected behaviour. That is actually a wart in AMQP. Exchange, queue and binding declaration are idempotent - which is a good thing - but the corresponding destructive operations are not. Also, there is an inconsistency here between unbind and, say, queue and exchange deletion. The latter raise 404 *channel* error when the mentioned resources do not exist. But the unbind is required to raise a connection error under similar conditions. Matthias. From rob.j.godfrey at gmail.com Thu May 6 13:51:08 2010 From: rob.j.godfrey at gmail.com (Robert Godfrey) Date: Thu, 6 May 2010 14:51:08 +0200 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE2A943.6070305@250bpm.com> References: <4BE279C3.6020903@250bpm.com> <4BE2970B.9070208@250bpm.com> <4BE2A943.6070305@250bpm.com> Message-ID: Thanks for your reply - comments inline below On 6 May 2010 13:34, Martin Sustrik wrote: > Hi Rob, > > First of all I would like to define what's MQ and what's DB. It'll be > helpful to get the discussion more focused IMO: > > With DB data are long-lived while queries are transient one-off events. > > I think this is a slight over-simplification. AMQP aims to provide store and forward messaging where "store" is an important part of that equation. The storage may be transitory or it may be relatively long lived (I've just been dealing with a situation where messages had been sitting in a queue for several weeks, quite legitimately). Any notion of "queuing" is implicitly going to rely on some sort of storage: the queue. Some use cases of Messaging (in particular low-latency data distribution) may want to avoid queuing and simply drop messages that cannot be consumed immediately. While this is not the use case AMQP is designed for, it can conceivably still be used in this way. not that it is not a requirement for every node to support every distribution mode - moreover > With MQ data are transient one-off events while queries are stable > long-lived entities. > > Terminology: > > Data = record (DB) = message (MQ) > Query = SQL statement (DB) = subscription (MQ) > > > It's wider than ordering alone. Node with unordered messages is basically >>> a >>> database table. >>> >> >> A Node with unordered messages would be some sort of Bag I would >> think... Unlike a DB table there would be no natural notion of a >> primary key, or necessarily any notion of a way to select the messages >> (though I guess the node *may* support certain AMQP1-0 filter types). >> Again, there is no requirement on implementers to write such a Node >> type (unless Michael has secretly put that in the document he is >> currently writing ;-) )... All that the core spec is doing is saying >> is "it's perfectly valid to have nodes that give FIFO ordering, LIFO >> ordering, or any other (non-)ordering you like". This is actually >> removing a burden on implementers rather than adding one (although the >> requirement for the same sort of pseudo-FIFO that 0-x requires will >> probably also be a requirement for AMQP 1-0 *Brokers*). >> > > Yes. Explicitly not defining how the messages are stored and leaving it to > layer above is perfectly valid approach. However, it should be done more > consistently, see below... > > > However, there are also other DB concepts in the spec. Say a concept of >>> non-destructive link -- which boils down to a SELECT statement. Or, say, >>> it seems implied that a message cannot silently disappear from a node >>> same way as record cannot silently disappear from a DB table. >>> >> >> There is absolutely no intent to prevent a node from silently >> "disappearing" a message that it is holding. All that >> "non-destructive" means is that the act of sending the message to the >> receiver does not in itself cause the message to be "disappeared". >> The two major use cases this functionality is designed for are Queue >> "browsing" (i.e. the ability to look at what is in your queue without >> consuming the messages) and the ability to implement "Topics" as a >> single entity (rather than the AMQP 0-x way of having a queue per >> consumer). The Topic case is potentially more interesting as a Topic >> node would have a policy that says "when all connected consumers have >> moved beyond a message in the *ordered* Topic, then the message may be >> deleted". This obviously requires some notion of ordering at the >> (Topic) node. Having implemented this functionality elsewhere, it >> certainly doesn't require a database table like data-structure - all >> it requires is that you hold pointers into the queue. >> > > Let me give you just one example of what problems we are facing here: > Destructive vs. non-destructive semantics break "stability" of message > dispatch algorithm. In other words, which messages you get is not fully > determined by your subscription, rather it depends on ordering of > subscriptions in the broker. If destructive subscription is matched first, > non-destructive subscription won't get the message. If they are matched in > reverse order, both get the message. You do expect such behaviour with DB > system -- ordering of SQL statements effects the results -- however, you > don't want it to happen with MQ system. > > If you use destructive links at all then obviously (and correctly) which messages are sent to which consumers will depend completely on the order in which the node offers the messages to the links. This is the epected behaviour for queues. For instance a shared work queue Q with consumers A, B and C ... when a message M enters the queue it is the choice of the node which of the A, B, or C it offers the message to - the other two will never see it. So I disagree that this is not expected behaviour in Messaging. What you seem to be describing above is "routing" where there is no storage capability. > > My suggestion would be to stretch the abstraction of ignoring the internal > node state/algorithms to fully cover the node behaviour: > > 1. Node is a named endpoint for links and that's it. > > 2. There's no concept of message being resident on a node. > > 3. There's no message ordering defined. This follows from the above. > > 4. There's no message state machine. This follows from 2. > > 3. There are no destructive/non-destructive links, just "links". > > I believe the spec already separates out these concerns into separate layers in a way which I think generally matches your categorization. Each Book in the spec represents an independent layer (with the exception of the first book which is there to provide a gentle introduction to the concepts). To the Transport Layer (Book III) links are between link endpoints - there is no concept of message residence, ordering, or a state machine. This is what you are describing above I think. Book IV, the Messaging Layer defines a particular form for describing the link endpoints. This defines a scheme for identifying whether you wish to take the messages from the sender (acquire/destructive) or simply look at the messages with taking them (browse/non-destructive). This is also the layer where we define how to request durability of the message, allow for the assigning of priorities, etc. This behaviour should be common to more than just "brokers" but also available in other AMQP intermediaries respecting the same Messaging layer. > Adopting the points above would make core specification much cleaner. The > burden of defining storage/ordering/routing etc. is left to "broker > behaviour" specification. > > Broker Behaviour will define a concrete set of capabilities that something calling itself an "AMQP Broker" MUST provide. In effect it is documenting constraints on the implementer as to the minimum features they must provide through the Messaging Layer. Even within a container which implements the Messaging Layer as described in Book IV, not every node need support all the options - it is expected that each node will support only certain messaging patterns. For example a node that implements only "routing" and not storage of any kind (something a bit like an 0-x Exchange) would not support mixing distribution modes I imagine - either it would only allow non-destructive distribution (acting as a fanout- every message goes to every consumer) or only allow destructive distribution (acting as a switch - each message goes to the first/only consumer that can take it... or is dropped if there is no such consumer). As an aside, the names destructive/non-destructive could probably be improved upon 9as they don't really properly capture the implied meaning) - but no-one has yet come up with terms that can be universally agreed upon :-) Hope this is making things a bit clearer -- Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100506/f4f5614d/attachment-0001.htm From contact at a-net-user.com Thu May 6 13:52:57 2010 From: contact at a-net-user.com (Roaan Vos) Date: Thu, 6 May 2010 14:52:57 +0200 Subject: [rabbitmq-discuss] Unbinding when not bound In-Reply-To: <4BE2A607.9000500@rabbitmq.com> References: <001301caec9f$dc4ed6f0$94ec84d0$@com> <4BE2A607.9000500@rabbitmq.com> Message-ID: Hi, On second thought, I don't think that will work. If I first do the binding, the client will likely receive data he didn't intend before being able to remove the binding. Since consuming messages off of the queue is happening asynchronously, while the bind/unbind happens on a different connection I think the above is quite possible. Thanks Roaan On 6 May 2010 13:20, Emile Joubert wrote: > > Hi Roaan, > > The broker is required to raise a connection exception if an unbind fails, > so you are describing expected behaviour. > > Duplicate bindings will be ignored, so you can prevent the exception by > performing a (possibly duplicate) binding immediately prior to unbind. > > The client is expected to keep track of bindings under normal circumstances > though. I assume this is impossible in your case - can you explain why? > > -Emile > > Roaan Vos wrote: > >> Hi, >> >> >> I currently allow clients to ?bind? and ?unbind? to various topics as >> needed using the .net client. >> >> However, when the client ?unbinds? without first having done a bind, >> RabbitMQ throws an exception and the connection seems to disappear. >> >> Is there a way for it to keep the connection (or not throw an exception)? >> >> >> Thanks >> >> >> Roaan >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100506/66373f3a/attachment.htm From rob.j.godfrey at gmail.com Thu May 6 13:53:22 2010 From: rob.j.godfrey at gmail.com (Robert Godfrey) Date: Thu, 6 May 2010 14:53:22 +0200 Subject: [rabbitmq-discuss] request for help! In-Reply-To: References: Message-ID: Hi Davorin On 6 May 2010 11:21, Davorin Rusevljan wrote: > I hope you do not mind beginner "how would I xxx in amqp1.0" type > questions. They are not direct comments on the standard specs, but maybe > some of them could eventually lead to the points that could be better > explained, so answering them might not be a complete waste of time. (but if > you do mind please let me know so that I can stop). > > So, as far as I see consumer issues a credits to the link, and if I am > reading it correctly, it can stop the delivery of the messages to him that > way. Now is there a way (automatic or programmed) for a broker or producer > to get rid of the consumer if the number of messages awaiting for him to > consume gets to high? Motivation for that would be preventing some ill > intended client from DOSing the producer broker by forcing it to store large > number of messages. > > The sender of messages should be able to indicate that despite the fact that, while the receiver of messages has issued credit, the sender will not send more until the receiver has acknowledged some of the existing outstanding messages. Thus the receiver can make the choice as to whether it wants to receive more messages - in which case it needs to acknowledge some of those it is holding on to (thus allowing the sender to delete them), or whether it wishes to continue working with the messages it has. In general there is no obligation for the sender to send even if credit has been supplied - but it should indicate through its state it is choosing not to send because there is too much unresolved state already, not because there are no messages to send. At first glance it looks like the documentation for this case is missing from the spec - thanks for pointing this out, and well spotted! Also note that at any time the sender may chose to unilaterally disconnect the link, session or even the connection with an appropriate error code (for instance there may be a policy to do so with "slow" consumers who are preventing messages being garbage collected from a "Topic" node). Hope this helps, Rob > Thanks! > > davorin rusevljan > http://www.cloud208.com/ > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100506/19572ab9/attachment.htm From sustrik at 250bpm.com Thu May 6 14:18:09 2010 From: sustrik at 250bpm.com (Martin Sustrik) Date: Thu, 06 May 2010 15:18:09 +0200 Subject: [rabbitmq-discuss] request for help! In-Reply-To: References: <4BE279C3.6020903@250bpm.com> <4BE2970B.9070208@250bpm.com> <4BE2A943.6070305@250bpm.com> Message-ID: <4BE2C191.5030402@250bpm.com> Robert Godfrey wrote: > Let me give you just one example of what problems we are facing > here: Destructive vs. non-destructive semantics break "stability" of > message dispatch algorithm. In other words, which messages you get > is not fully determined by your subscription, rather it depends on > ordering of subscriptions in the broker. If destructive subscription > is matched first, non-destructive subscription won't get the > message. If they are matched in reverse order, both get the message. > You do expect such behaviour with DB system -- ordering of SQL > statements effects the results -- however, you don't want it to > happen with MQ system. > > > If you use destructive links at all then obviously (and correctly) which > messages are sent to which consumers will depend completely on the order > in which the node offers the messages to the links. This is the epected > behaviour for queues. For instance a shared work queue Q with consumers > A, B and C ... when a message M enters the queue it is the choice of the > node which of the A, B, or C it offers the message to - the other two > will never see it. So I disagree that this is not expected behaviour in > Messaging. What you seem to be describing above is "routing" where > there is no storage capability. Let me give an example: Say you have a non-destructive an destructive links attached to a node. When you process a message at the node, the non-destructive link gets either all the messages (if the matching for the destructive link is done after matching for the non-destructive one), or no messages (if the matching for the destructive link is done before matching for the non-destructive one) or random subset of messages (if some form of load-balancing among links is done). All in all, client has no guarantee of which messages it'll get or whether it'll get at least some messages. In other words, one misbehaved client can render all the other clients non-functional. Martin From mikeb at lshift.net Thu May 6 15:03:21 2010 From: mikeb at lshift.net (Michael Bridgen) Date: Thu, 06 May 2010 15:03:21 +0100 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE2C191.5030402@250bpm.com> References: <4BE279C3.6020903@250bpm.com> <4BE2970B.9070208@250bpm.com> <4BE2A943.6070305@250bpm.com> <4BE2C191.5030402@250bpm.com> Message-ID: <4BE2CC29.2050101@lshift.net> >> Let me give you just one example of what problems we are facing >> here: Destructive vs. non-destructive semantics break "stability" of >> message dispatch algorithm. In other words, which messages you get >> is not fully determined by your subscription, rather it depends on >> ordering of subscriptions in the broker. If destructive subscription >> is matched first, non-destructive subscription won't get the >> message. If they are matched in reverse order, both get the message. >> You do expect such behaviour with DB system -- ordering of SQL >> statements effects the results -- however, you don't want it to >> happen with MQ system. >> >> >> If you use destructive links at all then obviously (and correctly) which >> messages are sent to which consumers will depend completely on the order >> in which the node offers the messages to the links. This is the epected >> behaviour for queues. For instance a shared work queue Q with consumers >> A, B and C ... when a message M enters the queue it is the choice of the >> node which of the A, B, or C it offers the message to - the other two >> will never see it. So I disagree that this is not expected behaviour in >> Messaging. What you seem to be describing above is "routing" where >> there is no storage capability. > > Let me give an example: > > Say you have a non-destructive an destructive links attached to a node. > When you process a message at the node, the non-destructive link gets > either all the messages (if the matching for the destructive link is > done after matching for the non-destructive one), or no messages (if the > matching for the destructive link is done before matching for the > non-destructive one) or random subset of messages (if some form of > load-balancing among links is done). All in all, client has no guarantee > of which messages it'll get or whether it'll get at least some messages. > > In other words, one misbehaved client can render all the other clients > non-functional. I understand that there's a desire to accommodate e.g., JMS-like semantics (which I can see may have been a motivating force for "distribution mode"). But I think the core spec can leave room for those, without taking a position otherwise. What the spec does at the minute is to have a model that tries to encompass all possibilities, where it ought to be silent. The main problem with the "all possibilities" approach is that it infects other layers. For example, the distribution modes and message state model make flow control, transactions, responsibility transfer and reliable delivery all interdependent. In my opinion these can be teased apart; specifically (but probably not exclusively), by distinguishing between delivery acknowledgement and transfer of responsibility. (Conflating those causes problems in 0-9-1 too by the way -- there's a rather fraught, unresolved question in RabbitMQ's bugzilla about the interaction between flow control and transactional acks. The last comment says "In conclusion, after discussion, acks are overloaded, and mean two things - 1. I've seen the msg; 2. forget about the msg. ...") Michael. From sustrik at 250bpm.com Thu May 6 15:07:42 2010 From: sustrik at 250bpm.com (Martin Sustrik) Date: Thu, 06 May 2010 16:07:42 +0200 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE2CC29.2050101@lshift.net> References: <4BE279C3.6020903@250bpm.com> <4BE2970B.9070208@250bpm.com> <4BE2A943.6070305@250bpm.com> <4BE2C191.5030402@250bpm.com> <4BE2CC29.2050101@lshift.net> Message-ID: <4BE2CD2E.3040200@250bpm.com> Michael Bridgen wrote: > (Conflating those causes problems in 0-9-1 too by the way -- there's a > rather fraught, unresolved question in RabbitMQ's bugzilla about the > interaction between flow control and transactional acks. The last > comment says "In conclusion, after discussion, acks are overloaded, and > mean two things - 1. I've seen the msg; 2. forget about the msg. ...") Can you point me to that issue? Thanks. Martin From emile at rabbitmq.com Thu May 6 15:24:39 2010 From: emile at rabbitmq.com (Emile Joubert) Date: Thu, 06 May 2010 15:24:39 +0100 Subject: [rabbitmq-discuss] Unbinding when not bound In-Reply-To: References: <001301caec9f$dc4ed6f0$94ec84d0$@com> <4BE2A607.9000500@rabbitmq.com> Message-ID: <4BE2D127.9080801@rabbitmq.com> Hi Roaan, If you are concerned about receiving messages asynchronously between binding and unbinding the queue then you could cancel the subscription first. Be aware that messages may still end up in the queue, even if they are not delivered. It would of course be preferable to avoid the entire sequence (cancel subscription, bind, unbind) if there was no binding in the first place. Another approach is to allow the exception to occur and recover from it by re-establishing the connection. -Emile Roaan Vos wrote: > Hi, > > On second thought, I don't think that will work. > > If I first do the binding, the client will likely receive data he didn't > intend before being able to remove the binding. > > Since consuming messages off of the queue is happening asynchronously, > while the bind/unbind happens on a different connection I think the > above is quite possible. > > Thanks > > Roaan > > > On 6 May 2010 13:20, Emile Joubert > wrote: > > > Hi Roaan, > > The broker is required to raise a connection exception if an unbind > fails, so you are describing expected behaviour. > > Duplicate bindings will be ignored, so you can prevent the exception > by performing a (possibly duplicate) binding immediately prior to > unbind. > > The client is expected to keep track of bindings under normal > circumstances though. I assume this is impossible in your case - can > you explain why? > > -Emile > > Roaan Vos wrote: > > Hi, > > > I currently allow clients to ?bind? and ?unbind? to various > topics as needed using the .net client. > > However, when the client ?unbinds? without first having done a > bind, RabbitMQ throws an exception and the connection seems to > disappear. > > Is there a way for it to keep the connection (or not throw an > exception)? > > > Thanks > > > Roaan > > > ------------------------------------------------------------------------ > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From mikeb at lshift.net Thu May 6 15:55:10 2010 From: mikeb at lshift.net (Michael Bridgen) Date: Thu, 06 May 2010 15:55:10 +0100 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE2CD2E.3040200@250bpm.com> References: <4BE279C3.6020903@250bpm.com> <4BE2970B.9070208@250bpm.com> <4BE2A943.6070305@250bpm.com> <4BE2C191.5030402@250bpm.com> <4BE2CC29.2050101@lshift.net> <4BE2CD2E.3040200@250bpm.com> Message-ID: <4BE2D84E.4040006@lshift.net> Martin Sustrik wrote: > Michael Bridgen wrote: > >> (Conflating those causes problems in 0-9-1 too by the way -- there's a >> rather fraught, unresolved question in RabbitMQ's bugzilla about the >> interaction between flow control and transactional acks. The last >> comment says "In conclusion, after discussion, acks are overloaded, >> and mean two things - 1. I've seen the msg; 2. forget about the msg. >> ...") > > Can you point me to that issue? Sadly, it's behind a firewall at the minute; but here is the list post that gave rise to it: http://old.nabble.com/Re%3A-MulticastMain-Java-client-causes-Erlang-error-eheap_alloc%3A-Cannot-allocate-467078560-bytes-of-memory-%28of%09type-%22heap%22%29-%28with-RabbitMQ-1.7.1%29-p27311987.html From kenneth at loafman.com Thu May 6 15:59:39 2010 From: kenneth at loafman.com (Kenneth Loafman) Date: Thu, 06 May 2010 09:59:39 -0500 Subject: [rabbitmq-discuss] Deleting Queues, How? Message-ID: <4BE2D95B.2090103@loafman.com> Hi, I've got some queues that were created as permanent on a fanout exchange that should have been created as temporary (exclusive=True). I'm trying to find a way to delete them since they are slowly filiing up. Is there a utility out there that will give me a way to do this, or must I shut down RabbitMQ and restart the world? ...Thanks, ...Ken From rafaels at redhat.com Thu May 6 16:10:00 2010 From: rafaels at redhat.com (Rafael Schloming) Date: Thu, 06 May 2010 11:10:00 -0400 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE279C3.6020903@250bpm.com> References: <4BE279C3.6020903@250bpm.com> Message-ID: <4BE2DBC8.1000004@redhat.com> Martin Sustrik wrote: > Alexis, > >> As part of an ongoing drive to "be more open" as well as to "get to >> 1.0" the AMQP Working Group has published the 1-0 PR3 draft on the >> webs for Public Comment: >> http://www.amqp.org/confluence/download/attachments/2523279/amqp_1-0_PR3.pdf > > Great you are bringing this to the public attention! > > We've discussed this before, so I'm going to repeat myself for the sake > of people on the mailing list... > > From my point of view there are two crucial issues with AMQP/1.0: > > 1. Messy layering. Almost every concept is discussed at multiple places. > It's very hard to understand the specification in its current form. (To > be fair, one piece is nicely and consistently separated. The codec.) A bit more detail would help on this point. I suspect at least some of this impression is due to the organization of the information as opposed to the technical layering, and specifics would help tease that out. > 2. Assumption that messages are stored on the node in unordered fashion > shifts AMQP from being message queueing protocol to being database > protocol. This blurs AMQP's mission, makes it compete with SQL and > causes implementation to be extremely costly and complex. We should > follow the good old "do one thing and do it well" principle and focus on > defining MQ behaviour rather than DB behaviour. This isn't our intention with nodes. We're certainly not trying to say that you MUST assume every kind of node stores all messages in an unordered way. What we're trying to say is that the messaging protocol doesn't actually need to know anything at all about the internal behavior of a node in order to ship messages to/from it. A node might behave as a strict FIFO queue, or it might be a producer that generates messages whenever the moon is full. Either way, the details are irrelevant to the process of transferring that message across the wire. So in a real sense we're trying to say as little as possible about nodes in general. I think this is actually an example of strong layering and makes the protocol very easy to implement as it is equally easy to retrofit it to something that stores messages for archival vs something that stores messages for distribution (or indeed something that doesn't even store messages at all). Additionally the symmetric nature of the protocol requires that we be very careful about what we require of nodes in general since there is a node at both ends of any link, which generally means the first and last nodes in any path through the AMQP network are client applications which can obviously behave in any way they like. If you look at how the term "node" is used throughout the transport, you'll see that in some sense it's really just a synonym for whatever application happens to be using the messaging protocol, whether that application is a queue inside a broker or some part of a client library. I think where this does start getting a bit confused is in the messaging book where the term "node" is used in a more specific sense to refer to a certain kind of entity within a broker-like container. This area should probably define more specific terms to talk about these more specific kinds of node. Overall I think your concerns about implementation complexity are more related to how we define the specific types of nodes that constitute the required set to be considered an "AMQP Broker", and this is not something that the core protocol itself defines. --Rafael From videlalvaro at gmail.com Thu May 6 16:19:47 2010 From: videlalvaro at gmail.com (Alvaro Videla) Date: Thu, 6 May 2010 23:19:47 +0800 Subject: [rabbitmq-discuss] Deleting Queues, How? In-Reply-To: <4BE2D95B.2090103@loafman.com> References: <4BE2D95B.2090103@loafman.com> Message-ID: <12EEB267-9F45-4614-881D-E93F82A277FA@gmail.com> Your library should implement a method called queue_delete('queue_name'); or something similar according to the language. -Alvaro On May 6, 2010, at 10:59 PM, Kenneth Loafman wrote: > Hi, > > I've got some queues that were created as permanent on a fanout exchange > that should have been created as temporary (exclusive=True). I'm trying > to find a way to delete them since they are slowly filiing up. Is there > a utility out there that will give me a way to do this, or must I shut > down RabbitMQ and restart the world? > > ...Thanks, > ...Ken > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From rafaels at redhat.com Thu May 6 16:28:16 2010 From: rafaels at redhat.com (Rafael Schloming) Date: Thu, 06 May 2010 11:28:16 -0400 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE2A943.6070305@250bpm.com> References: <4BE279C3.6020903@250bpm.com> <4BE2970B.9070208@250bpm.com> <4BE2A943.6070305@250bpm.com> Message-ID: <4BE2E010.2000409@redhat.com> Martin Sustrik wrote: > Hi Rob, > > First of all I would like to define what's MQ and what's DB. It'll be > helpful to get the discussion more focused IMO: > > With DB data are long-lived while queries are transient one-off events. > > With MQ data are transient one-off events while queries are stable > long-lived entities. I would use the term filter in this context. Queries can generally do more advanced things like joins and sub queries which don't make sense in the context of live data feeds. Filtering that is the subset of querying that is common to both archived data and live data feeds. > My suggestion would be to stretch the abstraction of ignoring the > internal node state/algorithms to fully cover the node behaviour: > > 1. Node is a named endpoint for links and that's it. > > 2. There's no concept of message being resident on a node. > > 3. There's no message ordering defined. This follows from the above. > > 4. There's no message state machine. This follows from 2. > > 3. There are no destructive/non-destructive links, just "links". > > Adopting the points above would make core specification much cleaner. > The burden of defining storage/ordering/routing etc. is left to "broker > behaviour" specification. I believe this is the intention, and I think we're pretty consistent about this up until the messaging book where we start using the term node in a narrower way. I think we would benefit from introducing some terms like "[lossy] repeaters" to define some broad classes of specialized nodes and adjust some of the content in the messaging book to use those terms instead of talking about nodes in a way that narrows the meaning of the term. I think from there the broker behavior specification could further define the specialized behaviors of queues, topics, etc. --Rafael From simon at rabbitmq.com Thu May 6 17:02:06 2010 From: simon at rabbitmq.com (Simon MacMullen) Date: Thu, 06 May 2010 17:02:06 +0100 Subject: [rabbitmq-discuss] Deleting Queues, How? In-Reply-To: <12EEB267-9F45-4614-881D-E93F82A277FA@gmail.com> References: <4BE2D95B.2090103@loafman.com> <12EEB267-9F45-4614-881D-E93F82A277FA@gmail.com> Message-ID: <4BE2E7FE.4020506@rabbitmq.com> I'm afraid that writing a small app to do this is the only option. The BQL plugin (http://www.rabbitmq.com/rabbitmq-bql.html) has a "drop queue" command, but you won't be able to get BQL installed without restarting RabbitMQ. At some point we'd like to write a command line client for ad hoc use and scripting. Time is, as usual, the problem... Cheers, Simon On 06/05/10 16:19, Alvaro Videla said: > Your library should implement a method called > queue_delete('queue_name'); or something similar according to the > language. > > -Alvaro On May 6, 2010, at 10:59 PM, Kenneth Loafman wrote: > >> Hi, >> >> I've got some queues that were created as permanent on a fanout >> exchange that should have been created as temporary >> (exclusive=True). I'm trying to find a way to delete them since >> they are slowly filiing up. Is there a utility out there that will >> give me a way to do this, or must I shut down RabbitMQ and restart >> the world? >> >> ...Thanks, ...Ken >> >> _______________________________________________ rabbitmq-discuss >> mailing list rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > >> > > _______________________________________________ rabbitmq-discuss > mailing list rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss -- Simon MacMullen Staff Engineer, RabbitMQ SpringSource, a division of VMware From rafaels at redhat.com Thu May 6 17:04:50 2010 From: rafaels at redhat.com (Rafael Schloming) Date: Thu, 06 May 2010 12:04:50 -0400 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE2CC29.2050101@lshift.net> References: <4BE279C3.6020903@250bpm.com> <4BE2970B.9070208@250bpm.com> <4BE2A943.6070305@250bpm.com> <4BE2C191.5030402@250bpm.com> <4BE2CC29.2050101@lshift.net> Message-ID: <4BE2E8A2.9090602@redhat.com> Michael Bridgen wrote: > I understand that there's a desire to accommodate e.g., JMS-like > semantics (which I can see may have been a motivating force for > "distribution mode"). But I think the core spec can leave room for > those, without taking a position otherwise. > > What the spec does at the minute is to have a model that tries to > encompass all possibilities, where it ought to be silent. I don't think this is really related to JMS at all. If you accept that certain kinds of nodes store messages, then it generally makes sense that you would want to be able to inspect the messages stored at a node without actually destroying them. Now JMS does require this capability with the notion of "queue browsing", however we could easily define a way to create this sort of link in the JMS Mapping via the extension points in sources, however that would be incorrect as that would be assuming that JMS is the only API in the world that wants to provide this capability, it therefore makes sense to have a standard way to request non-destructive access to stored messages that sits somewhere outside the JMS Mapping. Note that this is *not* requiring every node that stores messages to support non-destructive access, it merely says if you *do* support non-destructive access, here is a standard way to expose that capability. > The main problem with the "all possibilities" approach is that it > infects other layers. > > For example, the distribution modes and message state model make flow > control, transactions, responsibility transfer and reliable delivery all > interdependent. In my opinion these can be teased apart; specifically > (but probably not exclusively), by distinguishing between delivery > acknowledgement and transfer of responsibility. Can you explain this a bit more? In PR3, flow control and acknowledgment are independent in that you can ack messages without causing more to arrive, and you can cause more to arrive without acking. Is there some other sense of interdependence that you mean here? > (Conflating those causes problems in 0-9-1 too by the way -- there's a > rather fraught, unresolved question in RabbitMQ's bugzilla about the > interaction between flow control and transactional acks. The last > comment says "In conclusion, after discussion, acks are overloaded, and > mean two things - 1. I've seen the msg; 2. forget about the msg. ...") I don't see how (1) is ever semantically meaningful to communicate. In the context of a transaction an ack isn't actually saying (1), it's generally saying something like "forget about this message when the transaction commits". Following that, it's the commit of the transaction that causes (2) to happen, and this may well happen entirely out of band of the messaging layer. --Rafael From videlalvaro at gmail.com Thu May 6 17:04:59 2010 From: videlalvaro at gmail.com (Alvaro Videla) Date: Fri, 7 May 2010 00:04:59 +0800 Subject: [rabbitmq-discuss] Deleting Queues, How? In-Reply-To: <4BE2E7FE.4020506@rabbitmq.com> References: <4BE2D95B.2090103@loafman.com> <12EEB267-9F45-4614-881D-E93F82A277FA@gmail.com> <4BE2E7FE.4020506@rabbitmq.com> Message-ID: <890B7C8D-B49B-413C-B804-65BF566DF0DE@gmail.com> In PHP you will do something like: $conn = new AMQPConnection($HOST, $PORT, $USER, $PASS); $ch = $conn->channel(); $ch->queue_delete($options['name']); On May 7, 2010, at 12:02 AM, Simon MacMullen wrote: > I'm afraid that writing a small app to do this is the only option. > > The BQL plugin (http://www.rabbitmq.com/rabbitmq-bql.html) has a "drop > queue" command, but you won't be able to get BQL installed without > restarting RabbitMQ. > > At some point we'd like to write a command line client for ad hoc use > and scripting. Time is, as usual, the problem... > > Cheers, Simon > > On 06/05/10 16:19, Alvaro Videla said: >> Your library should implement a method called >> queue_delete('queue_name'); or something similar according to the >> language. >> >> -Alvaro On May 6, 2010, at 10:59 PM, Kenneth Loafman wrote: >> >>> Hi, >>> >>> I've got some queues that were created as permanent on a fanout >>> exchange that should have been created as temporary >>> (exclusive=True). I'm trying to find a way to delete them since >>> they are slowly filiing up. Is there a utility out there that will >>> give me a way to do this, or must I shut down RabbitMQ and restart >>> the world? >>> >>> ...Thanks, ...Ken >>> >>> _______________________________________________ rabbitmq-discuss >>> mailing list rabbitmq-discuss at lists.rabbitmq.com >>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> >>> >> >> _______________________________________________ rabbitmq-discuss >> mailing list rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > > -- > Simon MacMullen > Staff Engineer, RabbitMQ > SpringSource, a division of VMware > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From gsim at redhat.com Thu May 6 17:07:13 2010 From: gsim at redhat.com (Gordon Sim) Date: Thu, 06 May 2010 17:07:13 +0100 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE2CC29.2050101@lshift.net> References: <4BE279C3.6020903@250bpm.com> <4BE2970B.9070208@250bpm.com> <4BE2A943.6070305@250bpm.com> <4BE2C191.5030402@250bpm.com> <4BE2CC29.2050101@lshift.net> Message-ID: <4BE2E931.6050303@redhat.com> On 05/06/2010 03:03 PM, Michael Bridgen wrote: >> Let me give an example: >> >> Say you have a non-destructive an destructive links attached to a node. >> When you process a message at the node, the non-destructive link gets >> either all the messages (if the matching for the destructive link is >> done after matching for the non-destructive one), or no messages (if the >> matching for the destructive link is done before matching for the >> non-destructive one) or random subset of messages (if some form of >> load-balancing among links is done). All in all, client has no guarantee >> of which messages it'll get or whether it'll get at least some messages. >> >> In other words, one misbehaved client can render all the other clients >> non-functional. I would expect an implementation to define policy around where links with these two types of distribution mode can be used. E.g. a pub-sub topic might only allow non-destructive links were valid, a plain queue might only allow destructive links and a browsable queue might allow both (with what I think are then obvious if non-deterministic implications for concurrent links with different modes). (I myself prefer the terms acquiring/non-acquiring to destructive/non-destructive, but the names used aren't critical). > I understand that there's a desire to accommodate e.g., JMS-like > semantics (which I can see may have been a motivating force for > "distribution mode"). But I think the core spec can leave room for > those, without taking a position otherwise. > > What the spec does at the minute is to have a model that tries to > encompass all possibilities, where it ought to be silent. I think it is important to be able to indicate which behaviour you require/expect (i.e. whether you want to exclusively 'acquire' the message or not). I think the details of what the node you are linking to allows with regard to distribution mode should indeed be left unspecified at this level (as it is). I view book IV as defining the minimal requirements beyond the basic transport (i.e. book III), allowing semantic interoperability for the common, basic messaging patterns without placing unnecessary burdens or constraints on implementations. From alexis.richardson at gmail.com Thu May 6 17:12:51 2010 From: alexis.richardson at gmail.com (Alexis Richardson) Date: Thu, 6 May 2010 17:12:51 +0100 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE2E931.6050303@redhat.com> References: <4BE2970B.9070208@250bpm.com> <4BE2A943.6070305@250bpm.com> <4BE2C191.5030402@250bpm.com> <4BE2CC29.2050101@lshift.net> <4BE2E931.6050303@redhat.com> Message-ID: On Thu, May 6, 2010 at 5:07 PM, Gordon Sim wrote: > > I would expect an implementation to define policy around where links > with these two types of distribution mode can be used. E.g. a pub-sub > topic might only allow non-destructive links were valid, a plain queue > might only allow destructive links and a browsable queue might allow > both (with what I think are then obvious if non-deterministic > implications for concurrent links with different modes). Is there any use case where 'destructive' or 'non destructive' behaviour should be a property of the LINK rather than the NODE? alexis > (I myself prefer the terms acquiring/non-acquiring to > destructive/non-destructive, but the names used aren't critical). > >> I understand that there's a desire to accommodate e.g., JMS-like >> semantics (which I can see may have been a motivating force for >> "distribution mode"). ?But I think the core spec can leave room for >> those, without taking a position otherwise. >> >> What the spec does at the minute is to have a model that tries to >> encompass all possibilities, where it ought to be silent. > > I think it is important to be able to indicate which behaviour you > require/expect (i.e. whether you want to exclusively 'acquire' the > message or not). I think the details of what the node you are linking to > allows with regard to distribution mode should indeed be left > unspecified at this level (as it is). > > I view book IV as defining the minimal requirements beyond the basic > transport (i.e. book III), allowing semantic interoperability for the > common, basic messaging patterns without placing unnecessary burdens or > constraints on implementations. > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > From gsim at redhat.com Thu May 6 17:20:53 2010 From: gsim at redhat.com (Gordon Sim) Date: Thu, 06 May 2010 17:20:53 +0100 Subject: [rabbitmq-discuss] request for help! In-Reply-To: References: <4BE2970B.9070208@250bpm.com> <4BE2A943.6070305@250bpm.com> <4BE2C191.5030402@250bpm.com> <4BE2CC29.2050101@lshift.net> <4BE2E931.6050303@redhat.com> Message-ID: <4BE2EC65.9010108@redhat.com> On 05/06/2010 05:12 PM, Alexis Richardson wrote: > On Thu, May 6, 2010 at 5:07 PM, Gordon Sim wrote: >> >> I would expect an implementation to define policy around where links >> with these two types of distribution mode can be used. E.g. a pub-sub >> topic might only allow non-destructive links were valid, a plain queue >> might only allow destructive links and a browsable queue might allow >> both (with what I think are then obvious if non-deterministic >> implications for concurrent links with different modes). > > Is there any use case where 'destructive' or 'non destructive' > behaviour should be a property of the LINK rather than the NODE? Browsing a queue (you would want to allow consumers and browsers, though most likely at different times). From david at drmaciver.com Thu May 6 17:25:01 2010 From: david at drmaciver.com (David MacIver) Date: Thu, 6 May 2010 17:25:01 +0100 Subject: [rabbitmq-discuss] Behaviour when connecting with invalid credentials Message-ID: (Currently using the 1.7.2 server and the current default branch of mercurial for the Java client) If you use the Java client and try to connect to the rabbit server with bad credentials (e.g. dodgy password, no permissions for the vhost, user doesn't exist) you'll see the following: com.rabbitmq.client.ShutdownSignalException: connection error; reason: java.io.EOFException at com.rabbitmq.utility.ValueOrException.getValue(ValueOrException.java:81) at com.rabbitmq.utility.BlockingValueOrException.uninterruptibleGetValue(BlockingValueOrException.java:47) at com.rabbitmq.client.impl.AMQChannel$BlockingRpcContinuation.getReply(AMQChannel.java:336) at com.rabbitmq.client.impl.AMQChannel.rpc(AMQChannel.java:209) at com.rabbitmq.client.impl.AMQChannel.exnWrappingRpc(AMQChannel.java:133) at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.java:302) at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:375) at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:420) java.io.EOFException at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:273) at com.rabbitmq.client.impl.Frame.readFrom(Frame.java:118) at com.rabbitmq.client.impl.SocketFrameHandler.readFrame(SocketFrameHandler.java:133) at com.rabbitmq.client.impl.AMQConnection.readFrame(AMQConnection.java:413) at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.j... I'm not quite sure if this is correct behaviour on the part of the broker - it's not clear to me what the defined behaviour when rejecting the credentials of a connecting user, but the actual behaviour just seems to be to close the connection with prejudice: =ERROR REPORT==== 6-May-2010::17:13:56 === exception on TCP connection <0.652.0> from 127.0.0.1:54886 {channel0_error,starting, {amqp_error,access_refused, "login refused for user 'hello world'", 'connection.start_ok'}} =INFO REPORT==== 6-May-2010::17:13:56 === closing TCP connection <0.652.0> from 127.0.0.1:54886 if this is intended behaviour then it would be nice if the Java client were to be a little more informative rather than failing noisily here. I first noticed this because Bunny (a ruby AMQP client I'm doing some work with/on) has essentially the same behaviour and falls over with an unexpected nil on having its credentials rejected. Other AMQP clients presumably have similar issues. So, what's up here? From contact at a-net-user.com Thu May 6 17:33:49 2010 From: contact at a-net-user.com (Roaan Vos) Date: Thu, 6 May 2010 18:33:49 +0200 Subject: [rabbitmq-discuss] Unbinding when not bound In-Reply-To: <4BE2D127.9080801@rabbitmq.com> References: <001301caec9f$dc4ed6f0$94ec84d0$@com> <4BE2A607.9000500@rabbitmq.com> <4BE2D127.9080801@rabbitmq.com> Message-ID: Hi, Yep, I decided on the last option. ;) Thanks for the help Roaan On 6 May 2010 16:24, Emile Joubert wrote: > > Hi Roaan, > > If you are concerned about receiving messages asynchronously between > binding and unbinding the queue then you could cancel the subscription > first. Be aware that messages may still end up in the queue, even if they > are not delivered. It would of course be preferable to avoid the entire > sequence (cancel subscription, bind, unbind) if there was no binding in the > first place. > > Another approach is to allow the exception to occur and recover from it by > re-establishing the connection. > > > -Emile > > > > > Roaan Vos wrote: > >> Hi, >> >> On second thought, I don't think that will work. >> >> If I first do the binding, the client will likely receive data he didn't >> intend before being able to remove the binding. >> >> Since consuming messages off of the queue is happening asynchronously, >> while the bind/unbind happens on a different connection I think the above is >> quite possible. >> >> Thanks >> >> Roaan >> >> >> On 6 May 2010 13:20, Emile Joubert > emile at rabbitmq.com>> wrote: >> >> >> Hi Roaan, >> >> The broker is required to raise a connection exception if an unbind >> fails, so you are describing expected behaviour. >> >> Duplicate bindings will be ignored, so you can prevent the exception >> by performing a (possibly duplicate) binding immediately prior to >> unbind. >> >> The client is expected to keep track of bindings under normal >> circumstances though. I assume this is impossible in your case - can >> you explain why? >> >> -Emile >> >> Roaan Vos wrote: >> >> Hi, >> >> I currently allow clients to ?bind? and ?unbind? to >> various >> topics as needed using the .net client. >> >> However, when the client ?unbinds? without first having done a >> bind, RabbitMQ throws an exception and the connection seems to >> disappear. >> >> Is there a way for it to keep the connection (or not throw an >> exception)? >> >> Thanks >> >> Roaan >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> >> >> >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100506/3f8cb486/attachment.htm From matthew at lshift.net Thu May 6 17:39:56 2010 From: matthew at lshift.net (Matthew Sackman) Date: Thu, 6 May 2010 17:39:56 +0100 Subject: [rabbitmq-discuss] Behaviour when connecting with invalid credentials In-Reply-To: References: Message-ID: <20100506163956.GH2739@mrnibble.lshift.net> On Thu, May 06, 2010 at 05:25:01PM +0100, David MacIver wrote: > If you use the Java client and try to connect to the rabbit server > with bad credentials (e.g. dodgy password, no permissions for the > vhost, user doesn't exist) you'll see the following: On 22nd July 2009, at 1:29pm, Tony Garnock-Jones wrote: > Authentication failures should be signalled to the client, either as > part of the protocol (e.g. explicit CONNECTION.CLOSE with some error > code), or through convention by client implementors: if the connection > is closed during auth exchange, that's a pretty clear signal of auth > failure, so it should be reported as such to callers. On 22nd July 2009, at 7:08pm, Matthias Radestock wrote: > Sending a connection.close would be in direct violation of an explicit > (and recent) instruction to the contrary in the protocol spec (0-9-1, > s2.2.4), and could cause (non-rabbit) clients to do all sorts of nasty > things. > > OTOH, as Tony points out, a client detecting a socket closure after it > has sent a connection.start-ok can fairly safely assume that the > reason is an authentication failure of some sort. So I suggest we > change all our clients to report the error with a "likely cause: > authentication failure" description (there are other possible causes > as well such as malformed framing, or the server or network dying for > some unrelated reason). Matthew From david at drmaciver.com Thu May 6 17:44:10 2010 From: david at drmaciver.com (David MacIver) Date: Thu, 6 May 2010 17:44:10 +0100 Subject: [rabbitmq-discuss] Behaviour when connecting with invalid credentials In-Reply-To: <20100506163956.GH2739@mrnibble.lshift.net> References: <20100506163956.GH2739@mrnibble.lshift.net> Message-ID: On 6 May 2010 17:39, Matthew Sackman wrote: > On Thu, May 06, 2010 at 05:25:01PM +0100, David MacIver wrote: >> If you use the Java client and try to connect to the rabbit server >> with bad credentials (e.g. dodgy password, no permissions for the >> vhost, user doesn't exist) you'll see the following: > > On 22nd July 2009, at 1:29pm, Tony Garnock-Jones wrote: >> Authentication failures should be signalled to the client, either as >> part of the protocol (e.g. explicit CONNECTION.CLOSE with some error >> code), or through convention by client implementors: if the connection >> is closed during auth exchange, that's a pretty clear signal of auth >> failure, so it should be reported as such to callers. > > On 22nd July 2009, at 7:08pm, Matthias Radestock wrote: >> Sending a connection.close would be in direct violation of an explicit >> (and recent) instruction to the contrary in the protocol spec (0-9-1, >> s2.2.4), and could cause (non-rabbit) clients to do all sorts of nasty >> things. >> >> OTOH, as Tony points out, a client detecting a socket closure after it >> has sent a connection.start-ok can fairly safely assume that the >> reason is an authentication failure of some sort. So I suggest we >> change all our clients to report the error with a "likely cause: >> authentication failure" description (there are other possible causes >> as well such as malformed framing, or the server or network dying for >> some unrelated reason). Ok. Thanks. I'll fix bunny to handle this. From rnickel at scea.com Thu May 6 18:05:55 2010 From: rnickel at scea.com (Robert Nickel) Date: Thu, 6 May 2010 10:05:55 -0700 Subject: [rabbitmq-discuss] Really bizarre startup issue... In-Reply-To: <4BE24C18.80008@rabbitmq.com> References: <20100430230143.GR7977@coinelement.989studios.com> <4BE24C18.80008@rabbitmq.com> Message-ID: <20100506170552.GE17952@coinelement.989studios.com> On 2010.05.06 05:56:56 +0100, Matthias Radestock wrote: > Robert, > > Robert Nickel wrote: >> On sdcloudsh01, contents of /etc/rabbitmq files: >> rabbitmq.conf: >> NODENAME=regsvc at sdcloudsh01 >> rabbitmq.config: >> [ >> {rabbit, []} >> ]. >> rabbitmq_cluster.config: >> [ 'regsvc at sdcloudsh01','regsvc at sdcloudsh02' ]. >> >> When starting the rabbitmq server using /sbin/service rabbitmq-server start, >> the service fails > > Does rabbit start up fine if you a) remove all the above configuration > files, and b) delete the database directory (usually > /var/lib/rabbitmq/mnesia)? Cleaned out the files and ran the test: [root at sdcloudsh01 ~]# ls /etc/rabbitmq/ [root at sdcloudsh01 ~]# ls /var/lib/rabbitmq/ [root at sdcloudsh01 ~]# /etc/init.d/rabbitmq-server start Starting rabbitmq-server: FAILED - check /var/log/rabbitmq/startup_log, _err rabbitmq-server. [root at sdcloudsh01 ~]# ls -l /var/log/rabbitmq/* -rw-r--r-- 1 root root 34 May 6 09:40 /var/log/rabbitmq/startup_err -rw-r--r-- 1 root root 58 May 6 09:40 /var/log/rabbitmq/startup_log [root at sdcloudsh01 ~]# cat /var/log/rabbitmq/* Error: {node_start_failed,normal} Starting all nodes... Starting node rabbit at sdcloudsh01... Same results, unfortunately. >> the following outputs are in /var/log/rabbitmq/startup_err and log: >> >> _log: >> Starting all nodes... >> Starting node regsvc at sdcloudsh01... >> _err: >> Error: {node_start_failed,normal} > > Are there any other non-empty log files in /var/log/rabbitmq? None. See listing above. >> After a bunch of troubleshooting, I noticed that if I strace the above >> command, everything works fine: >> >> strace -f /sbin/service rabbitmq-server start >> >> Terminating the strace leaves the rabbit server running happily. > > That would suggest some sort of race / timing issue. Strange. Agreed. My inital thought is that the parent process is terminating before the fork somehow. I don't have a good way to validate this as I have zero experience with erlang and how to debug it. FWIW: [root at sdcloudsh01 ~]# uname -rvmi 2.6.18-53.el5PAE #1 SMP Mon Nov 12 02:55:09 EST 2007 i686 i386 The rabbitmq user has no .bash* files other than .bash_history. Thank you, --Robert From wvandenhandel at dataraker.com Thu May 6 18:49:50 2010 From: wvandenhandel at dataraker.com (Wayne Van Den Handel) Date: Thu, 06 May 2010 13:49:50 -0400 Subject: [rabbitmq-discuss] Scalability? Message-ID: <4BE3013E.9080308@dataraker.com> I am evaluating RabbitMQ for purposes of parallelization on top of a Cassandra data store. I have created a simple test scenario of a set of Queues that are given data to be loaded from a single Python publisher and 3-4 Python Consumer applications take the data from the Queues and load into Cassandra. The entire scenario was easily set up and runs great for about 10 minutes when RabbitMQ proceeds to use up all available memory and crashes. I then discovered the passive mode to create a queue (and find out how many messages it has) and now only add more work to the queue when there is less than 1000 messages in the queue (which easily fit into memory). I start up my test again and still blow RabbitMQ up in 10 minutes. I am watching with the admin console the entire time and there is never more than a total 1000 messages in all queues at any given time. Watching top I see RabbitMQ take up more and more memory over time. It seems that it can only process 30-40k messages in total/aggregate before it crashes (even though there is never more than 1000 messages in all queues at one time). Am I missing something here? The product seems very easy to use and works great but it totally un-scalable. Is RabbitMQ not meant for high data volumes/traffic? What would better serve this purpose? We need something on top of Cassandra to provide high volume parallelization. I understand that we can only hold what fits in memory right now (when will that be fixed?), but even that is not true as memory is never given back. Environment: CentOS 5.4 64 Bit RabbitMQ v1.7.2-1.el5 installed from yum py-amqplib Create Queue chan.queue_declare(queue="dr_load.1", durable=True, exclusive=False, auto_delete=False) chan.exchange_declare(exchange="dr_load", type="direct", durable=True, auto_delete=False) chan.queue_bind(queue="dr_load.1", exchange="dr_load", routing_key="Instance.1") Publish Data chan.basic_publish(msg,exchange="dr_load",routing_key="Instance.1",mandatory=True) Consume Data msg = chan.basic_get("Instance.1") chan.basic_ack(msg.delivery_tag) Thanks! -- Wayne Van Den Handel, DataRaker Inc Phone: 703.996.4891 Mobile: 305.849.1794 Skype: wayne.van.den.handel Email: wvandenhandel at dataraker.com From rafaels at redhat.com Thu May 6 18:56:47 2010 From: rafaels at redhat.com (Rafael Schloming) Date: Thu, 06 May 2010 13:56:47 -0400 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE2EC65.9010108@redhat.com> References: <4BE2970B.9070208@250bpm.com> <4BE2A943.6070305@250bpm.com> <4BE2C191.5030402@250bpm.com> <4BE2CC29.2050101@lshift.net> <4BE2E931.6050303@redhat.com> <4BE2EC65.9010108@redhat.com> Message-ID: <4BE302DF.5040507@redhat.com> Gordon Sim wrote: > On 05/06/2010 05:12 PM, Alexis Richardson wrote: >> On Thu, May 6, 2010 at 5:07 PM, Gordon Sim wrote: >>> I would expect an implementation to define policy around where links >>> with these two types of distribution mode can be used. E.g. a pub-sub >>> topic might only allow non-destructive links were valid, a plain queue >>> might only allow destructive links and a browsable queue might allow >>> both (with what I think are then obvious if non-deterministic >>> implications for concurrent links with different modes). >> Is there any use case where 'destructive' or 'non destructive' >> behaviour should be a property of the LINK rather than the NODE? > > Browsing a queue (you would want to allow consumers and browsers, though > most likely at different times). One point of clarification, the destructive/non-destructive property is not actually associated with a link, it's actually part of the source specification. There is no distinction between destructive and non-destructive links from the perspective of the transport. It makes no difference to the transport whether the result of an ack is to advance a cursor or to dequeue a message. The distribution-mode field of the source specification simply permits the application to indicate how the link is/should be treated by the node, in other words destructive/non-destructive is not a "property of the link", but rather a classification of the outgoing links from a certain kind of node, and this classification has no impact on how links function, only on how the node behaves with respect to the two different classes of outgoing links. --Rafael From dougbarth at gmail.com Thu May 6 19:09:46 2010 From: dougbarth at gmail.com (Doug Barth) Date: Thu, 6 May 2010 11:09:46 -0700 (PDT) Subject: [rabbitmq-discuss] Deleting Queues, How? In-Reply-To: <4BE2D95B.2090103@loafman.com> References: <4BE2D95B.2090103@loafman.com> Message-ID: <5a501346-204d-4ead-8222-bb383695ae9e@b7g2000yqk.googlegroups.com> If you have ruby installed, I have a gem that I wrote that supplies basic CLI programs for queue management. gem install amqp-utils On May 6, 9:59?am, Kenneth Loafman wrote: > Hi, > > I've got some queues that were created as permanent on a fanout exchange > that should have been created as temporary (exclusive=True). ?I'm trying > to find a way to delete them since they are slowly filiing up. ?Is there > a utility out there that will give me a way to do this, or must I shut > down RabbitMQ and restart the world? > > ...Thanks, > ...Ken > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-disc... at lists.rabbitmq.comhttp://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > -- > You received this message because you are subscribed to the Google Groups "rabbitmq-discuss" group. > To post to this group, send email to rabbitmq-discuss at googlegroups.com. > To unsubscribe from this group, send email to rabbitmq-discuss+unsubscribe at googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rabbitmq-discuss?hl=en. From matthias at rabbitmq.com Thu May 6 19:35:20 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Thu, 06 May 2010 19:35:20 +0100 Subject: [rabbitmq-discuss] Really bizarre startup issue... In-Reply-To: <20100506170552.GE17952@coinelement.989studios.com> References: <20100430230143.GR7977@coinelement.989studios.com> <4BE24C18.80008@rabbitmq.com> <20100506170552.GE17952@coinelement.989studios.com> Message-ID: <4BE30BE8.3070105@rabbitmq.com> Robert, Robert Nickel wrote: > Cleaned out the files and ran the test: [...] > Same results, unfortunately. *sigh*. It might be worth adding some debugging output to /usr/lib/rabbitmq/bin/rabbitmq-server, just to see whether starting rabbit actually gets as far as running that script (and if so, how far into it). > FWIW: > [root at sdcloudsh01 ~]# uname -rvmi > 2.6.18-53.el5PAE #1 SMP Mon Nov 12 02:55:09 EST 2007 i686 i386 Is there another machine on which you could try to get rabbit installed? That way we could rule out any peculiarities with that particular machine. And/or could you give one of the rabbit team access to the above machine? Regards, Matthias. From colin at cloudeventprocessing.com Thu May 6 20:22:40 2010 From: colin at cloudeventprocessing.com (Colin Clark) Date: Thu, 06 May 2010 14:22:40 -0500 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: <4BE3013E.9080308@dataraker.com> References: <4BE3013E.9080308@dataraker.com> Message-ID: <4BE31700.6090308@cloudeventprocessing.com> Something smells rotten in Denmark. I can't comment on your particular implementation but what I can tell you is that we're pumping a lot of data through RabbitMQ (avg 320KiB/s 24x7), that we're far exceeding your volumes (as I can decipher from your post), and that we routinely run for days/weeks on end without any issues. Given that your store is Cassandra, you probably shouldn't even be seeing a meaningful CPU load at those volumes (for the database). And I don't understand your 'hold what fits in memory' comment at all. Would someone who knows something about the python API please steer this lost soul in the right direction? On 5/6/2010 12:49 PM, Wayne Van Den Handel wrote: > I am evaluating RabbitMQ for purposes of parallelization on top of a > Cassandra data store. I have created a simple test scenario of a set of > Queues that are given data to be loaded from a single Python publisher > and 3-4 Python Consumer applications take the data from the Queues and > load into Cassandra. The entire scenario was easily set up and runs > great for about 10 minutes when RabbitMQ proceeds to use up all > available memory and crashes. I then discovered the passive mode to > create a queue (and find out how many messages it has) and now only add > more work to the queue when there is less than 1000 messages in the > queue (which easily fit into memory). I start up my test again and still > blow RabbitMQ up in 10 minutes. I am watching with the admin console the > entire time and there is never more than a total 1000 messages in all > queues at any given time. Watching top I see RabbitMQ take up more and > more memory over time. It seems that it can only process 30-40k messages > in total/aggregate before it crashes (even though there is never more > than 1000 messages in all queues at one time). > > Am I missing something here? The product seems very easy to use and > works great but it totally un-scalable. Is RabbitMQ not meant for high > data volumes/traffic? What would better serve this purpose? We need > something on top of Cassandra to provide high volume parallelization. I > understand that we can only hold what fits in memory right now (when > will that be fixed?), but even that is not true as memory is never given > back. > > Environment: > CentOS 5.4 64 Bit > RabbitMQ v1.7.2-1.el5 installed from yum > py-amqplib > > Create Queue > chan.queue_declare(queue="dr_load.1", durable=True, exclusive=False, > auto_delete=False) > chan.exchange_declare(exchange="dr_load", type="direct", durable=True, > auto_delete=False) > chan.queue_bind(queue="dr_load.1", exchange="dr_load", > routing_key="Instance.1") > > Publish Data > chan.basic_publish(msg,exchange="dr_load",routing_key="Instance.1",mandatory=True) > > Consume Data > msg = chan.basic_get("Instance.1") > chan.basic_ack(msg.delivery_tag) > > Thanks! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100506/41d33418/attachment-0001.htm From matthias at rabbitmq.com Thu May 6 21:35:39 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Thu, 06 May 2010 21:35:39 +0100 Subject: [rabbitmq-discuss] Really bizarre startup issue... In-Reply-To: <20100506195038.GF26133@coinelement.989studios.com> References: <20100430230143.GR7977@coinelement.989studios.com> <4BE24C18.80008@rabbitmq.com> <20100506170552.GE17952@coinelement.989studios.com> <4BE30BE8.3070105@rabbitmq.com> <20100506195038.GF26133@coinelement.989studios.com> Message-ID: <4BE3281B.7010305@rabbitmq.com> Robert, Robert Nickel wrote: > On 2010.05.06 19:35:20 +0100, Matthias Radestock wrote: >> *sigh*. It might be worth adding some debugging output to >> /usr/lib/rabbitmq/bin/rabbitmq-server, just to see whether starting >> rabbit actually gets as far as running that script (and if so, how far >> into it). > > I don't think that script is ever invoked as the init script invokes > /usr/sbin/rabbitmq-multi which then invokes > /usr/lib/rabbitmq/bin/rabbitmq-multi which has the call to erl. > > Is this incorrect? The Erlang code executed by rabbitmq-multi in turn calls the rabbitmq-server script. If things are working as they should. Matthias. From rnickel at scea.com Thu May 6 21:41:36 2010 From: rnickel at scea.com (Robert Nickel) Date: Thu, 6 May 2010 13:41:36 -0700 Subject: [rabbitmq-discuss] Really bizarre startup issue... In-Reply-To: <4BE3281B.7010305@rabbitmq.com> References: <20100430230143.GR7977@coinelement.989studios.com> <4BE24C18.80008@rabbitmq.com> <20100506170552.GE17952@coinelement.989studios.com> <4BE30BE8.3070105@rabbitmq.com> <20100506195038.GF26133@coinelement.989studios.com> <4BE3281B.7010305@rabbitmq.com> Message-ID: <20100506204136.GI26133@coinelement.989studios.com> On 2010.05.06 21:35:39 +0100, Matthias Radestock wrote: > Robert, > > Robert Nickel wrote: >> On 2010.05.06 19:35:20 +0100, Matthias Radestock wrote: >>> *sigh*. It might be worth adding some debugging output to >>> /usr/lib/rabbitmq/bin/rabbitmq-server, just to see whether starting >>> rabbit actually gets as far as running that script (and if so, how >>> far into it). >> >> I don't think that script is ever invoked as the init script invokes >> /usr/sbin/rabbitmq-multi which then invokes >> /usr/lib/rabbitmq/bin/rabbitmq-multi which has the call to erl. >> >> Is this incorrect? > > The Erlang code executed by rabbitmq-multi in turn calls the > rabbitmq-server script. If things are working as they should. Excellent. I will add my set -x into that. Is there a way to get more debugging information out of erlang? --Robert From rnickel at scea.com Thu May 6 21:44:16 2010 From: rnickel at scea.com (Robert Nickel) Date: Thu, 6 May 2010 13:44:16 -0700 Subject: [rabbitmq-discuss] Really bizarre startup issue... In-Reply-To: <20100506204136.GI26133@coinelement.989studios.com> References: <20100430230143.GR7977@coinelement.989studios.com> <4BE24C18.80008@rabbitmq.com> <20100506170552.GE17952@coinelement.989studios.com> <4BE30BE8.3070105@rabbitmq.com> <20100506195038.GF26133@coinelement.989studios.com> <4BE3281B.7010305@rabbitmq.com> <20100506204136.GI26133@coinelement.989studios.com> Message-ID: <20100506204416.GJ26133@coinelement.989studios.com> On 2010.05.06 13:41:36 -0700, Robert Nickel wrote: > On 2010.05.06 21:35:39 +0100, Matthias Radestock wrote: > > Robert, > > > > Robert Nickel wrote: > >> On 2010.05.06 19:35:20 +0100, Matthias Radestock wrote: > >>> *sigh*. It might be worth adding some debugging output to > >>> /usr/lib/rabbitmq/bin/rabbitmq-server, just to see whether starting > >>> rabbit actually gets as far as running that script (and if so, how > >>> far into it). > >> > >> I don't think that script is ever invoked as the init script invokes > >> /usr/sbin/rabbitmq-multi which then invokes > >> /usr/lib/rabbitmq/bin/rabbitmq-multi which has the call to erl. > >> > >> Is this incorrect? > > > > The Erlang code executed by rabbitmq-multi in turn calls the > > rabbitmq-server script. If things are working as they should. > > Excellent. I will add my set -x into that. Is there a way to get more > debugging information out of erlang? rabbitmq-server is not getting invoked according to the output in /var/log/rabbitmq/startup*. I added an echo and set -x to the script and got nothing. -- -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/- Robert Nickel Senior Systems Administrator, Systems Engineering WWS Global Platform Sony Computer Entertainment America 10075 Barnes Canyon Rd San Diego Ca, 92121 (858)824-4802 Phone robert_nickel at playstation.sony.com From matthias at rabbitmq.com Thu May 6 22:48:08 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Thu, 06 May 2010 22:48:08 +0100 Subject: [rabbitmq-discuss] Really bizarre startup issue... In-Reply-To: <20100506204416.GJ26133@coinelement.989studios.com> References: <20100430230143.GR7977@coinelement.989studios.com> <4BE24C18.80008@rabbitmq.com> <20100506170552.GE17952@coinelement.989studios.com> <4BE30BE8.3070105@rabbitmq.com> <20100506195038.GF26133@coinelement.989studios.com> <4BE3281B.7010305@rabbitmq.com> <20100506204136.GI26133@coinelement.989studios.com> <20100506204416.GJ26133@coinelement.989studios.com> Message-ID: <4BE33918.8030209@rabbitmq.com> Robert, Robert Nickel wrote: > rabbitmq-server is not getting invoked according to the output in > /var/log/rabbitmq/startup*. > > I added an echo and set -x to the script and got nothing. The logging could possibly go astray; I suggest you add something like a 'touch /tmp/foo' right at the beginning to serve as a "got here" marker. The {node_start_failed,normal} error you are seeing in the logs indicates that the rabbit_multi erlang code is attempting to invoke the rabbitmq-server script but that either somehow fails or at least doesn't result in a running rabbit server. It's very unusual for that to happen and not result in some errors in the startup logs. I cannot think of an easy way of tracking down the cause w/o hacking on the rabbitmq_multi erlang code. Matthias. From mvcalder at gmail.com Thu May 6 22:53:22 2010 From: mvcalder at gmail.com (Matt Calder) Date: Thu, 6 May 2010 17:53:22 -0400 Subject: [rabbitmq-discuss] Trouble starting rabbitmq (new user) Message-ID: Hi, I've had persistent problems running rabbit mq under Ubuntu. > uname -a Linux domU-12-31-39-01-B1-21 2.6.31-302-ec2 #7-Ubuntu SMP Tue Oct 13 19:06:04 UTC 2009 i686 GNU/Linux After an initial install things seem fine. However after use, not particularly heavy, it falls into a bad state and nothing seems to help. ubuntu at domU-12-31-39-01-B1-21:~/celerytest$ sudo rabbitmqctl status Status of node 'rabbit at domU-12-31-39-01-B1-21' ... {badrpc,nodedown} ...done. If I restart, I get a timeout, ubuntu at domU-12-31-39-01-B1-21:~/celerytest$ cat /var/log/rabbitmq/startup_log Starting all nodes... Starting node rabbit at domU-12-31-39-01-B1-21... RabbitMQ 1.6.0 (AMQP 8-0) Copyright (C) 2007-2009 LShift Ltd., Cohesive Financial Technologies LLC., and Rabbit Technologies Ltd. Licensed under the MPL. See http://www.rabbitmq.com/ node : rabbit at domU-12-31-39-01-B1-21 log : /var/log/rabbitmq/rabbit.log sasl log : /var/log/rabbitmq/rabbit-sasl.log database dir: /var/lib/rabbitmq/mnesia/rabbit starting database ...timeout {"init terminating in do_boot",{{nocatch,{error,{cannot_start_application,rabbit,{{timeout_waiting_for_tables,[rabbit_user,rabbit_user_permission,rabbit_vhost,rabbit_config,rabbit_listener,rabbit_durable_route,rabbit_route,rabbit_reverse_route,rabbit_durable_exchange,rabbit_exchange,rabbit_durable_queue,rabbit_queue]},{rabbit,start,[normal,[]]}}}}},[{init,start_it,1},{init,start_em,1}]}} Since I am a new user I suspect I am doing something obviously wrong. If anyone knows what that is I would greatly appreciate a pointer. Uninstalling and reinstalling doesn't seem like a workable plan going forward. Matt From natester at gmail.com Thu May 6 22:58:34 2010 From: natester at gmail.com (Nathaniel Haggard) Date: Thu, 6 May 2010 15:58:34 -0600 Subject: [rabbitmq-discuss] extra listening ports Message-ID: tcp 0 0 0.0.0.0:3485 0.0.0.0:* LISTEN 15765/beam tcp 0 0 0.0.0.0:4369 0.0.0.0:* LISTEN 3728/epmd I found these ports also bound to the public interface when I startup rabbitmq-multi. What are those ports used for and do they have to be bound to the public interface? I'd like to keep this as secure as possible. -Nate From jasonjwwilliams at gmail.com Thu May 6 23:08:32 2010 From: jasonjwwilliams at gmail.com (Jason J. W. Williams) Date: Thu, 6 May 2010 16:08:32 -0600 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: <4BE3013E.9080308@dataraker.com> References: <4BE3013E.9080308@dataraker.com> Message-ID: Hi Wayne, This there a reason you're using basic_get instead of basic_consume? I haven't looked at the guts of basic_get inside py-amqplib, but basic_consume just by my way of thinking should have less build-up/tear-down overhead. It's what we use very successfully. -J On Thu, May 6, 2010 at 11:49 AM, Wayne Van Den Handel wrote: > I am evaluating RabbitMQ for purposes of parallelization on top of a > Cassandra data store. I have created a simple test scenario of a set of > Queues that are given data to be loaded from a single Python publisher > and 3-4 Python Consumer applications take the data from the Queues and > load into Cassandra. The entire scenario was easily set up and runs > great for about 10 minutes when RabbitMQ proceeds to use up all > available memory and crashes. ?I then discovered the passive mode to > create a queue (and find out how many messages it has) and now only add > more work to the queue when there is less than 1000 messages in the > queue (which easily fit into memory). I start up my test again and still > blow RabbitMQ up in 10 minutes. I am watching with the admin console the > entire time and there is never more than a total 1000 messages in all > queues at any given time. Watching top I see RabbitMQ take up more and > more memory over time. It seems that it can only process 30-40k messages > in total/aggregate before it crashes (even though there is never more > than 1000 messages in all queues at one time). > > Am I missing something here? The product seems very easy to use and > works great but it totally un-scalable. Is RabbitMQ not meant for high > data volumes/traffic? What would better serve this purpose? We need > something on top of Cassandra to provide high volume parallelization. I > understand that we can only hold what fits in memory right now (when > will that be fixed?), but even that is not true as memory is never given > back. > > Environment: > CentOS 5.4 64 Bit > RabbitMQ v1.7.2-1.el5 installed from yum > py-amqplib > > Create Queue > chan.queue_declare(queue="dr_load.1", durable=True, exclusive=False, > auto_delete=False) > chan.exchange_declare(exchange="dr_load", type="direct", durable=True, > auto_delete=False) > chan.queue_bind(queue="dr_load.1", exchange="dr_load", > routing_key="Instance.1") > > Publish Data > chan.basic_publish(msg,exchange="dr_load",routing_key="Instance.1",mandatory=True) > > Consume Data > msg = chan.basic_get("Instance.1") > chan.basic_ack(msg.delivery_tag) > > Thanks! > > -- > Wayne Van Den Handel, DataRaker Inc > > Phone: ?703.996.4891 > Mobile: 305.849.1794 > Skype: ?wayne.van.den.handel > Email: ?wvandenhandel at dataraker.com > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > From nemik at nemik.net Fri May 7 02:20:48 2010 From: nemik at nemik.net (Nemanja Stefanovic) Date: Thu, 6 May 2010 20:20:48 -0500 Subject: [rabbitmq-discuss] extra listening ports In-Reply-To: References: Message-ID: http://www.ejabberd.im/epmd Not sure about 3485. You should secure things though by blocking those at a firewall level using something like iptables. On Thu, May 6, 2010 at 4:58 PM, Nathaniel Haggard wrote: > tcp 0 0 0.0.0.0:3485 0.0.0.0:* > LISTEN 15765/beam > tcp 0 0 0.0.0.0:4369 0.0.0.0:* > LISTEN 3728/epmd > > I found these ports also bound to the public interface when I startup > rabbitmq-multi. What are those ports used for and do they have to be > bound to the public interface? > > I'd like to keep this as secure as possible. > > -Nate > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100506/8d8cfb58/attachment.htm From aquino.gustavo at gmail.com Fri May 7 02:34:13 2010 From: aquino.gustavo at gmail.com (Gustavo Aquino) Date: Thu, 6 May 2010 22:34:13 -0300 Subject: [rabbitmq-discuss] MTU Message-ID: Hi, What is the MTU of a message from RabbitMQ ? 1.500 ? Regards. Gustavo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100506/86a8de60/attachment-0001.htm From aquino.gustavo at gmail.com Fri May 7 02:38:33 2010 From: aquino.gustavo at gmail.com (Gustavo Aquino) Date: Thu, 6 May 2010 22:38:33 -0300 Subject: [rabbitmq-discuss] Trouble starting rabbitmq (new user) In-Reply-To: References: Message-ID: Hi Matt, Take a look inside list, I had this problem in past and you will found the solutions it's probably a hostname problem that you can solv with a configuration file. Regards. Gustavo On Thu, May 6, 2010 at 6:53 PM, Matt Calder wrote: > Hi, > > I've had persistent problems running rabbit mq under Ubuntu. > > > uname -a > Linux domU-12-31-39-01-B1-21 2.6.31-302-ec2 #7-Ubuntu SMP Tue Oct 13 > 19:06:04 UTC 2009 i686 GNU/Linux > > After an initial install things seem fine. However after use, not > particularly heavy, it falls into a bad state and nothing seems to > help. > > ubuntu at domU-12-31-39-01-B1-21:~/celerytest$ sudo rabbitmqctl status > Status of node 'rabbit at domU-12-31-39-01-B1-21' ... > {badrpc,nodedown} > ...done. > > If I restart, > > I get a timeout, > > ubuntu at domU-12-31-39-01-B1-21:~/celerytest$ cat > /var/log/rabbitmq/startup_log > Starting all nodes... > Starting node rabbit at domU-12-31-39-01-B1-21... > RabbitMQ 1.6.0 (AMQP 8-0) > Copyright (C) 2007-2009 LShift Ltd., Cohesive Financial Technologies > LLC., and Rabbit Technologies Ltd. > Licensed under the MPL. See http://www.rabbitmq.com/ > > node : rabbit at domU-12-31-39-01-B1-21 > log : /var/log/rabbitmq/rabbit.log > sasl log : /var/log/rabbitmq/rabbit-sasl.log > database dir: /var/lib/rabbitmq/mnesia/rabbit > > starting database ...timeout > {"init terminating in > > do_boot",{{nocatch,{error,{cannot_start_application,rabbit,{{timeout_waiting_for_tables,[rabbit_user,rabbit_user_permission,rabbit_vhost,rabbit_config,rabbit_listener,rabbit_durable_route,rabbit_route,rabbit_reverse_route,rabbit_durable_exchange,rabbit_exchange,rabbit_durable_queue,rabbit_queue]},{rabbit,start,[normal,[]]}}}}},[{init,start_it,1},{init,start_em,1}]}} > > > Since I am a new user I suspect I am doing something obviously wrong. > If anyone knows what that is I would greatly appreciate a pointer. > Uninstalling and reinstalling doesn't seem like a workable plan going > forward. > > Matt > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100506/d462e058/attachment.htm From videlalvaro at gmail.com Fri May 7 06:51:02 2010 From: videlalvaro at gmail.com (Alvaro Videla) Date: Fri, 7 May 2010 13:51:02 +0800 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: References: <4BE3013E.9080308@dataraker.com> Message-ID: <89839F8F-ABB1-4B04-AAAD-633E4CF60185@gmail.com> I second what Colin says, We use RabbitMQ in prod for nearly a year now, and we never had problems. Our volumes are not big, but we queue/consume around 500K messages per day. We only stopped the servers when we upgraded them to the latest version, Regards, Alvaro On May 7, 2010, at 6:08 AM, Jason J. W. Williams wrote: > Hi Wayne, > > This there a reason you're using basic_get instead of basic_consume? I > haven't looked at the guts of basic_get inside py-amqplib, but > basic_consume just by my way of thinking should have less > build-up/tear-down overhead. It's what we use very successfully. > > -J > > On Thu, May 6, 2010 at 11:49 AM, Wayne Van Den Handel > wrote: >> I am evaluating RabbitMQ for purposes of parallelization on top of a >> Cassandra data store. I have created a simple test scenario of a set of >> Queues that are given data to be loaded from a single Python publisher >> and 3-4 Python Consumer applications take the data from the Queues and >> load into Cassandra. The entire scenario was easily set up and runs >> great for about 10 minutes when RabbitMQ proceeds to use up all >> available memory and crashes. I then discovered the passive mode to >> create a queue (and find out how many messages it has) and now only add >> more work to the queue when there is less than 1000 messages in the >> queue (which easily fit into memory). I start up my test again and still >> blow RabbitMQ up in 10 minutes. I am watching with the admin console the >> entire time and there is never more than a total 1000 messages in all >> queues at any given time. Watching top I see RabbitMQ take up more and >> more memory over time. It seems that it can only process 30-40k messages >> in total/aggregate before it crashes (even though there is never more >> than 1000 messages in all queues at one time). >> >> Am I missing something here? The product seems very easy to use and >> works great but it totally un-scalable. Is RabbitMQ not meant for high >> data volumes/traffic? What would better serve this purpose? We need >> something on top of Cassandra to provide high volume parallelization. I >> understand that we can only hold what fits in memory right now (when >> will that be fixed?), but even that is not true as memory is never given >> back. >> >> Environment: >> CentOS 5.4 64 Bit >> RabbitMQ v1.7.2-1.el5 installed from yum >> py-amqplib >> >> Create Queue >> chan.queue_declare(queue="dr_load.1", durable=True, exclusive=False, >> auto_delete=False) >> chan.exchange_declare(exchange="dr_load", type="direct", durable=True, >> auto_delete=False) >> chan.queue_bind(queue="dr_load.1", exchange="dr_load", >> routing_key="Instance.1") >> >> Publish Data >> chan.basic_publish(msg,exchange="dr_load",routing_key="Instance.1",mandatory=True) >> >> Consume Data >> msg = chan.basic_get("Instance.1") >> chan.basic_ack(msg.delivery_tag) >> >> Thanks! >> >> -- >> Wayne Van Den Handel, DataRaker Inc >> >> Phone: 703.996.4891 >> Mobile: 305.849.1794 >> Skype: wayne.van.den.handel >> Email: wvandenhandel at dataraker.com >> >> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From videlalvaro at gmail.com Fri May 7 06:54:34 2010 From: videlalvaro at gmail.com (Alvaro Videla) Date: Fri, 7 May 2010 13:54:34 +0800 Subject: [rabbitmq-discuss] Trouble starting rabbitmq (new user) In-Reply-To: References: Message-ID: <1A20C24E-4FF0-4D34-9F39-CB2EB805288C@gmail.com> To monitor RabbitMQ using the rabbitctl you have to the same user that rabbitmq is running. This is because they have to share the same erlang cookie. On May 7, 2010, at 5:53 AM, Matt Calder wrote: > Hi, > > I've had persistent problems running rabbit mq under Ubuntu. > >> uname -a > Linux domU-12-31-39-01-B1-21 2.6.31-302-ec2 #7-Ubuntu SMP Tue Oct 13 > 19:06:04 UTC 2009 i686 GNU/Linux > > After an initial install things seem fine. However after use, not > particularly heavy, it falls into a bad state and nothing seems to > help. > > ubuntu at domU-12-31-39-01-B1-21:~/celerytest$ sudo rabbitmqctl status > Status of node 'rabbit at domU-12-31-39-01-B1-21' ... > {badrpc,nodedown} > ...done. > > If I restart, > > I get a timeout, > > ubuntu at domU-12-31-39-01-B1-21:~/celerytest$ cat /var/log/rabbitmq/startup_log > Starting all nodes... > Starting node rabbit at domU-12-31-39-01-B1-21... > RabbitMQ 1.6.0 (AMQP 8-0) > Copyright (C) 2007-2009 LShift Ltd., Cohesive Financial Technologies > LLC., and Rabbit Technologies Ltd. > Licensed under the MPL. See http://www.rabbitmq.com/ > > node : rabbit at domU-12-31-39-01-B1-21 > log : /var/log/rabbitmq/rabbit.log > sasl log : /var/log/rabbitmq/rabbit-sasl.log > database dir: /var/lib/rabbitmq/mnesia/rabbit > > starting database ...timeout > {"init terminating in > do_boot",{{nocatch,{error,{cannot_start_application,rabbit,{{timeout_waiting_for_tables,[rabbit_user,rabbit_user_permission,rabbit_vhost,rabbit_config,rabbit_listener,rabbit_durable_route,rabbit_route,rabbit_reverse_route,rabbit_durable_exchange,rabbit_exchange,rabbit_durable_queue,rabbit_queue]},{rabbit,start,[normal,[]]}}}}},[{init,start_it,1},{init,start_em,1}]}} > > > Since I am a new user I suspect I am doing something obviously wrong. > If anyone knows what that is I would greatly appreciate a pointer. > Uninstalling and reinstalling doesn't seem like a workable plan going > forward. > > Matt > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From siddalinga at gmail.com Fri May 7 07:16:52 2010 From: siddalinga at gmail.com (Sidda Eraiah) Date: Thu, 6 May 2010 23:16:52 -0700 (PDT) Subject: [rabbitmq-discuss] Silverlight application with RabbitMQ In-Reply-To: References: <4BD6A64B.2090806@lshift.net> <4BD82BF5.5040209@lshift.net> <4BDA2544.9060107@lshift.net> Message-ID: <29f99616-337d-426c-a5e4-ac47da6e1382@34g2000prs.googlegroups.com> Jens Aernouts, As you found out Kaazing supports AMQP 0-9-1 protocol. It works great against QPid 0.6 (which supports AMQP 0-9-1). RabbitMQ support for AMQP 0-9-1 in the development branch is not very stable and is difficult to get it to run. There is no news from RabbitMQ about when it will be released. If you have to use RabbitMQ only, you can try Kaazing's StompClient implementation to work against RabbitMQ with STOMP adapter. We have tested Kaazing's StompClient against RabbitMQ with stomp adapter successfully. StompClient provides with capability to send binary data to server as a ByteBuffer. You don't have to worry about the content- length header referred above - it is all taken care for you in the StompClient library. Kaazin's StompClient library is available to you in Javascript, Silverlight, .NET, Flex, Java or JavaFX. Best Regards, Sidda On Apr 30, 1:05?pm, "Aernouts Jens" wrote: > Hi everyone, > > I didn't test the STOMP plugin or the new AMQP version yet, so I can't give > new information about it. However, thank you guys for all the feedback. I'm > going to test it after finishing the Silverlight client. > I used all my time working on that and it finally seems to work. I ran the > tests that where delivered with the client and they're all working (except > the tests that didn't even work in the original project). After that, I ran > some example projects, and they're also working. Like I said before, I > commented out the things we don't need (XML things, SSL, ...), so they > aren't working yet. These functions will be fixed afterwards. > About the version: It was simple to change the version by adding the version > number in the AssemblyInfo.cs file. > About the PublicKeyToken: Well, that's what I thought before... However, > thanks for that. > When I finish the project, I'll send it to you and in the meantime, I'll > keep you posted. > Next week I'm on collegetrip, so there won't be any updates... > > Kind Regards > > Jens Aernouts - Student Bachelor of Applied Engineering @ Artesis University > College of Antwerp > > > > > > > Hi Jens, > > > Aernouts Jens wrote: > >> @ Tony: About STOMP: how can our client send a content-length header to > >> the server? We can use the content-length header at our client, but not > >> at the server I think... Can you give some more info about this please? > > > So the STOMP protocol,http://stomp.codehaus.org/Protocol, says this on > > the > > subject: > > > ?"It is recommended that SEND frames include a content-length header which > > ? is a byte count for the length of the message body. If a content-length > > ? header is included, this number of bytes should be read, regardless of > > ? whether or not there are null characters in the body. The frame still > > needs > > ? to be terminated with a null byte and if a content-length is not > > specified, > > ? the first null byte encountered signals the end of the frame." > > > (MESSAGE frames have a very similar paragraph in their description.) > > > The RabbitMQ STOMP server plugin pays attention to this content-length > > header. > > It also *always* supplies a content-length header on MESSAGE whenever the > > message body is non-empty. > > >> I'm currently compiling the client project against the Silverlight > >> runtime, and it seems to work. At this moment, I just rewrote the things > >> we really need (this needs to be fixed as fast as possible), but I'm > >> going to fix the other problems too. > > > Hey this is excellent news! Will you be able to send us a patch? > > >> What should I do to compile it with the right PublicKeyToken and the > >> right version Number? > > > I think you might need our key for that. (Which clearly isn't an option > > :-) ) I > > suspect you will have to recompile the DLLs you have that depend on the > > RabbitMQ client to have less strict dependencies. I'm afraid I'm not an > > expert > > on the vagaries of .NET linking, though :-/ > > > Regards, > > ?Tony > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-disc... at lists.rabbitmq.comhttp://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > -- > You received this message because you are subscribed to the Google Groups "rabbitmq-discuss" group. > To post to this group, send email to rabbitmq-discuss at googlegroups.com. > To unsubscribe from this group, send email to rabbitmq-discuss+unsubscribe at googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rabbitmq-discuss?hl=en. From lists at zopyx.com Fri May 7 07:30:13 2010 From: lists at zopyx.com (Andreas Jung) Date: Fri, 07 May 2010 08:30:13 +0200 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: <89839F8F-ABB1-4B04-AAAD-633E4CF60185@gmail.com> References: <4BE3013E.9080308@dataraker.com> <89839F8F-ABB1-4B04-AAAD-633E4CF60185@gmail.com> Message-ID: <4BE3B375.9070703@zopyx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alvaro Videla wrote: > I second what Colin says, > > We use RabbitMQ in prod for nearly a year now, and we never had problems. Our volumes are not big, but we queue/consume around 500K messages per day. > > We only stopped the servers when we upgraded them to the latest version, Could please summarize your hardware setup for your installation? How many CPU usage and RAM do you need in average? Andreas - -- ZOPYX Limited | zopyx group Charlottenstr. 37/1 | The full-service network for Zope & Plone D-72070 T?bingen | Produce & Publish www.zopyx.com | www.produce-and-publish.com - ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvjs3UACgkQCJIWIbr9KYwFdgCfWGHglm0ZeNTZ9S/cjo3pcQwh M1gAoLcjZ7F1vz49wt88FGXKUT/5kKCu =Hm9z -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: lists.vcf Type: text/x-vcard Size: 316 bytes Desc: not available Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/94a478f8/attachment-0001.vcf From videlalvaro at gmail.com Fri May 7 08:38:04 2010 From: videlalvaro at gmail.com (Alvaro Videla) Date: Fri, 7 May 2010 15:38:04 +0800 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: <4BE3B32C.6020407@gmail.com> References: <4BE3013E.9080308@dataraker.com> <89839F8F-ABB1-4B04-AAAD-633E4CF60185@gmail.com> <4BE3B32C.6020407@gmail.com> Message-ID: <0E2BB247-E296-4B8C-8219-C732E515C009@gmail.com> Hi Andreas, We have two machines for RabbitMQ they are: 2x Intel(R) Xeon(TM) CPU 3.20GHz / 8Gmem Now I checked the load average and is below 0.5 and for what I've read in this mailing list 500k msgs per day is nothing. Regards, Alvaro On May 7, 2010, at 2:29 PM, zopyxfilter at gmail.com wrote: > Alvaro Videla wrote: >> I second what Colin says, >> >> We use RabbitMQ in prod for nearly a year now, and we never had problems. Our volumes are not big, but we queue/consume around 500K messages per day. >> >> > > Could please summarize your hardware setup for your installation? > How many CPU usage and RAM do you need in average? > > Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/d0da4b26/attachment.htm From rtrlists at googlemail.com Fri May 7 10:00:18 2010 From: rtrlists at googlemail.com (Robert Raschke) Date: Fri, 7 May 2010 10:00:18 +0100 Subject: [rabbitmq-discuss] extra listening ports In-Reply-To: References: Message-ID: On Fri, May 7, 2010 at 2:20 AM, Nemanja Stefanovic wrote: > http://www.ejabberd.im/epmd > > Not sure about 3485. You should secure things though by blocking those at a > firewall level using something like iptables. > > > On Thu, May 6, 2010 at 4:58 PM, Nathaniel Haggard wrote: > >> tcp 0 0 0.0.0.0:3485 0.0.0.0:* >> LISTEN 15765/beam >> tcp 0 0 0.0.0.0:4369 0.0.0.0:* >> LISTEN 3728/epmd >> >> I found these ports also bound to the public interface when I startup >> rabbitmq-multi. What are those ports used for and do they have to be >> bound to the public interface? >> >> I'd like to keep this as secure as possible. >> >> -Nate >> >> When Erlang Nodes start up they talk to EPMD to negotiate which port they should use to communicate with other Erlang Nodes. My guess is that's what 3484 is. If you stop everything and restart it's probably going to get a different port. Plain Erlang is meant to run in a protected environment. If you are concerned about connectivity to these ports, then there are ways of restricting/protecting the Erlang Node comms ports (see the kernel inet_dist_ sys.config entries http://www.erlang.org/doc/man/kernel_app.html, and SSL for Erlang distribution http://www.erlang.org/doc/apps/ssl/ssl_distribution.html). Robby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/36b8b716/attachment.htm From wvandenhandel at dataraker.com Fri May 7 12:48:54 2010 From: wvandenhandel at dataraker.com (Wayne Van Den Handel) Date: Fri, 7 May 2010 07:48:54 -0400 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: References: <4BE3013E.9080308@dataraker.com> <89839F8F-ABB1-4B04-AAAD-633E4CF60185@gmail.com> Message-ID: I will test the basic consume, thanks for the tip. The machine I am running is a single socket 4 core with 4 gigs ram but there are other things running and taking up memory. Is there a gc interval that can be set to get memory back sooner? As I add messages and remove them I can see the exact memory taken with the admin tool and it keeps going up. It seems the rate at which I add to the queue exceeds the ability the clear memory. Basically even though there is little in the queue at any time the memory use keeps going up. At this point I am ready to give up until they harden the persister to go to disk as I assume the persister is the problem. On May 7, 2010 1:51 AM, "Alvaro Videla" wrote: I second what Colin says, We use RabbitMQ in prod for nearly a year now, and we never had problems. Our volumes are not big, but we queue/consume around 500K messages per day. We only stopped the servers when we upgraded them to the latest version, Regards, Alvaro On May 7, 2010, at 6:08 AM, Jason J. W. Williams wrote: > Hi Wayne, > > This there a reason you'... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/dc113dfe/attachment.htm From videlalvaro at gmail.com Fri May 7 12:50:40 2010 From: videlalvaro at gmail.com (Alvaro Videla) Date: Fri, 7 May 2010 19:50:40 +0800 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: References: <4BE3013E.9080308@dataraker.com> <89839F8F-ABB1-4B04-AAAD-633E4CF60185@gmail.com> Message-ID: <08439CCF-9B39-4957-8125-C03866D4C8F6@gmail.com> We are not using the new persister in prod, but we do run the latest release. On May 7, 2010, at 7:48 PM, Wayne Van Den Handel wrote: > I will test the basic consume, thanks for the tip. The machine I am running is a single socket 4 core with 4 gigs ram but there are other things running and taking up memory. Is there a gc interval that can be set to get memory back sooner? As I add messages and remove them I can see the exact memory taken with the admin tool and it keeps going up. It seems the rate at which I add to the queue exceeds the ability the clear memory. Basically even though there is little in the queue at any time the memory use keeps going up. At this point I am ready to give up until they harden the persister to go to disk as I assume the persister is the problem. > > >> On May 7, 2010 1:51 AM, "Alvaro Videla" wrote: >> >> I second what Colin says, >> >> We use RabbitMQ in prod for nearly a year now, and we never had problems. Our volumes are not big, but we queue/consume around 500K messages per day. >> >> We only stopped the servers when we upgraded them to the latest version, >> >> Regards, >> >> Alvaro >> >> >> On May 7, 2010, at 6:08 AM, Jason J. W. Williams wrote: >> >> > Hi Wayne, >> > >> > This there a reason you'... >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/8827b36c/attachment.htm From ctusch at gmail.com Fri May 7 12:59:31 2010 From: ctusch at gmail.com (Christian Tusch) Date: Fri, 7 May 2010 13:59:31 +0200 Subject: [rabbitmq-discuss] Federation in RabbitMQ Message-ID: Hello, just a short question: Does RabbitMQ support federation? Thanks From matthew at lshift.net Fri May 7 13:00:27 2010 From: matthew at lshift.net (Matthew Sackman) Date: Fri, 7 May 2010 13:00:27 +0100 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: References: <4BE3013E.9080308@dataraker.com> <89839F8F-ABB1-4B04-AAAD-633E4CF60185@gmail.com> Message-ID: <20100507120026.GJ2739@mrnibble.lshift.net> Hi Wayne, On Fri, May 07, 2010 at 07:48:54AM -0400, Wayne Van Den Handel wrote: > I will test the basic consume, thanks for the tip. The machine I am running > is a single socket 4 core with 4 gigs ram but there are other things running > and taking up memory. Is there a gc interval that can be set to get memory > back sooner? As I add messages and remove them I can see the exact memory > taken with the admin tool and it keeps going up. It seems the rate at which > I add to the queue exceeds the ability the clear memory. Basically even > though there is little in the queue at any time the memory use keeps going > up. Rabbit assumes it gets the whole machine's memory to itself. If that's not the case then you need to reduce the memory high watermark from 0.4 to some much lower figure - say, 0.1. See http://www.rabbitmq.com/extensions.html#memsup > At this point I am ready to give up until they harden the persister to > go to disk as I assume the persister is the problem. Yup. The new persister currently requires you build from source, but it is actively being QA'd and great progress has been made getting it into default. We've gone from about 100 hunks difference a couple of weeks ago to now about 13 - so things are very much moving in this direction. In the mean time, many people are already using the new persister, which is on branch "bug21673" and if you're comfortable compiling from source and using some code which has not yet completed our QA process, then we would encourage you to use it, with the understanding that there may still be bugs in it. Further battle testing is always welcome and should you come across any bugs, any bug reports you make are very gratefully received. Matthew From matthew at lshift.net Fri May 7 13:01:10 2010 From: matthew at lshift.net (Matthew Sackman) Date: Fri, 7 May 2010 13:01:10 +0100 Subject: [rabbitmq-discuss] Federation in RabbitMQ In-Reply-To: References: Message-ID: <20100507120110.GK2739@mrnibble.lshift.net> On Fri, May 07, 2010 at 01:59:31PM +0200, Christian Tusch wrote: > just a short question: Does RabbitMQ support federation? Nope, not yet, but it is on our roadmap. Exactly what do you mean by federation, and what features would you like to see on this? Matthew From mvcalder at gmail.com Fri May 7 13:11:02 2010 From: mvcalder at gmail.com (Matt Calder) Date: Fri, 7 May 2010 08:11:02 -0400 Subject: [rabbitmq-discuss] Trouble starting rabbitmq (new user) In-Reply-To: <1A20C24E-4FF0-4D34-9F39-CB2EB805288C@gmail.com> References: <1A20C24E-4FF0-4D34-9F39-CB2EB805288C@gmail.com> Message-ID: Thanks for the replies. I went through a lot of old emails from the archives (again). I found my problems were almost, but not quite, the same. Presumably there is some underlying cause. What I eventually did that seems to work is this. First, I purged rabbitmq-server and erlang: sudo apt-get purge rabbitmq-server sudo apt-get purge erlang sudo apt-get autoremove Then, I installed erlang independently of (and before) rabbitmq-server: sudo apt-get install erlang-base sudo apt-get install erlang-dev # Not sure this is necessary sudo apt-get install rabbitmq-server This has been working, that is, I have had no issues with rabbitmqctl, nor have I had problems starting and stopping the server from /etc/init.d, and this good behaviour continued after rebooting. Given that, I am declaring victory. I thought it might be helpful to post these breadcrumbs for any other Ubuntu or AWS cloud users out there. I mention that this is an EC2 installation because I have installed the rabbitmq-server package (without the pre-install of erlang) on my home network (also Ubuntu machines) without any issues. Thanks again for the helpful replies, Matt On Fri, May 7, 2010 at 1:54 AM, Alvaro Videla wrote: > To monitor RabbitMQ using the rabbitctl you have to the same user that rabbitmq is running. This is because they have to share the same erlang cookie. > > > On May 7, 2010, at 5:53 AM, Matt Calder wrote: > >> Hi, >> >> I've had persistent problems running rabbit mq under Ubuntu. >> >>> uname -a >> Linux domU-12-31-39-01-B1-21 2.6.31-302-ec2 #7-Ubuntu SMP Tue Oct 13 >> 19:06:04 UTC 2009 i686 GNU/Linux >> >> After an initial install things seem fine. However after use, not >> particularly heavy, it falls into a bad state and nothing seems to >> help. >> >> ubuntu at domU-12-31-39-01-B1-21:~/celerytest$ sudo rabbitmqctl status >> Status of node 'rabbit at domU-12-31-39-01-B1-21' ... >> {badrpc,nodedown} >> ...done. >> >> If I restart, >> >> I get a timeout, >> >> ubuntu at domU-12-31-39-01-B1-21:~/celerytest$ cat /var/log/rabbitmq/startup_log >> Starting all nodes... >> Starting node rabbit at domU-12-31-39-01-B1-21... >> RabbitMQ 1.6.0 (AMQP 8-0) >> Copyright (C) 2007-2009 LShift Ltd., Cohesive Financial Technologies >> LLC., and Rabbit Technologies Ltd. >> Licensed under the MPL. ?See http://www.rabbitmq.com/ >> >> node ? ? ? ?: rabbit at domU-12-31-39-01-B1-21 >> log ? ? ? ? : /var/log/rabbitmq/rabbit.log >> sasl log ? ?: /var/log/rabbitmq/rabbit-sasl.log >> database dir: /var/lib/rabbitmq/mnesia/rabbit >> >> starting database ? ? ? ? ? ? ...timeout >> {"init terminating in >> do_boot",{{nocatch,{error,{cannot_start_application,rabbit,{{timeout_waiting_for_tables,[rabbit_user,rabbit_user_permission,rabbit_vhost,rabbit_config,rabbit_listener,rabbit_durable_route,rabbit_route,rabbit_reverse_route,rabbit_durable_exchange,rabbit_exchange,rabbit_durable_queue,rabbit_queue]},{rabbit,start,[normal,[]]}}}}},[{init,start_it,1},{init,start_em,1}]}} >> >> >> Since I am a new user I suspect I am doing something obviously wrong. >> If anyone knows what that is I would greatly appreciate a pointer. >> Uninstalling and reinstalling doesn't seem like a workable plan going >> forward. >> >> Matt >> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > From david at rabbitmq.com Fri May 7 13:57:18 2010 From: david at rabbitmq.com (David Wragg) Date: Fri, 07 May 2010 13:57:18 +0100 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: <4BE3013E.9080308@dataraker.com> (Wayne Van Den Handel's message of "Thu\, 06 May 2010 13\:49\:50 -0400") References: <4BE3013E.9080308@dataraker.com> Message-ID: Hi Wayne, Wayne Van Den Handel writes: > Watching top I see RabbitMQ take up more and > more memory over time. It seems that it can only process 30-40k messages > in total/aggregate before it crashes (even though there is never more > than 1000 messages in all queues at one time). I wonder if you could boil down your code to a simple consumer and producer program that demonstrate the problem? We're having trouble explaining the behaviour you describe, so that would probably be the best way to get to the bottom of it. David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware From rafaels at redhat.com Fri May 7 14:00:41 2010 From: rafaels at redhat.com (Rafael Schloming) Date: Fri, 07 May 2010 09:00:41 -0400 Subject: [rabbitmq-discuss] Unofficial guide to AMQP 1.0 PR3 In-Reply-To: References: <4BE1F35A.2060904@lshift.net> Message-ID: <4BE40EF9.7090005@redhat.com> Alexis Richardson wrote: > Davorin > > On Thu, May 6, 2010 at 7:16 AM, Davorin Rusevljan > wrote: >> This of course raises the question should I invest my time in learning 0.8 >> and products that use it, or try to jump the wagon of 1.0. >> >> What would you say, in what state is 1.0 specs is it about to be published >> soon, and what are the plans for RabbitMQ support for it? > > The easiest path is to learn 0-8 or 0-91 which is very similar and better. I would differ with this slightly. Obviously if you need a production quality solution immediately, then you need to evaluate what projects and/or vendors offer right now, however I don't know if diving into a specification targeted at implementors is the best way to do that. Most likely you'll need to decide based on what features you need and whether/how they are exposed by the various implementations. On the other hand if you're interest does lie in the specification, the 1-0 document is specifically intended *not* to require any knowledge of prior versions to comprehend, and in some cases familiarity with older versions can even result in some confusion, although Michael's unofficial guide certainly helps with that. Either way, we could definitely use feedback from people who are reading the 1-0 version of the document with fresh eyes that are not weighed down by the baggage from earlier versions of the spec. So if you have a few hours to spare, any comments would be greatly appreciated, although due to the lack of production ready implementations, this may be as much for the benefit of the working group as it is for you in the short term. --Rafael From wvandenhandel at dataraker.com Fri May 7 14:05:32 2010 From: wvandenhandel at dataraker.com (Wayne Van Den Handel) Date: Fri, 07 May 2010 09:05:32 -0400 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: References: <4BE3013E.9080308@dataraker.com> Message-ID: <4BE4101C.7090209@dataraker.com> An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/8cd9b653/attachment.htm From matthew at lshift.net Fri May 7 14:09:47 2010 From: matthew at lshift.net (Matthew Sackman) Date: Fri, 7 May 2010 14:09:47 +0100 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: <4BE4101C.7090209@dataraker.com> References: <4BE3013E.9080308@dataraker.com> <4BE4101C.7090209@dataraker.com> Message-ID: <20100507130946.GA9487@mrnibble.lshift.net> On Fri, May 07, 2010 at 09:05:32AM -0400, Wayne Van Den Handel wrote: > I argue that is a poor assumption for a default setting. Nothing should > assume out of the box it can have 80% of physical memory (regardless of > what is running). I hope the new persister takes away some of those > assumptions. It should be smart enough to work with the memory > available. We used to try to do this. It's basically impossible for an OS to report how much free memory is available, especially if you want to avoid going into swap. Hence we gave up in favour of a very simple knob that is easily understood and easily tuned. Matthew From alexis.richardson at gmail.com Fri May 7 14:17:34 2010 From: alexis.richardson at gmail.com (Alexis Richardson) Date: Fri, 7 May 2010 14:17:34 +0100 Subject: [rabbitmq-discuss] Unofficial guide to AMQP 1.0 PR3 In-Reply-To: <4BE40EF9.7090005@redhat.com> References: <4BE1F35A.2060904@lshift.net> <4BE40EF9.7090005@redhat.com> Message-ID: +1 Davorin Just to clarify - my comments were under the assumption that you wanted to run something in production some time soon. I fully agree with Rafi that we welcome comments on 1-0, and questions are good too. If you read the spec and do not understand something, let us know. That way it can be clarirfied. alexis On Fri, May 7, 2010 at 2:00 PM, Rafael Schloming wrote: > Alexis Richardson wrote: >> >> Davorin >> >> On Thu, May 6, 2010 at 7:16 AM, Davorin Rusevljan >> wrote: >>> >>> This of course raises the question should I invest my time in learning >>> 0.8 >>> and products that use it, or try to jump the wagon of 1.0. >>> >>> What would you say, in what state is 1.0 specs is it about to be >>> published >>> soon, and what are the plans for RabbitMQ support for it? >> >> The easiest path is to learn 0-8 or 0-91 which is very similar and better. > > I would differ with this slightly. Obviously if you need a production > quality solution immediately, then you need to evaluate what projects and/or > vendors offer right now, however I don't know if diving into a specification > targeted at implementors is the best way to do that. Most likely you'll need > to decide based on what features you need and whether/how they are exposed > by the various implementations. > > On the other hand if you're interest does lie in the specification, the 1-0 > document is specifically intended *not* to require any knowledge of prior > versions to comprehend, and in some cases familiarity with older versions > can even result in some confusion, although Michael's unofficial guide > certainly helps with that. > > Either way, we could definitely use feedback from people who are reading the > 1-0 version of the document with fresh eyes that are not weighed down by the > baggage from earlier versions of the spec. So if you have a few hours to > spare, any comments would be greatly appreciated, although due to the lack > of production ready implementations, this may be as much for the benefit of > the working group as it is for you in the short term. > > --Rafael > > From ctusch at gmail.com Fri May 7 14:22:05 2010 From: ctusch at gmail.com (Christian Tusch) Date: Fri, 7 May 2010 15:22:05 +0200 Subject: [rabbitmq-discuss] Federation in RabbitMQ In-Reply-To: <20100507120110.GK2739@mrnibble.lshift.net> References: <20100507120110.GK2739@mrnibble.lshift.net> Message-ID: My goal is to have reliable message delivery between services with no central server between them. There could be hundreds of services and each one should be able to to send and receive messages from every other i.e. a peer to peer network. In the case of one service not being able to reach another service the message should be transmitted as soon as the connection is available again (also surviving a restart). This would also mean that a formerly disconnected service would receive all missed messages on as soon as it becomes connected again. So one way this could work, I figured, is that I'd need a local broker for each service and queues for each other service a service could possibly talk to. Now every service could subscribe to his personal queue on every other service but I don't know if that's a good idea since this would mean a lot of subscriptions. The other option I've been thinking about is using federation (the way I understand it... but maybe I'm misinterpreting it). Here I would have a local queue again which 'federates' with it's counter part on the receiver's side. The advantage I see with this solution is that the services wouldn't need to subscribe to all the other services' queues by default. I would be really happy to hear your opinion on this matter. On 7 May 2010 14:01, Matthew Sackman wrote: > On Fri, May 07, 2010 at 01:59:31PM +0200, Christian Tusch wrote: >> just a short question: Does RabbitMQ support federation? > > Nope, not yet, but it is on our roadmap. Exactly what do you mean by > federation, and what features would you like to see on this? > > Matthew > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > From david at rabbitmq.com Fri May 7 14:23:01 2010 From: david at rabbitmq.com (David Wragg) Date: Fri, 07 May 2010 14:23:01 +0100 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: <4BE4101C.7090209@dataraker.com> (Wayne Van Den Handel's message of "Fri\, 07 May 2010 09\:05\:32 -0400") References: <4BE3013E.9080308@dataraker.com> <4BE4101C.7090209@dataraker.com> Message-ID: Wayne Van Den Handel writes: > Mathew explained everything with the high memory watermark setting. The > machine is not dedicated to RabbitMQ and is running other things. > Erlang thinks it can have 40% of memory which I guess can go to 80% > before forcing GC. On this machine RabbitMQ crashes well before it > reaches 80% as that much memory is not available. > I argue that is a poor assumption for a default setting. Nothing should > assume out of the box it can have 80% of physical memory (regardless of > what is running). I hope the new persister takes away some of those > assumptions. It should be smart enough to work with the memory > available. Matthew knows more about Erlang behaviour than I do, but I don't find that explanation very satisfying, given your description of the problem. It sounds odd that the Erlang VM would expand to the memory limit before attempting a GC. I would expect it to GC long before that limit was reached, so that in your case, the limit never would be reached. And although the default memory limit percentage is based on the assumption that rabbit has the machine to itself, it's certainly not my experience that you need to dedicate a machine to rabbit for it to operate robustly. So if you are willing to invest the time in turning your python code into something you are willing to share with us, I'd be happy to look at it. David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware From alexis.richardson at gmail.com Fri May 7 14:28:29 2010 From: alexis.richardson at gmail.com (Alexis Richardson) Date: Fri, 7 May 2010 14:28:29 +0100 Subject: [rabbitmq-discuss] Federation in RabbitMQ In-Reply-To: References: <20100507120110.GK2739@mrnibble.lshift.net> Message-ID: Christian We have some customers doing things a bit like that, eg using Shovel. See some of the slides here: http://skillsmatter.com/podcast/cloud-grid/use-cases-for-cloud-messaging See also, attached, some currently *experimental* work towards more general cases, akin to yours. You can read more about this customer's use cases on their (public) wiki page, eg: http://www.oceanobservatories.org/spaces/display/CIDev/Messaging+Service+Specification+V1 alexis On Fri, May 7, 2010 at 2:22 PM, Christian Tusch wrote: > My goal is to have reliable message delivery between services with no > central server between them. There could be hundreds of services and > each one should be able to to send and receive messages from every > other i.e. a peer to peer network. In the case of one service not > being able to reach another service the message should be transmitted > as soon as the connection is available again (also surviving a > restart). This would also mean that a formerly disconnected service > would receive all missed messages on as soon as it becomes connected > again. > > So one way this could work, I figured, is that I'd need a local broker > for each service and queues for each other service a service could > possibly talk to. Now every service could subscribe to his personal > queue on every other service but I don't know if that's a good idea > since this would mean a lot of subscriptions. > > The other option I've been thinking about is using federation (the way > I understand it... but maybe I'm misinterpreting it). Here I would > have a local queue again which 'federates' with it's counter part on > the receiver's side. The advantage I see with this solution is that > the services wouldn't need to subscribe to all the other services' > queues by default. > > I would be really happy to hear your opinion on this matter. > > On 7 May 2010 14:01, Matthew Sackman wrote: >> On Fri, May 07, 2010 at 01:59:31PM +0200, Christian Tusch wrote: >>> just a short question: Does RabbitMQ support federation? >> >> Nope, not yet, but it is on our roadmap. Exactly what do you mean by >> federation, and what features would you like to see on this? >> >> Matthew >> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > -------------- next part -------------- A non-text attachment was scrubbed... Name: AMQP-ScalableFederation_OOI-PrototypeReport-20100105.pdf Type: application/pdf Size: 142258 bytes Desc: not available Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/4a3f91af/attachment-0001.pdf From alexis.richardson at gmail.com Fri May 7 14:35:09 2010 From: alexis.richardson at gmail.com (Alexis Richardson) Date: Fri, 7 May 2010 14:35:09 +0100 Subject: [rabbitmq-discuss] MTU In-Reply-To: References: Message-ID: Gustavo Tell us how big a message you want to send please. alexis On Fri, May 7, 2010 at 2:34 AM, Gustavo Aquino wrote: > Hi, > What is the MTU of a message from RabbitMQ ? 1.500 ? > Regards. > Gustavo > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > From davorin.rusevljan at gmail.com Fri May 7 14:38:30 2010 From: davorin.rusevljan at gmail.com (Davorin Rusevljan) Date: Fri, 7 May 2010 15:38:30 +0200 Subject: [rabbitmq-discuss] Unofficial guide to AMQP 1.0 PR3 In-Reply-To: <4BE40EF9.7090005@redhat.com> References: <4BE1F35A.2060904@lshift.net> <4BE40EF9.7090005@redhat.com> Message-ID: On Fri, May 7, 2010 at 3:00 PM, Rafael Schloming wrote: > I would differ with this slightly. Obviously if you need a production > quality solution immediately, then you need to evaluate what projects and/or > vendors offer right now, however I don't know if diving into a specification > targeted at implementors is the best way to do that. Most likely you'll need > to decide based on what features you need and whether/how they are exposed > by the various implementations. > > On the other hand if you're interest does lie in the specification, the 1-0 > document is specifically intended *not* to require any knowledge of prior > versions to comprehend, and in some cases familiarity with older versions > can even result in some confusion, although Michael's unofficial guide > certainly helps with that. > > Either way, we could definitely use feedback from people who are reading > the 1-0 version of the document with fresh eyes that are not weighed down by > the baggage from earlier versions of the spec. So if you have a few hours to > spare, any comments would be greatly appreciated, although due to the lack > of production ready implementations, this may be as much for the benefit of > the working group as it is for you in the short term. > > my interest in amqp comes has more than one aspect: a) develop one particular app for production b) my general interest in distributed programming (once used to work with CORBA, and implemented part of the in-house orb) c) write amqp smalltalk client mapping as my graduate thesis at college during this summer/autumn a) would probably require 0.x version but potential customer has lost interest, at least in short term. Though, it would be very nice if viable 1.0 server implementation would exist somewhere around end of this year. For b) and c) 1.0 seems to be a better choice, so I guess I will start with it. But I am afraid I will start reading into it more seriously in late june, which might be a bit late for your needs, but, well better ever then never :) Thanks to all for advices. Davorin Rusevljan http://www.cloud208.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/93d092f9/attachment.htm From mmenti at gmail.com Fri May 7 14:43:42 2010 From: mmenti at gmail.com (mmenti at gmail.com) Date: Fri, 7 May 2010 14:43:42 +0100 Subject: [rabbitmq-discuss] high number of unack'ed messages when queue grows large Message-ID: Hi there, new to this list - apologies if this was discusses already recently, but didn't see it when scanning recent archive threads... We've been seeing an issue where the number of unack'ed messages suddenly starts growing much larger than the number of connected consumers, whenever the queue gets to a certain size (somewhere around 50k messages in the queue, with 250 consumers connected). We've noticed that by reducing the number of consumers, the issue becomes less pronounced, but was wondering if anyone else is seeing this, and if there's any ways to avoid this? We're using rabbitmq 1.7.0 on an 64-bit Amazon EC2 Ubuntu 8.04 hardy AMI. Cheers, Mario. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/7e76f2ac/attachment.htm From matthew at lshift.net Fri May 7 14:49:21 2010 From: matthew at lshift.net (Matthew Sackman) Date: Fri, 7 May 2010 14:49:21 +0100 Subject: [rabbitmq-discuss] high number of unack'ed messages when queue grows large In-Reply-To: References: Message-ID: <20100507134921.GB9487@mrnibble.lshift.net> Hi Mario, On Fri, May 07, 2010 at 02:43:42PM +0100, mmenti at gmail.com wrote: > We've been seeing an issue where the number of unack'ed messages suddenly > starts growing much larger than the number of connected consumers, whenever > the queue gets to a certain size (somewhere around 50k messages in the > queue, with 250 consumers connected). We've noticed that by reducing the > number of consumers, the issue becomes less pronounced, but was wondering if > anyone else is seeing this, and if there's any ways to avoid this? We're > using rabbitmq 1.7.0 on an 64-bit Amazon EC2 Ubuntu 8.04 hardy AMI. There are two parts to this issue. Firstly, some priorities of messages internally were changed either in 1.7.1 or 1.7.2 so that acks would have higher priority internally than publishes. This helps solve this problem, and so I would recommend you upgrade. Secondly, you can help by setting a qos prefetch count on your consumers - if, say, you set it to 10, then you're ensuring that each consumer will only receive 10 messages before it must a) ack a message and b) that ack is received *and*processed* by Rabbit. This will ensure the unacked message count stays low. Matthew From mmenti at gmail.com Fri May 7 14:59:26 2010 From: mmenti at gmail.com (mmenti at gmail.com) Date: Fri, 7 May 2010 14:59:26 +0100 Subject: [rabbitmq-discuss] high number of unack'ed messages when queue grows large In-Reply-To: <20100507134921.GB9487@mrnibble.lshift.net> References: <20100507134921.GB9487@mrnibble.lshift.net> Message-ID: On Fri, May 7, 2010 at 2:49 PM, Matthew Sackman wrote: > Hi Mario, > > On Fri, May 07, 2010 at 02:43:42PM +0100, mmenti at gmail.com wrote: > > We've been seeing an issue where the number of unack'ed messages suddenly > > starts growing much larger than the number of connected consumers, > whenever > > the queue gets to a certain size (somewhere around 50k messages in the > > queue, with 250 consumers connected). We've noticed that by reducing the > > number of consumers, the issue becomes less pronounced, but was wondering > if > > anyone else is seeing this, and if there's any ways to avoid this? We're > > using rabbitmq 1.7.0 on an 64-bit Amazon EC2 Ubuntu 8.04 hardy AMI. > > There are two parts to this issue. Firstly, some priorities of messages > internally were changed either in 1.7.1 or 1.7.2 so that acks would have > higher priority internally than publishes. This helps solve this > problem, and so I would recommend you upgrade. > Thanks, good to know - we'll try and do that as soon as is feasible. > > Secondly, you can help by setting a qos prefetch count on your consumers > - if, say, you set it to 10, then you're ensuring that each consumer > will only receive 10 messages before it must a) ack a message and b) > that ack is received *and*processed* by Rabbit. This will ensure the > unacked message count stays low. > Strangely we already have prefetch set to 1 on the consumers, and still see this issue. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/5133c523/attachment.htm From matthew at lshift.net Fri May 7 15:05:02 2010 From: matthew at lshift.net (Matthew Sackman) Date: Fri, 7 May 2010 15:05:02 +0100 Subject: [rabbitmq-discuss] high number of unack'ed messages when queue grows large In-Reply-To: References: <20100507134921.GB9487@mrnibble.lshift.net> Message-ID: <20100507140502.GD9487@mrnibble.lshift.net> On Fri, May 07, 2010 at 02:59:26PM +0100, mmenti at gmail.com wrote: > Strangely we already have prefetch set to 1 on the consumers, and still see > this issue. That's bizarre. Are you doing some gets as well? They're not counted in the qos setting. Also, which client are you using? Matthew From colin at cloudeventprocessing.com Fri May 7 15:53:08 2010 From: colin at cloudeventprocessing.com (Colin Clark) Date: Fri, 07 May 2010 09:53:08 -0500 Subject: [rabbitmq-discuss] graphical admin tools for rabbitmq In-Reply-To: References: <20100507134921.GB9487@mrnibble.lshift.net> Message-ID: <4BE42954.5090205@cloudeventprocessing.com> Is anyone using graphical admin tools for rabbitmq? If so, perhaps point me in the right direction? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/ed440a76/attachment.htm From videlalvaro at gmail.com Fri May 7 15:55:12 2010 From: videlalvaro at gmail.com (Alvaro Videla) Date: Fri, 7 May 2010 22:55:12 +0800 Subject: [rabbitmq-discuss] graphical admin tools for rabbitmq In-Reply-To: <4BE42954.5090205@cloudeventprocessing.com> References: <20100507134921.GB9487@mrnibble.lshift.net> <4BE42954.5090205@cloudeventprocessing.com> Message-ID: I tried this one: http://alicetheapp.com/ And at the company I'm writing our own in PHP which I plan to release soon, Regards, Alvaro On May 7, 2010, at 10:53 PM, Colin Clark wrote: > Is anyone using graphical admin tools for rabbitmq? If so, perhaps point me in the right direction? > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/d0ea754e/attachment-0001.htm From alexis.richardson at gmail.com Fri May 7 15:57:33 2010 From: alexis.richardson at gmail.com (Alexis Richardson) Date: Fri, 7 May 2010 15:57:33 +0100 Subject: [rabbitmq-discuss] graphical admin tools for rabbitmq In-Reply-To: <4BE42954.5090205@cloudeventprocessing.com> References: <20100507134921.GB9487@mrnibble.lshift.net> <4BE42954.5090205@cloudeventprocessing.com> Message-ID: Some are listed here: http://www.rabbitmq.com/how.html On Fri, May 7, 2010 at 3:53 PM, Colin Clark wrote: > Is anyone using graphical admin tools for rabbitmq?? If so, perhaps point me > in the right direction? > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > From emile at rabbitmq.com Fri May 7 16:27:44 2010 From: emile at rabbitmq.com (Emile Joubert) Date: Fri, 07 May 2010 16:27:44 +0100 Subject: [rabbitmq-discuss] MTU In-Reply-To: References: Message-ID: <4BE43170.5060606@rabbitmq.com> Gustavo, The broker will accept an AMQP frame size up to 128Kb during the connection tuning phase of the protocol negotiation. This controls the maximum size of the frames that are accepted and produced by RabbitMQ. The number 1500 sounds more like a transport layer MTU. RabbitMQ is not involved is setting this. -Emile Gustavo Aquino wrote: > Hi, > > What is the MTU of a message from RabbitMQ ? 1.500 ? > > Regards. > > Gustavo > > > ------------------------------------------------------------------------ > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From mmenti at gmail.com Fri May 7 17:32:30 2010 From: mmenti at gmail.com (mmenti at gmail.com) Date: Fri, 7 May 2010 17:32:30 +0100 Subject: [rabbitmq-discuss] high number of unack'ed messages when queue grows large In-Reply-To: <20100507140502.GD9487@mrnibble.lshift.net> References: <20100507134921.GB9487@mrnibble.lshift.net> <20100507140502.GD9487@mrnibble.lshift.net> Message-ID: On Fri, May 7, 2010 at 3:05 PM, Matthew Sackman wrote: > On Fri, May 07, 2010 at 02:59:26PM +0100, mmenti at gmail.com wrote: > > Strangely we already have prefetch set to 1 on the consumers, and still > see > > this issue. > > That's bizarre. Are you doing some gets as well? They're not counted in > the qos setting. Also, which client are you using? > We're using MQ, from the tmm1-amqp gem, and no, not doing any gets.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/24424e02/attachment.htm From jasonjwwilliams at gmail.com Fri May 7 17:40:44 2010 From: jasonjwwilliams at gmail.com (Jason J. W. Williams) Date: Fri, 7 May 2010 10:40:44 -0600 Subject: [rabbitmq-discuss] Unofficial guide to AMQP 1.0 PR3 In-Reply-To: References: <4BE1F35A.2060904@lshift.net> <4BE40EF9.7090005@redhat.com> Message-ID: Regarding AMQP 1.0 itself, perhaps I'm alone here, but it seems overly complicated. To steal a phrase from Joel Spolsky...it wreaks of architecture astronautism. I'm against this idea that we need to wrap the queue, exchange and binding primitives with another layer of abstraction. It looks like we've got this great framework to build trucks...but now somebody's saying if we abstract it we could build space shuttles if you wanted to and reconnect the parts in the future! But in the end you can't really build space shuttles very well and now you've got crappy trucks. My two cents. -J On Fri, May 7, 2010 at 7:38 AM, Davorin Rusevljan wrote: > > On Fri, May 7, 2010 at 3:00 PM, Rafael Schloming wrote: >> >> I would differ with this slightly. Obviously if you need a production >> quality solution immediately, then you need to evaluate what projects and/or >> vendors offer right now, however I don't know if diving into a specification >> targeted at implementors is the best way to do that. Most likely you'll need >> to decide based on what features you need and whether/how they are exposed >> by the various implementations. >> >> On the other hand if you're interest does lie in the specification, the >> 1-0 document is specifically intended *not* to require any knowledge of >> prior versions to comprehend, and in some cases familiarity with older >> versions can even result in some confusion, although Michael's unofficial >> guide certainly helps with that. >> >> Either way, we could definitely use feedback from people who are reading >> the 1-0 version of the document with fresh eyes that are not weighed down by >> the baggage from earlier versions of the spec. So if you have a few hours to >> spare, any comments would be greatly appreciated, although due to the lack >> of production ready implementations, this may be as much for the benefit of >> the working group as it is for you in the short term. >> > > my interest in amqp comes has more than one aspect: > a) develop one particular app for production > b) my general interest in distributed programming (once used to work with > CORBA, and implemented part of the in-house orb) > c) write amqp smalltalk client mapping as my graduate thesis at college > during this summer/autumn > > a) would probably require 0.x version but potential customer has lost > interest, at least in short term. Though, it would be very nice if viable > 1.0 server implementation would exist somewhere around end of this year. > > For b) and c) 1.0 seems to be a better choice, so I guess I will start with > it.? But I am afraid I will start reading into it more seriously in late > june, which might be a bit late for your needs, but, well better ever then > never :) > > Thanks to all for advices. > > Davorin Rusevljan > http://www.cloud208.com/ > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > From hungryblank at gmail.com Fri May 7 17:54:44 2010 From: hungryblank at gmail.com (Paolo Negri) Date: Fri, 7 May 2010 18:54:44 +0200 Subject: [rabbitmq-discuss] Unofficial guide to AMQP 1.0 PR3 In-Reply-To: <4BE40EF9.7090005@redhat.com> References: <4BE1F35A.2060904@lshift.net> <4BE40EF9.7090005@redhat.com> Message-ID: On Fri, May 7, 2010 at 3:00 PM, Rafael Schloming wrote: > Alexis Richardson wrote: >> Davorin >> >> On Thu, May 6, 2010 at 7:16 AM, Davorin Rusevljan >> wrote: >>> This of course raises the question should I invest my time in learning 0.8 >>> and products that use it, or try to jump the wagon of 1.0. >>> >>> What would you say, in what state is 1.0 specs is it about to be published >>> soon, and what are the plans for RabbitMQ support for it? >> >> The easiest path is to learn 0-8 or 0-91 which is very similar and better. > > I would differ with this slightly. Obviously if you need a production > quality solution immediately, then you need to evaluate what projects > and/or vendors offer right now, however I don't know if diving into a > specification targeted at implementors is the best way to do that. Most > likely you'll need to decide based on what features you need and > whether/how they are exposed by the various implementations. > > On the other hand if you're interest does lie in the specification, the > 1-0 document is specifically intended *not* to require any knowledge of > prior versions to comprehend, and in some cases familiarity with older > versions can even result in some confusion, although Michael's > unofficial guide certainly helps with that. > > Either way, we could definitely use feedback from people who are reading > the 1-0 version of the document with fresh eyes that are not weighed > down by the baggage from earlier versions of the spec. So if you have a > few hours to spare, any comments would be greatly appreciated, although > due to the lack of production ready implementations, this may be as much > for the benefit of the working group as it is for you in the short term. Actually I think that having in mind 0-91 helps getting through the new document. IMHO the greater generalization poses a bigger challenge when it comes to explaining and understanding the protocol. Just take as an example the "link" entity. Looking at the picture in page 13 of document [1], you don't see the filter - or a filtering entity at all, messages magically (or because they're clever) follow the right link and go from the initial node to the right node for their color. In many other contexts links are entities where there isn't much action. The usual link abstraction represents a connection or relationship and it either exists or not, may have a direction, but it doesn't operate more complicated operations. If I describe a network connection as a link between two endpoints it means I'm only interested in describing the fact that "this entities are connected". If I describe the same connection but I'm interested in how the packets are routed through and which will be filtered by the firewall, then I'll add firewall and router entities to the schema to justify these properties of the connection. On the same line non destructive links are rather esoteric: a message goes down the link, the link clones the original message, pushes one of the clones down the pipe and sends the other back to the origin node. This is a difficult mental model. You might try to explain it in a way where the original message never leaves the node, but then who clones it? The link can't since the message is not in yet so it would be the node then but why a property of the link would trigger behavior in the node? I know it might sound silly but I see some trickiness. And also from the implementer point of view there's some potential ambiguity. Referring to the old specs might make easier to understand how entities of the new spec should be combined to get started in simple scenarios. The new spec allows for much more flexibility but without the old building blocks in mind the new adopter has IMHO a significant chance of shooting himself in the foot. The point I want to make is that if you read the specs the E. Tufte way, not limited to the visual representation but also extending it to the text there's a weakness in order of cause/effect explanation and concepts representation which wasn't there in previous versions. I'm not saying that the new spec are bad or can't be understood at all, I just think that the learning curve has got steeper. I also openly admit that I'm for sure biased by the fact that I know the old previous versions and then they probably look easier to me just because I know them. To finish I noticed that there are scheduled works for a documents for the broker implementation specs which might clear out part of my concerns (url missing because amqp.org seems to be down or my provider has issues). [1] http://www.amqp.org/confluence/display/AMQP/1-0+Core+Protocol+Spec Thanks, Paolo > > --Rafael > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > From jon.brisbin at npcinternational.com Fri May 7 20:25:12 2010 From: jon.brisbin at npcinternational.com (Jon Brisbin) Date: Fri, 7 May 2010 14:25:12 -0500 Subject: [rabbitmq-discuss] message/artifact chunking? Message-ID: <736738BF-7CDA-4AF0-A111-4ACFD898EF98@npcinternational.com> I'm approaching deploying WARs and other deployment artifacts into my cloud using RabbitMQ (of course! ;) by sending a message containing a URL the consumer could use to download the necessary resource, but I was wondering if I should not so easily dismiss chunking my artifacts and sending them in pieces into the cloud, rather than sending a reference to an HTTP-accessible resource which must be downloaded and deployed? Does anyone use chunking for sending large objects via messages? Is it better or worse than forcing consumers to download their own resource? How do you keep messages in order and make sure your artifacts don't get corrupted? I've never done async chunking before so thought I'd see if anyone has experience in this area... Thanks! Jon Brisbin Portal Webmaster NPC International, Inc. From jpellerin at leapfrogonline.com Fri May 7 20:59:07 2010 From: jpellerin at leapfrogonline.com (Jason Pellerin) Date: Fri, 7 May 2010 15:59:07 -0400 Subject: [rabbitmq-discuss] Unofficial guide to AMQP 1.0 PR3 In-Reply-To: <4BE1F35A.2060904@lshift.net> References: <4BE1F35A.2060904@lshift.net> Message-ID: <201005071559.07067.jpellerin@leapfrogonline.com> On Wednesday 05 May 2010 18:38:18 Michael Bridgen wrote: > Flow control acts like a more fine-grained channel.flow for publishers, > and like basic.qos for consumers; in each case, the receiving side > issues *credit*, which the sending side uses up by transferring > messages. To do something like a basic.get, a consumer issues a single > unit of *credit*, and waits for the single message to come in. I hope I'm missing something, but this description jumped out at me as looking like AMQP 1.0 is going to include one of (IMO) 0-10's biggest mistakes. As someone using messaging mainly in web applications, basic.get is the best thing in amqp. When response time matters, having a single command that polls for a message and returns immediately if one isn't present is incredibly useful. Replacing that with 2+ commands and replacing polling with waiting -- ouch. JP CONFIDENTIALITY NOTE The document(s) accompanying this e-mail transmission, if any, and the e-mail transmittal message containing information from Leapfrog Online Customer Acquisition, LLC is confidential or privileged. The information is intended to be for the use of the individual(s) or entity(ies) named on this e-mail transmission message. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this e-mail is prohibited. If you have received this e-mail in error, please immediately delete this e-mail and notify us by telephone of the error. From wvandenhandel at dataraker.com Fri May 7 21:23:31 2010 From: wvandenhandel at dataraker.com (Wayne Van Den Handel) Date: Fri, 07 May 2010 16:23:31 -0400 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: <20100507120026.GJ2739@mrnibble.lshift.net> References: <4BE3013E.9080308@dataraker.com> <89839F8F-ABB1-4B04-AAAD-633E4CF60185@gmail.com> <20100507120026.GJ2739@mrnibble.lshift.net> Message-ID: <4BE476C3.8040707@dataraker.com> An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/a8e47f88/attachment-0001.htm From colin at cloudeventprocessing.com Fri May 7 21:40:03 2010 From: colin at cloudeventprocessing.com (Colin Clark) Date: Fri, 07 May 2010 15:40:03 -0500 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: <4BE476C3.8040707@dataraker.com> References: <4BE3013E.9080308@dataraker.com> <89839F8F-ABB1-4B04-AAAD-633E4CF60185@gmail.com> <20100507120026.GJ2739@mrnibble.lshift.net> <4BE476C3.8040707@dataraker.com> Message-ID: <4BE47AA3.6050406@cloudeventprocessing.com> Wayne, (and Mathew below please) If you send me your code for the pub's & sub's, I will test it on one of our machines here. I'm on the road this weekend, but will have access to a multi core 64 bit Ubuntu 10.04 with RabbitMQ 1.72, 4gig ram, lots-o-disk, etc. to test on Sunday evening. Also, can you paint the complete picture of what you're doing - based upon what I've read so far, you've got a couple of producers, they're publishing, and then you've got a couple of subscribers dumping to Cassandra. Is that correct? When you say 1000 messages below, is that per second? (I'm easily pushing ~20,000,000 messages a day with RabbitMQ and nada problema and that's nothing compared to other peeps out there so I'm sure that we can find something here) Mathew - I'm going to test with the latest rabbitmq server as is on Ubu 10.04 - if I need to rebuild with this new persistor, can you send me some pointers please (I usually build rabbitmq from source anyway, so maybe I've already got one laying around some where, but I want to make sure) On 5/7/2010 3:23 PM, Wayne Van Den Handel wrote: > I tried the high water mark setting and it now prevents too much > memory from being used (barely) but as my test continued it eventually > had a hard crash for another reason. I was hitting it with 2 producers > throttled to 1000 messages each to a separate queue and 5 consumers. > There was always 1000 messages each in the 2 queues and after 15 > minutes one of the producers crashed with an error (from the logs) > {amqp_error,not_found,"no queue 'xxx' in vhost '/'", queue.declare'}. > I figured this was a timeout or something as the queue did exist and > was being emptied by 3 different consumers actively. > > 5 seconds later the entire process died with an error (from the logs) > "exception on TCP connection ... connection_closed_abruptly" and then > "closing TCP connection". > > I am new to queuing but frankly I don't know what to do. My Experience > with this and other MQ products is less than compelling. Does this > take a ton of tweaking to get stable? How do people manage to push > 500k messages a day? > > > Wayne > > > Matthew Sackman wrote: >> Hi Wayne, >> >> On Fri, May 07, 2010 at 07:48:54AM -0400, Wayne Van Den Handel wrote: >> >>> I will test the basic consume, thanks for the tip. The machine I am running >>> is a single socket 4 core with 4 gigs ram but there are other things running >>> and taking up memory. Is there a gc interval that can be set to get memory >>> back sooner? As I add messages and remove them I can see the exact memory >>> taken with the admin tool and it keeps going up. It seems the rate at which >>> I add to the queue exceeds the ability the clear memory. Basically even >>> though there is little in the queue at any time the memory use keeps going >>> up. >>> >> >> Rabbit assumes it gets the whole machine's memory to itself. If that's >> not the case then you need to reduce the memory high watermark from 0.4 >> to some much lower figure - say, 0.1. >> Seehttp://www.rabbitmq.com/extensions.html#memsup >> >> >>> At this point I am ready to give up until they harden the persister to >>> go to disk as I assume the persister is the problem. >>> >> >> Yup. The new persister currently requires you build from source, but it >> is actively being QA'd and great progress has been made getting it into >> default. We've gone from about 100 hunks difference a couple of weeks >> ago to now about 13 - so things are very much moving in this direction. >> >> In the mean time, many people are already using the new persister, which >> is on branch "bug21673" and if you're comfortable compiling from source >> and using some code which has not yet completed our QA process, then we >> would encourage you to use it, with the understanding that there may >> still be bugs in it. Further battle testing is always welcome and should >> you come across any bugs, any bug reports you make are very gratefully >> received. >> >> Matthew >> >> > > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100507/6d9ef7b1/attachment.htm From matthias at rabbitmq.com Fri May 7 22:30:45 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Fri, 07 May 2010 22:30:45 +0100 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: <4BE476C3.8040707@dataraker.com> References: <4BE3013E.9080308@dataraker.com> <89839F8F-ABB1-4B04-AAAD-633E4CF60185@gmail.com> <20100507120026.GJ2739@mrnibble.lshift.net> <4BE476C3.8040707@dataraker.com> Message-ID: <4BE48685.8070307@rabbitmq.com> Wayne, Wayne Van Den Handel wrote: > I tried the high water mark setting and it now prevents too much memory > from being used (barely) but as my test continued it eventually had a > hard crash for another reason. I was hitting it with 2 producers > throttled to 1000 messages each to a separate queue and 5 consumers. Just to clarify ... the producer limits the publishing rate by checking on the queue size with a passive queue.declare, and only sends more messages when the size is less than 1000, right? How often is that check performed? > There was always 1000 messages each in the 2 queues and after 15 minutes > one of the producers crashed with an error (from the logs) > {amqp_error,not_found,"no queue 'xxx' in vhost '/'", queue.declare'}. I > figured this was a timeout or something as the queue did exist and was > being emptied by 3 different consumers actively. How many queues do you see when running "rabbitmqctl list_queues"? > 5 seconds later the entire process died with an error (from the logs) > "exception on TCP connection ... connection_closed_abruptly" and then > "closing TCP connection". Which process died? The producers/consumers? Rabbit? Are there any other interesting messages in the rabbit.log or rabbit-sasl.log? If you could 1) clear the log files, 2) restart rabbit, 3) do a complete run of your tests until they fail, 4) put the logs somewhere we can see them then we may be able to determine the cause of the problem from looking at the logs. And, as Colin suggests, if you can post the code then we can try to reproduce the problem. > I am new to queuing but frankly I don't know what to do. My Experience > with this and other MQ products is less than compelling. Does this take > a ton of tweaking to get stable? How do people manage to push 500k > messages a day? How many messages did you actually send in your above test? Rabbit can easily route tens of thousands of messages a second. So if your test was running for 15 minutes and the producers/consumers weren't a bottleneck then rabbit will have processed tens of millions of messages in that time. Regards, Matthias. From wvandenhandel at dataraker.com Fri May 7 23:07:38 2010 From: wvandenhandel at dataraker.com (Wayne Van Den Handel) Date: Fri, 07 May 2010 18:07:38 -0400 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: <4BE48685.8070307@rabbitmq.com> References: <4BE3013E.9080308@dataraker.com> <89839F8F-ABB1-4B04-AAAD-633E4CF60185@gmail.com> <20100507120026.GJ2739@mrnibble.lshift.net> <4BE476C3.8040707@dataraker.com> <4BE48685.8070307@rabbitmq.com> Message-ID: <4BE48F2A.5070603@dataraker.com> Matthias Radestock wrote: > Wayne, > > Wayne Van Den Handel wrote: >> I tried the high water mark setting and it now prevents too much >> memory from being used (barely) but as my test continued it >> eventually had a hard crash for another reason. I was hitting it with >> 2 producers throttled to 1000 messages each to a separate queue and 5 >> consumers. > > Just to clarify ... the producer limits the publishing rate by > checking on the queue size with a passive queue.declare, and only > sends more messages when the size is less than 1000, right? > > How often is that check performed? This check is done each time prior to adding another message to the queue. It ensures there is always only ever 1000 max messages. I did this so as to not run of our memory. There is a 10 second sleep if it finds the queue "full" before checking again and adding more records. > >> There was always 1000 messages each in the 2 queues and after 15 >> minutes one of the producers crashed with an error (from the logs) >> {amqp_error,not_found,"no queue 'xxx' in vhost '/'", queue.declare'}. >> I figured this was a timeout or something as the queue did exist and >> was being emptied by 3 different consumers actively. > > How many queues do you see when running "rabbitmqctl list_queues"? There are 9 queues. Only 2 have messages and are being used in this test. Both of the 2 have always ~1000 records. The producers are 100x faster than the consumers. In a production mode there would be a few producers but 50+ consumers. > >> 5 seconds later the entire process died with an error (from the logs) >> "exception on TCP connection ... connection_closed_abruptly" and then >> "closing TCP connection". > > Which process died? The producers/consumers? Rabbit? One of the 2 producer python processes dies and then 5 seconds later Rabbit died. > > Are there any other interesting messages in the rabbit.log or > rabbit-sasl.log? There are no other interesting messages. > > If you could > 1) clear the log files, > 2) restart rabbit, > 3) do a complete run of your tests until they fail, > 4) put the logs somewhere we can see them I am rerunning and will post the logs if/when it crashes. > > then we may be able to determine the cause of the problem from looking > at the logs. > > And, as Colin suggests, if you can post the code then we can try to > reproduce the problem. My code is reading data from a MySQL database as the source so this "scenario" is not portable. > >> I am new to queuing but frankly I don't know what to do. My >> Experience with this and other MQ products is less than compelling. >> Does this take a ton of tweaking to get stable? How do people manage >> to push 500k messages a day? > > How many messages did you actually send in your above test? Rabbit can > easily route tens of thousands of messages a second. So if your test > was running for 15 minutes and the producers/consumers weren't a > bottleneck then rabbit will have processed tens of millions of > messages in that time. The messages are composed of a batch of 10000 records from a database query (6 fields) pickled with python. Performance of Rabbit is great relative to everything else going on (reading from MySQL, python, Cassandra writes). Performance is great, stability is the issue. Could it be the size of the messages? Each Queue with 1000 messages shows a size of 2,914,608 using rabbitmqctl. > > Regards, > > Matthias. > Thanks for your help! Wayne From aquino.gustavo at gmail.com Sat May 8 01:29:41 2010 From: aquino.gustavo at gmail.com (Gustavo Aquino) Date: Fri, 7 May 2010 21:29:41 -0300 Subject: [rabbitmq-discuss] MTU In-Reply-To: References: Message-ID: <44D519E9-AA7A-4DEE-BBE4-5284F8F9E3C4@gmail.com> Hi Alexis, Message have 213 bytes Gustavo On 07/05/2010, at 10:35, Alexis Richardson wrote: > Gustavo > > Tell us how big a message you want to send please. > > alexis > > On Fri, May 7, 2010 at 2:34 AM, Gustavo Aquino > wrote: >> Hi, >> What is the MTU of a message from RabbitMQ ? 1.500 ? >> Regards. >> Gustavo >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> >> From wvandenhandel at dataraker.com Sat May 8 02:27:01 2010 From: wvandenhandel at dataraker.com (Wayne Van Den Handel) Date: Fri, 07 May 2010 21:27:01 -0400 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: <4BE48685.8070307@rabbitmq.com> References: <4BE3013E.9080308@dataraker.com> <89839F8F-ABB1-4B04-AAAD-633E4CF60185@gmail.com> <20100507120026.GJ2739@mrnibble.lshift.net> <4BE476C3.8040707@dataraker.com> <4BE48685.8070307@rabbitmq.com> Message-ID: <4BE4BDE5.2010309@dataraker.com> Here are the logs exactly the same as I reported before right before it crashed (my python code) after 15-20 min of running. The process is still running taking up 79% of memory and 100% of a single core's cpu even though the high water mark was set to 10%. When trying to connect with python the error is socket error 111, connection refused. It crashed (python client) after publishing to the queue a little less than 6000 messages. === Rolling persister log to "/var/lib/rabbitmq/mnesia/rabbit/rabbit_persister.LOG.previous" =ERROR REPORT==== 7-May-2010::22:13:07 === connection <0.9530.0> (running), channel 1 - error: {amqp_error,not_found,"no queue 'Instance.4' in vhost '/'",'queue.declare'} =WARNING REPORT==== 7-May-2010::22:13:08 === exception on TCP connection <0.9530.0> from 10.4.0.151:46046 connection_closed_abruptly =INFO REPORT==== 7-May-2010::22:13:08 === closing TCP connection <0.9530.0> from 10.4.0.151:46046 Matthias Radestock wrote: > Wayne, > > Wayne Van Den Handel wrote: >> I tried the high water mark setting and it now prevents too much >> memory from being used (barely) but as my test continued it >> eventually had a hard crash for another reason. I was hitting it with >> 2 producers throttled to 1000 messages each to a separate queue and 5 >> consumers. > > Just to clarify ... the producer limits the publishing rate by > checking on the queue size with a passive queue.declare, and only > sends more messages when the size is less than 1000, right? > > How often is that check performed? > >> There was always 1000 messages each in the 2 queues and after 15 >> minutes one of the producers crashed with an error (from the logs) >> {amqp_error,not_found,"no queue 'xxx' in vhost '/'", queue.declare'}. >> I figured this was a timeout or something as the queue did exist and >> was being emptied by 3 different consumers actively. > > How many queues do you see when running "rabbitmqctl list_queues"? > >> 5 seconds later the entire process died with an error (from the logs) >> "exception on TCP connection ... connection_closed_abruptly" and then >> "closing TCP connection". > > Which process died? The producers/consumers? Rabbit? > > Are there any other interesting messages in the rabbit.log or > rabbit-sasl.log? > > If you could > 1) clear the log files, > 2) restart rabbit, > 3) do a complete run of your tests until they fail, > 4) put the logs somewhere we can see them > > then we may be able to determine the cause of the problem from looking > at the logs. > > And, as Colin suggests, if you can post the code then we can try to > reproduce the problem. > >> I am new to queuing but frankly I don't know what to do. My >> Experience with this and other MQ products is less than compelling. >> Does this take a ton of tweaking to get stable? How do people manage >> to push 500k messages a day? > > How many messages did you actually send in your above test? Rabbit can > easily route tens of thousands of messages a second. So if your test > was running for 15 minutes and the producers/consumers weren't a > bottleneck then rabbit will have processed tens of millions of > messages in that time. > > Regards, > > Matthias. > -- Wayne Van Den Handel, DataRaker Inc Phone: 703.996.4891 Mobile: 305.849.1794 Skype: wayne.van.den.handel Email: wvandenhandel at dataraker.com From aquino.gustavo at gmail.com Sat May 8 11:01:31 2010 From: aquino.gustavo at gmail.com (Gustavo Aquino) Date: Sat, 8 May 2010 07:01:31 -0300 Subject: [rabbitmq-discuss] MTU In-Reply-To: <4BE43170.5060606@rabbitmq.com> References: <4BE43170.5060606@rabbitmq.com> Message-ID: Emilie, I want to know if I post a message with 213 Bytes whats your MTU? whats the oversize ? And what MTU for high throughput ? if I change my network interface to 2000 MTU Rabbit will follow it ? Gustavo On Fri, May 7, 2010 at 12:27 PM, Emile Joubert wrote: > > Gustavo, > > The broker will accept an AMQP frame size up to 128Kb during the connection > tuning phase of the protocol negotiation. This controls the maximum size of > the frames that are accepted and produced by RabbitMQ. > > The number 1500 sounds more like a transport layer MTU. RabbitMQ is not > involved is setting this. > > -Emile > > > > Gustavo Aquino wrote: > >> Hi, >> >> What is the MTU of a message from RabbitMQ ? 1.500 ? >> >> Regards. >> >> Gustavo >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100508/dabc4498/attachment.htm From david at rabbitmq.com Sat May 8 13:05:39 2010 From: david at rabbitmq.com (David Wragg) Date: Sat, 08 May 2010 13:05:39 +0100 Subject: [rabbitmq-discuss] MTU In-Reply-To: (Gustavo Aquino's message of "Sat\, 8 May 2010 07\:01\:31 -0300") References: <4BE43170.5060606@rabbitmq.com> Message-ID: Hi Gustavo, Gustavo Aquino writes: > I want to know if I post a message with 213 Bytes whats your MTU? whats the > oversize ? And what MTU for high throughput ? if I change my network > interface to 2000 MTU Rabbit will follow it ? The MTU is decided by the operating system's network stack. As Emile said, RabbitMQ has no way to observe or control the MTU. I'm not sure why you would be concerned about the MTU. Perhaps you could tell us what you are trying to achieve, in order for us to give useful advice? Otherwise, MTU settings are probably something to discuss on an operating system specific forum. David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware From rafaels at redhat.com Sat May 8 14:18:42 2010 From: rafaels at redhat.com (Rafael Schloming) Date: Sat, 08 May 2010 09:18:42 -0400 Subject: [rabbitmq-discuss] Unofficial guide to AMQP 1.0 PR3 In-Reply-To: <201005071559.07067.jpellerin@leapfrogonline.com> References: <4BE1F35A.2060904@lshift.net> <201005071559.07067.jpellerin@leapfrogonline.com> Message-ID: <4BE564B2.8020905@redhat.com> Jason Pellerin wrote: > On Wednesday 05 May 2010 18:38:18 Michael Bridgen wrote: > >> Flow control acts like a more fine-grained channel.flow for publishers, >> and like basic.qos for consumers; in each case, the receiving side >> issues *credit*, which the sending side uses up by transferring >> messages. To do something like a basic.get, a consumer issues a single >> unit of *credit*, and waits for the single message to come in. > > I hope I'm missing something, but this description jumped out at me as looking > like AMQP 1.0 is going to include one of (IMO) 0-10's biggest mistakes. > > As someone using messaging mainly in web applications, basic.get is the best > thing in amqp. When response time matters, having a single command that polls > for a message and returns immediately if one isn't present is incredibly > useful. Replacing that with 2+ commands and replacing polling with waiting -- > ouch. What Michael is describing above is correct, but not complete for the case you're interested in. To do a synchronous get you would also put the link in drain mode, and this would guarantee that your credit is consumed immediately, i.e. no waiting. In the simple case this boils down to an interaction similar to basic.get. You send a flow frame (equivalent to basic.get ->), receive either a transfer (<- get-ok), or another flow frame indicating there is nothing available to transfer (<- get-empty). This scheme has the significant added benefit that by issuing N units of credit rather than just one, you can use the same mechanism to poll in batches rather than just one message at a time. While this is an evolution of the same flow control model first introduced in 0-10, I wouldn't be concerned over that as neither one requires you to substitute waiting for polling, and the number of frames/commands required is the same as for the equivalent basic.get interaction. The flow control section of the transport spec includes examples of this and other cases if you're interested in more details. --Rafael From holger.hoffstaette at googlemail.com Sat May 8 18:04:30 2010 From: holger.hoffstaette at googlemail.com (Holger Hoffstaette) Date: Sat, 08 May 2010 19:04:30 +0200 Subject: [rabbitmq-discuss] MTU References: <4BE43170.5060606@rabbitmq.com> Message-ID: On Sat, 08 May 2010 13:05:39 +0100, David Wragg wrote: > Gustavo Aquino > writes: >> I want to know if I post a message with 213 Bytes whats your MTU? whats >> the oversize ? And what MTU for high throughput ? if I change my network >> interface to 2000 MTU Rabbit will follow it ? > > The MTU is decided by the operating system's network stack. As Emile > said, RabbitMQ has no way to observe or control the MTU. It is certainly possible and not at all unusual for network software to observe the MTU of a given interface (via an ioctl) and use it accordingly. The most obvious use case for Rabbit would be batching of small messages, where every payload is just a few bytes. This would significantly reduce kernel context switches and NIC interrupts, at the obvious expense of per-batch latency. The throughput increase in scenarios with many small messages can be quite dramatic, especially when the entire network is using jumbo frames. -h From aquino.gustavo at gmail.com Sat May 8 21:49:55 2010 From: aquino.gustavo at gmail.com (Gustavo Aquino) Date: Sat, 8 May 2010 17:49:55 -0300 Subject: [rabbitmq-discuss] MTU In-Reply-To: References: <4BE43170.5060606@rabbitmq.com> Message-ID: We need to do a calc, we have high volume of messages, and my 213 bytes have a oversize, Rabbit probably put header and etc in message. We know how to configure MTU, just for it we need to know the message size, undertand ? After this calc we will configure MTU in O.S, switchers and routes, MTU is not only used in O.S. You can put your interface with 1500 MTU but if your switcher have 500 MTU it will put limits to you. Regards. On Sat, May 8, 2010 at 9:05 AM, David Wragg wrote: > Hi Gustavo, > > Gustavo Aquino writes: > > I want to know if I post a message with 213 Bytes whats your MTU? whats > the > > oversize ? And what MTU for high throughput ? if I change my network > > interface to 2000 MTU Rabbit will follow it ? > > The MTU is decided by the operating system's network stack. As Emile > said, RabbitMQ has no way to observe or control the MTU. > > I'm not sure why you would be concerned about the MTU. Perhaps you > could tell us what you are trying to achieve, in order for us to give > useful advice? Otherwise, MTU settings are probably something to > discuss on an operating system specific forum. > > David > > -- > David Wragg > Staff Engineer, RabbitMQ > SpringSource, a division of VMware > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100508/2fe9d048/attachment.htm From videlalvaro at gmail.com Sun May 9 04:43:34 2010 From: videlalvaro at gmail.com (Alvaro Videla) Date: Sun, 9 May 2010 11:43:34 +0800 Subject: [rabbitmq-discuss] Haskell Client for RabbitMQ Message-ID: <8F228A77-61DD-422B-B306-F7A0A8DAA2E3@gmail.com> Hi, The other day I found a Haskell client for RabbitMQ http://hackage.haskell.org/packages/archive/amqp/ Maybe it could get included in the list of clients in the http://www.rabbitmq.com/ site Regards, Alvaro From david at rabbitmq.com Sun May 9 11:26:14 2010 From: david at rabbitmq.com (David Wragg) Date: Sun, 09 May 2010 11:26:14 +0100 Subject: [rabbitmq-discuss] MTU In-Reply-To: (Holger Hoffstaette's message of "Sat\, 08 May 2010 19\:04\:30 +0200") References: <4BE43170.5060606@rabbitmq.com> Message-ID: Hi Holger, "Holger Hoffstaette" writes: > On Sat, 08 May 2010 13:05:39 +0100, David Wragg wrote: >> The MTU is decided by the operating system's network stack. As Emile >> said, RabbitMQ has no way to observe or control the MTU. > > It is certainly possible and not at all unusual for network software to > observe the MTU of a given interface (via an ioctl) and use it > accordingly. The most obvious use case for Rabbit would be batching of > small messages, where every payload is just a few bytes. This would > significantly reduce kernel context switches and NIC interrupts, at the > obvious expense of per-batch latency. > The throughput increase in scenarios with many small messages can be quite > dramatic, especially when the entire network is using jumbo frames. What you describe sounds more like the use of corking (e.g. via the TCP_CORK ioctl in Linux) than an interaction with the MTU. I see that the linux ip(7) and tcp(7) man pages do indeed describe some MTU/MSS related options, so my statement was too strong. I should have said that RabbitMQ does nothing to observe or control the MTU. But it appears that the relevant options only allow the MTU to be constrained to a value lower than the network interface's configured MTU, which seems unlikely to be desirable. David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware From alexis at rabbitmq.com Sun May 9 11:54:56 2010 From: alexis at rabbitmq.com (Alexis Richardson) Date: Sun, 9 May 2010 11:54:56 +0100 Subject: [rabbitmq-discuss] Haskell Client for RabbitMQ In-Reply-To: <8F228A77-61DD-422B-B306-F7A0A8DAA2E3@gmail.com> References: <8F228A77-61DD-422B-B306-F7A0A8DAA2E3@gmail.com> Message-ID: Sure... There's a longer list of clients here: http://delicious.com/alexisrichardson/rabbitmq+client (which I need to update..) On Sun, May 9, 2010 at 4:43 AM, Alvaro Videla wrote: > Hi, > > The other day I found a Haskell client for RabbitMQ > > http://hackage.haskell.org/packages/archive/amqp/ > > Maybe it could get included in the list of clients in the http://www.rabbitmq.com/ site > > Regards, > > Alvaro > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > From siddalinga at gmail.com Sun May 9 19:58:31 2010 From: siddalinga at gmail.com (Sidda Eraiah) Date: Sun, 9 May 2010 11:58:31 -0700 (PDT) Subject: [rabbitmq-discuss] Silverlight application with RabbitMQ In-Reply-To: References: <4BD6A64B.2090806@lshift.net> <4BD82BF5.5040209@lshift.net> <4BDA2544.9060107@lshift.net> Message-ID: Jens Aernouts, As you found out Kaazing supports AMQP 0-9-1 protocol. It works against other servers which support AMQP 0-9-1. RabbitMQ support for AMQP 0-9-1 in the development branch is difficult to get it to run but once you get it configured correctly it works fine. With rabbitmq-stomp adapter, you can try Kaazing's StompClient implementation. StompClient provides with capability to send binary data to server as a ByteBuffer. You don't have to worry about the content- length header referred above - it is taken care for you in the StompClient library. Kaazing's StompClient library is available to you in Javascript, Silverlight, .NET, Flex, Java or JavaFX. Best Regards, Sidda On Apr 30, 1:05?pm, "Aernouts Jens" wrote: > Hi everyone, > > I didn't test the STOMP plugin or the new AMQP version yet, so I can't give > new information about it. However, thank you guys for all the feedback. I'm > going to test it after finishing the Silverlight client. > I used all my time working on that and it finally seems to work. I ran the > tests that where delivered with the client and they're all working (except > the tests that didn't even work in the original project). After that, I ran > some example projects, and they're also working. Like I said before, I > commented out the things we don't need (XML things, SSL, ...), so they > aren't working yet. These functions will be fixed afterwards. > About the version: It was simple to change the version by adding the version > number in the AssemblyInfo.cs file. > About the PublicKeyToken: Well, that's what I thought before... However, > thanks for that. > When I finish the project, I'll send it to you and in the meantime, I'll > keep you posted. > Next week I'm on collegetrip, so there won't be any updates... > > Kind Regards > > Jens Aernouts - Student Bachelor of Applied Engineering @ Artesis University > College of Antwerp > > > > > > > Hi Jens, > > > Aernouts Jens wrote: > >> @ Tony: About STOMP: how can our client send a content-length header to > >> the server? We can use the content-length header at our client, but not > >> at the server I think... Can you give some more info about this please? > > > So the STOMP protocol,http://stomp.codehaus.org/Protocol, says this on > > the > > subject: > > > ?"It is recommended that SEND frames include a content-length header which > > ? is a byte count for the length of the message body. If a content-length > > ? header is included, this number of bytes should be read, regardless of > > ? whether or not there are null characters in the body. The frame still > > needs > > ? to be terminated with a null byte and if a content-length is not > > specified, > > ? the first null byte encountered signals the end of the frame." > > > (MESSAGE frames have a very similar paragraph in their description.) > > > The RabbitMQ STOMP server plugin pays attention to this content-length > > header. > > It also *always* supplies a content-length header on MESSAGE whenever the > > message body is non-empty. > > >> I'm currently compiling the client project against the Silverlight > >> runtime, and it seems to work. At this moment, I just rewrote the things > >> we really need (this needs to be fixed as fast as possible), but I'm > >> going to fix the other problems too. > > > Hey this is excellent news! Will you be able to send us a patch? > > >> What should I do to compile it with the right PublicKeyToken and the > >> right version Number? > > > I think you might need our key for that. (Which clearly isn't an option > > :-) ) I > > suspect you will have to recompile the DLLs you have that depend on the > > RabbitMQ client to have less strict dependencies. I'm afraid I'm not an > > expert > > on the vagaries of .NET linking, though :-/ > > > Regards, > > ?Tony > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-disc... at lists.rabbitmq.comhttp://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > -- > You received this message because you are subscribed to the Google Groups "rabbitmq-discuss" group. > To post to this group, send email to rabbitmq-discuss at googlegroups.com. > To unsubscribe from this group, send email to rabbitmq-discuss+unsubscribe at googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rabbitmq-discuss?hl=en. From matthew at lshift.net Sun May 9 20:30:23 2010 From: matthew at lshift.net (Matthew Sackman) Date: Sun, 9 May 2010 20:30:23 +0100 Subject: [rabbitmq-discuss] MTU In-Reply-To: References: <4BE43170.5060606@rabbitmq.com> Message-ID: <20100509193022.GA22170@wellquite.org> On Sat, May 08, 2010 at 05:49:55PM -0300, Gustavo Aquino wrote: > We need to do a calc, we have high volume of messages, and my 213 bytes have > a oversize, Rabbit probably put header and etc in message. Indeed, AMQP does specify the binary wire-level protocol. To find out the exact overheads, I suggest you either read that and do the calculations yourself, or fire up wireshark, send a few such messages, and from the capture, you'll be able to see exactly how much data is being transferred per message. Matthew From aquino.gustavo at gmail.com Sun May 9 21:27:24 2010 From: aquino.gustavo at gmail.com (Gustavo Aquino) Date: Sun, 9 May 2010 17:27:24 -0300 Subject: [rabbitmq-discuss] MTU In-Reply-To: <20100509193022.GA22170@wellquite.org> References: <4BE43170.5060606@rabbitmq.com> <20100509193022.GA22170@wellquite.org> Message-ID: Matthew, Thanks but today we are trying to get this information by this hard way. I'm trying to get a help here, someone may have done it before or RabbitMQ owners can have this number and will help me to get back time loosed hacking packages network. This number is very important, and have significant differences between AMQP implementations. Just for example the Qpid package have a oversize in message larger than RabbitMQ until you can send 32k messages per second using 100mbps you can do only 16k messages per second with Qpid with the same 100mbps. (Messages with 213bytes). Resuming If you will have a high throughput and need high performance make sure that you will not want to use jumbo frame. Regards. On Sun, May 9, 2010 at 4:30 PM, Matthew Sackman wrote: > On Sat, May 08, 2010 at 05:49:55PM -0300, Gustavo Aquino wrote: > > We need to do a calc, we have high volume of messages, and my 213 bytes > have > > a oversize, Rabbit probably put header and etc in message. > > Indeed, AMQP does specify the binary wire-level protocol. To find out > the exact overheads, I suggest you either read that and do the > calculations yourself, or fire up wireshark, send a few such messages, > and from the capture, you'll be able to see exactly how much data is > being transferred per message. > > Matthew > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100509/d47c2b38/attachment.htm From sustrik at 250bpm.com Sun May 9 22:02:11 2010 From: sustrik at 250bpm.com (Martin Sustrik) Date: Sun, 09 May 2010 23:02:11 +0200 Subject: [rabbitmq-discuss] MTU In-Reply-To: References: <4BE43170.5060606@rabbitmq.com> <20100509193022.GA22170@wellquite.org> Message-ID: <4BE722D3.4080702@250bpm.com> Gustavo, > Thanks but today we are trying to get this information by this hard way. > I'm trying to get a help here, someone may have done it before or > RabbitMQ owners can have this number and will help me to get back time > loosed hacking packages network. Per-message overhead for AMQP/0-8 is 50+ bytes. > This number is very important, and have significant differences between > AMQP implementations. Just for example the Qpid package have a oversize > in message larger than RabbitMQ until you can send 32k messages per > second using 100mbps you can do only 16k messages per second with Qpid > with the same 100mbps. (Messages with 213bytes). > > Resuming If you will have a high throughput and need high performance > make sure that you will not want to use jumbo frame. It's very unlikely that MTU size setting will have any impact on performance in your scenario. Martin From aquino.gustavo at gmail.com Sun May 9 22:36:00 2010 From: aquino.gustavo at gmail.com (Gustavo Aquino) Date: Sun, 9 May 2010 18:36:00 -0300 Subject: [rabbitmq-discuss] MTU In-Reply-To: <4BE722D3.4080702@250bpm.com> References: <4BE43170.5060606@rabbitmq.com> <20100509193022.GA22170@wellquite.org> <4BE722D3.4080702@250bpm.com> Message-ID: Martin, On Sun, May 9, 2010 at 6:02 PM, Martin Sustrik wrote: > Gustavo, > > > Thanks but today we are trying to get this information by this hard way. >> I'm trying to get a help here, someone may have done it before or RabbitMQ >> owners can have this number and will help me to get back time loosed hacking >> packages network. >> > > Per-message overhead for AMQP/0-8 is 50+ bytes. > > Thanks, do you know if RabbitMQ cover this pattern ? > This number is very important, and have significant differences between >> AMQP implementations. Just for example the Qpid package have a oversize in >> message larger than RabbitMQ until you can send 32k messages per second >> using 100mbps you can do only 16k messages per second with Qpid with the >> same 100mbps. (Messages with 213bytes). >> >> Resuming If you will have a high throughput and need high performance make >> sure that you will not want to use jumbo frame. >> > > It's very unlikely that MTU size setting will have any impact on > performance in your scenario. > If you use jumbo frame you have a significant impact in your round trip, and make sure we are working to save microseconds/nanoseconds and a simple overhead in round trip message impact us so much. Again the MTU question is to do some calc to refine our network configurations, not a simple configuration in Ethernet interface, a network admin use this calc to project your network to a specific requirement, and when you are talking in microseconds/nanoseconds this configuration made a big difference. For example we are getting bad performance in one of our nodes, and we discovered that router was configured for 576 MTU the result is an overhead of 0.500 us each message with one specific throughput. So the question is not about a MTU problem, but the use of it for a solution. Gustavo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100509/bc53a14a/attachment.htm From sustrik at 250bpm.com Sun May 9 23:08:30 2010 From: sustrik at 250bpm.com (Martin Sustrik) Date: Mon, 10 May 2010 00:08:30 +0200 Subject: [rabbitmq-discuss] MTU In-Reply-To: References: <4BE43170.5060606@rabbitmq.com> <20100509193022.GA22170@wellquite.org> <4BE722D3.4080702@250bpm.com> Message-ID: <4BE7325E.9000107@250bpm.com> Gustavo Aquino wrote: > Martin, > > > On Sun, May 9, 2010 at 6:02 PM, Martin Sustrik > wrote: > > Gustavo, > > > Thanks but today we are trying to get this information by this > hard way. I'm trying to get a help here, someone may have done > it before or RabbitMQ owners can have this number and will help > me to get back time loosed hacking packages network. > > > Per-message overhead for AMQP/0-8 is 50+ bytes. > > Thanks, do you know if RabbitMQ cover this pattern ? Sure. It's minimal size of envelope for AMQP/0-8. Actual envelope may be larger depending on what you put into it (exchange name, topic etc.) > > > This number is very important, and have significant differences > between AMQP implementations. Just for example the Qpid package > have a oversize in message larger than RabbitMQ until you can > send 32k messages per second using 100mbps you can do only 16k > messages per second with Qpid with the same 100mbps. (Messages > with 213bytes). > > Resuming If you will have a high throughput and need high > performance make sure that you will not want to use jumbo frame. > > > It's very unlikely that MTU size setting will have any impact on > performance in your scenario. > > > If you use jumbo frame you have a significant impact in your round trip, > and make sure we are working to save microseconds/nanoseconds and a > simple overhead in round trip message impact us so much. > > Again the MTU question is to do some calc to refine our network > configurations, not a simple configuration in Ethernet interface, a > network admin use this calc to project your network to a specific > requirement, and when you are talking in microseconds/nanoseconds this > configuration made a big difference. For example we are getting bad > performance in one of our nodes, and we discovered that router was > configured for 576 MTU the result is an overhead of 0.500 us each > message with one specific throughput. 0.5 us is presumably less than 1% of overall latency. In fact, it's pretty hard even to measure that kind of latency difference. Just the latency jitter is going to be many times higher than that. What exactly are you trying to achieve? And what are you measuring? Martin From aquino.gustavo at gmail.com Mon May 10 03:58:02 2010 From: aquino.gustavo at gmail.com (Gustavo Aquino) Date: Sun, 9 May 2010 23:58:02 -0300 Subject: [rabbitmq-discuss] MTU In-Reply-To: <4BE7325E.9000107@250bpm.com> References: <4BE43170.5060606@rabbitmq.com> <20100509193022.GA22170@wellquite.org> <4BE722D3.4080702@250bpm.com> <4BE7325E.9000107@250bpm.com> Message-ID: Martin, On Sun, May 9, 2010 at 7:08 PM, Martin Sustrik wrote: > Gustavo Aquino wrote: > >> Martin, >> >> >> >> On Sun, May 9, 2010 at 6:02 PM, Martin Sustrik > sustrik at 250bpm.com>> wrote: >> >> Gustavo, >> >> >> Thanks but today we are trying to get this information by this >> hard way. I'm trying to get a help here, someone may have done >> it before or RabbitMQ owners can have this number and will help >> me to get back time loosed hacking packages network. >> >> >> Per-message overhead for AMQP/0-8 is 50+ bytes. >> >> Thanks, do you know if RabbitMQ cover this pattern ? >> > > Sure. It's minimal size of envelope for AMQP/0-8. Actual envelope may be > larger depending on what you put into it (exchange name, topic etc.) Well MTU is about maximum not minimal, so you sad a interest stuff, let say that we posting message to one exchange named "123"and it routed to one queue named "456" on other machine, so what is MTU from primarily message and what the size of second ? > > > >> >> This number is very important, and have significant differences >> between AMQP implementations. Just for example the Qpid package >> have a oversize in message larger than RabbitMQ until you can >> send 32k messages per second using 100mbps you can do only 16k >> messages per second with Qpid with the same 100mbps. (Messages >> with 213bytes). >> >> Resuming If you will have a high throughput and need high >> performance make sure that you will not want to use jumbo frame. >> >> >> It's very unlikely that MTU size setting will have any impact on >> performance in your scenario. >> >> >> If you use jumbo frame you have a significant impact in your round trip, >> and make sure we are working to save microseconds/nanoseconds and a simple >> overhead in round trip message impact us so much. >> Again the MTU question is to do some calc to refine our network >> configurations, not a simple configuration in Ethernet interface, a network >> admin use this calc to project your network to a specific requirement, and >> when you are talking in microseconds/nanoseconds this configuration made a >> big difference. For example we are getting bad performance in one of our >> nodes, and we discovered that router was configured for 576 MTU the result >> is an overhead of 0.500 us each message with one specific throughput. >> > > 0.5 us is presumably less than 1% of overall latency. In fact, it's pretty > hard even to measure that kind of latency difference. Just the latency > jitter is going to be many times higher than that. > > What exactly are you trying to achieve? And what are you measuring? > Look 0.5us in each message based on a throughput, whats happend if your router have a 576 MTU and your other are sending 1.500 MTU? it will fragmente this packages in 3 packages of 576 MTU, this cause something like a full network bandwidth used, in other words if my router can use only 1.500 MTU how much messages I can put in this value ? this is te basic calc that we want do do and about that we need to know the MTU of RabbitMQ messages understand ? If RabbitMQ are receiving 20 messages per millisecond from publisher and each message have 213 bytes, what the size of packages over network to a consumer or other broker? Gustavo > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100509/324e7d68/attachment.htm From sustrik at 250bpm.com Mon May 10 08:35:24 2010 From: sustrik at 250bpm.com (Martin Sustrik) Date: Mon, 10 May 2010 09:35:24 +0200 Subject: [rabbitmq-discuss] MTU In-Reply-To: References: <4BE43170.5060606@rabbitmq.com> <20100509193022.GA22170@wellquite.org> <4BE722D3.4080702@250bpm.com> <4BE7325E.9000107@250bpm.com> Message-ID: <4BE7B73C.3050407@250bpm.com> Gustavo, > If RabbitMQ are receiving 20 messages per millisecond from publisher and > each message have 213 bytes, what the size of packages over network to a > consumer or other broker? 20 msgs/ms = 1 message each 50 us This means (under Linux at least) that each message is sent as a separate packet. Or maybe three packets per message. It depends on whether RabbitMQ sends message using single OS call or whether is sends each frame separately. Anyway, with 213 bytes of message body and ~60 bytes of AMQP envelope, OS gets 273 bytes each 50 us to send. At this rate OS will probably do no packet coallescing (depends on TCP_NODELAY setting and latency of your link), neither will interrupt coalescing in the NIC kick in (it usually starts working when packets are less than 20-30 us apart). Thus, packets on the network are likely to be ~300 bytes long (taking into account IP and TCP headers). Check it using a packet capturing tool such as wireshark! Anyway, packets 300 bytes long are way below standard MTU (1500) or jumbo frame MTU (9000) -- making the setting pretty irrelevant. Martin From holger.hoffstaette at googlemail.com Mon May 10 09:18:04 2010 From: holger.hoffstaette at googlemail.com (Holger Hoffstaette) Date: Mon, 10 May 2010 10:18:04 +0200 Subject: [rabbitmq-discuss] MTU References: <4BE43170.5060606@rabbitmq.com> Message-ID: On Sun, 09 May 2010 11:26:14 +0100, David Wragg wrote: > writes: >> >> It is certainly possible and not at all unusual for network software to >> observe the MTU of a given interface (via an ioctl) and use it >> accordingly. The most obvious use case for Rabbit would be batching of >> small messages, where every payload is just a few bytes. This would > > What you describe sounds more like the use of corking (e.g. via the > TCP_CORK ioctl in Linux) than an interaction with the MTU. Sort of, kind of - but the point is to do this in userspace, not in the TCP stack. Otherwise you could just re-enable Nagle. > I see that the linux ip(7) and tcp(7) man pages do indeed describe some > MTU/MSS related options, so my statement was too strong. I should have > said that RabbitMQ does nothing to observe or control the MTU. But it Right, and that is really all I was saying. Trying to change the MTU for a regular app is IMHO straight from the "not even wrong" category. cheers Holger From matthew at lshift.net Mon May 10 10:30:16 2010 From: matthew at lshift.net (Matthew Sackman) Date: Mon, 10 May 2010 10:30:16 +0100 Subject: [rabbitmq-discuss] MTU In-Reply-To: <4BE7B73C.3050407@250bpm.com> References: <20100509193022.GA22170@wellquite.org> <4BE722D3.4080702@250bpm.com> <4BE7325E.9000107@250bpm.com> <4BE7B73C.3050407@250bpm.com> Message-ID: <20100510093016.GB23354@mrnibble.lshift.net> On Mon, May 10, 2010 at 09:35:24AM +0200, Martin Sustrik wrote: > Gustavo, > > > If RabbitMQ are receiving 20 messages per millisecond from publisher and > > each message have 213 bytes, what the size of packages over network to a > > consumer or other broker? > > 20 msgs/ms = 1 message each 50 us > > This means (under Linux at least) that each message is sent as a > separate packet. Or maybe three packets per message. It depends on > whether RabbitMQ sends message using single OS call or whether is sends > each frame separately. We make one call to write the entire message. Whilst this, at least in Erlang land, consists of writing an io_list (which is a (potentially deep) list of binaries), last I checked, this is very performant as Erlang maps this to a writev, thus does not have overheads of copying data into one contiguous block before writing. Matthew From aquino.gustavo at gmail.com Mon May 10 12:36:38 2010 From: aquino.gustavo at gmail.com (Gustavo Aquino) Date: Mon, 10 May 2010 08:36:38 -0300 Subject: [rabbitmq-discuss] MTU In-Reply-To: <20100510093016.GB23354@mrnibble.lshift.net> References: <20100509193022.GA22170@wellquite.org> <4BE722D3.4080702@250bpm.com> <4BE7325E.9000107@250bpm.com> <4BE7B73C.3050407@250bpm.com> <20100510093016.GB23354@mrnibble.lshift.net> Message-ID: Thanks guys. On Mon, May 10, 2010 at 6:30 AM, Matthew Sackman wrote: > On Mon, May 10, 2010 at 09:35:24AM +0200, Martin Sustrik wrote: > > Gustavo, > > > > > If RabbitMQ are receiving 20 messages per millisecond from publisher > and > > > each message have 213 bytes, what the size of packages over network to > a > > > consumer or other broker? > > > > 20 msgs/ms = 1 message each 50 us > > > > This means (under Linux at least) that each message is sent as a > > separate packet. Or maybe three packets per message. It depends on > > whether RabbitMQ sends message using single OS call or whether is sends > > each frame separately. > > We make one call to write the entire message. Whilst this, at least in > Erlang land, consists of writing an io_list (which is a (potentially > deep) list of binaries), last I checked, this is very performant as > Erlang maps this to a writev, thus does not have overheads of copying > data into one contiguous block before writing. > > Matthew > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100510/983be3ce/attachment.htm From majek04 at gmail.com Mon May 10 14:36:09 2010 From: majek04 at gmail.com (Marek Majkowski) Date: Mon, 10 May 2010 14:36:09 +0100 Subject: [rabbitmq-discuss] message/artifact chunking? In-Reply-To: <736738BF-7CDA-4AF0-A111-4ACFD898EF98@npcinternational.com> References: <736738BF-7CDA-4AF0-A111-4ACFD898EF98@npcinternational.com> Message-ID: On Fri, May 7, 2010 at 20:25, Jon Brisbin wrote: > I'm approaching deploying WARs and other deployment artifacts into my cloud using RabbitMQ (of course! ;) by sending a message containing a URL the consumer could use to download the necessary resource, but I was wondering if I should not so easily dismiss chunking my artifacts and sending them in pieces into the cloud, rather than sending a reference to an HTTP-accessible resource which must be downloaded and deployed? > > Does anyone use chunking for sending large objects via messages? Is it better or worse than forcing consumers to download their own resource? How do you keep messages in order and make sure your artifacts don't get corrupted? I've never done async chunking before so thought I'd see if anyone has experience in this area... Putting a large file over RabbitMQ obviously will work, but I'd say it's a bad idea. It's just easier to put the big things to some temporary storage, and transfer only light requests over message bus. Putting large stuff on the bus (throughput) can probably effect in a degraded latency. On the other hand, if you aren't worried about latency it might work - and you correctly identified possible complications. Marek Majkowski From tim.fox at jboss.com Mon May 10 14:37:04 2010 From: tim.fox at jboss.com (Tim Fox) Date: Mon, 10 May 2010 14:37:04 +0100 Subject: [rabbitmq-discuss] request for help! Message-ID: <4BE80C00.3080204@jboss.com> I've spent this morning going through the 1.0. PR3 spec, firstly, it's considerably simpler than 0.10, which is great news :) Here's my 2p: One thing I find quite strange is that the core spec doesn't actually seem to mandate any queueing semantics anywhere. I've nothing particularly against that - in fact, the idea that a node can do different types of ordering is actually quite nice, however it's not a queueing protocol. Shouldn't AMQP therefore be renamed to AMTP (Advanced Message Transfer Protocol) ? ;) On a more serious note, my main concerns are mainly around complexity, and verbosity of the wire format. The latter I suppose is not completely independent from the former. Regarding complexity. IMO a large part of the complexity in the spec. seems to come from the way it tries to provide a once and only once delivery guarantee. AIUI the way the spec. implements this guarantee is something like the following when transferring a message from A to B: a) message to be sent from A-->B b) ack sent back from B-->A c) "ack of ack" sent from A-->B - now the delivery tag can be removed from the senders cache This results in a complex set of message states, and puts the burden on both sides of the link to maintain a map of delivery tags, which would also have to be persisted in order to provide once and only delivery guarantee in event of failures of node(s). This will also require several syncs to storage at each transition (for durable messaging). I.e. slow Perhaps a simpler way of getting the once and only guarantee is to forget the delivery tag altogether and allow the sender to specify a de-duplication-id - this is just a user generated id - e.g. a String or a byte[], (can be generated from user application domain concepts - e.g. order number). When sending a message this id can be specified on the transfer. The receiving end can then maintain a de-duplication cache. The de-duplication cache can be implemented as a circular buffer which just overwrites itself when full (this is what we do in HornetQ for reliable bridging between nodes), this means the interaction c) is not necessary or can just be sent intermittently to allow the cache to be cleared. The de-dup cache still requires syncing to non volatile storage to give the once and only once (for durable messages), however it requires less writes than the method described in the spec, and it it has one less interaction (you can get rid of the "ack of ack") On recovery after system failure, the sender just blindly sends the messages again, on receipt at the server any messages seen before will just be rejected. No need for reattaching, sending maps of unsettled transfers or other complex stuff like that. By removing all this delivery tag book-keeping and session re-attachment stuff, which seems unnecessary to me, would result in a dramatic simplification. Regarding verbosity of the wire format for message transfer; if you're just passing a 12 byte message (e.g. stock price - 4 byte identifier + 8 byte price) then the overall encoded size is much higher than 12 bytes. This will kill performance for small messages, making any AMQP compliant implementation unable to compete in the world of lightweight publish/subscribe messaging with other, non AMQP implementations which don't have to conform to the AMQP wire format and can produce much more lightweight encodings. The key to perf with lightweight pub/sub is to make the encoded message size as small as possible and cram as many messages as you can into single socket writes. Now, lightweight pub/sub may not be the target domain for AMQP, in which case it does not need to worry about it, however if a particular messaging system supports multiple protocols including AMQP, it will not do much for the adoption of AMQP if the best performance is not achievable using the AMQP protocol - users will fall back to using the proprietary protocol offered by the vendor. A short comment on transactions. I have to be honest here, I spent about 30 mins reading the chapter on transactions several times. I have to say at the end of it I am not much further understanding it. :( However maybe that is moot - a part of me is thinking that transactions don't really belong in the core spec. Perhaps the core spec should be concerned with allowing the reliable movement of messages between nodes. With that in place, transactions could be layered on top in another spec (?) -- Sent from my BBC Micro Model B Tim Fox JBoss HornetQ - putting the buzz in messaging http://hornetq.org http://hornetq.blogspot.com/ http://twitter.com/hornetq irc://irc.freenode.net:6667#hornetq fox at redhat.com From kenneth at loafman.com Mon May 10 15:05:34 2010 From: kenneth at loafman.com (Kenneth Loafman) Date: Mon, 10 May 2010 09:05:34 -0500 Subject: [rabbitmq-discuss] Firewall Issues Message-ID: <4BE812AE.2020403@loafman.com> Hi, I've got RabbitMQ up on three machines and wanted to add a firewall. The configuration is simple, MQ serves input to P1 and P2 which do all the processing. MQ / \ P1 P2 I opened the port 5672:tcp on all machines and between two machines, MQ and P1, that seems to work. When I added P2, it immediately got a 'connection refused' message. All machines are running Ubuntu 9.10 and rabbitmq-server 1.7.2. P1 and P2 are identical as far as I can tell. Any help would be appreciated. ...Thanks, ...Ken From kenneth at loafman.com Mon May 10 15:21:40 2010 From: kenneth at loafman.com (Kenneth Loafman) Date: Mon, 10 May 2010 09:21:40 -0500 Subject: [rabbitmq-discuss] Firewall Issues In-Reply-To: References: <4BE812AE.2020403@loafman.com> Message-ID: <4BE81674.102@loafman.com> Nope, just a single node service at this point. P1 and P2 do not even have RabbitMQ installed, they are just MQ clients. I should have noted that in my original message. The process has worked well for months prior to adding the firewall. ...Ken Matt Calder wrote: > Ken, > > It looks like you are setting up a cluster, if so, are they sharing > the same cookie? > > I just went through starting a cluster here is my step-by-step: > > 1) Start a cluster of rabbits. > Assume cluster is on: hostA, hostB (for example) > > # The rabbitmq processes must be running with the same cookie > hostA> sudo rabbitmqctl stop > hostA> sudo /etc/init.d/rabbitmq-server stop > hostA> sudo rm ~rabbitmq/.erlang.cookie > hostA> sudo echo ABC123 | sudo tee ~rabbitmq/.erlang.cookie > hostA> sudo chmod 400 ~rabbitmq/.erlang.cookie > hostA> sudo chown rabbitmq ~rabbitmq/.erlang.cookie > hostA> sudo chgrp rabbitmq ~rabbitmq/.erlang.cookie > hostA> sudo /etc/init.d/rabbitmq-server start > > repeat for hostB > > # On join hostB to hostA > hostB> sudo rabbitmqctl stop_app > hostB> sudo rabbitmqctl reset > hostB> sudo rabbitmqctl cluster rabbit at hostA > > Hope that helps. > > Matt > > > On Mon, May 10, 2010 at 10:05 AM, Kenneth Loafman wrote: >> Hi, >> >> I've got RabbitMQ up on three machines and wanted to add a firewall. >> The configuration is simple, MQ serves input to P1 and P2 which do all >> the processing. >> >> MQ >> / \ >> P1 P2 >> >> I opened the port 5672:tcp on all machines and between two machines, MQ >> and P1, that seems to work. When I added P2, it immediately got a >> 'connection refused' message. All machines are running Ubuntu 9.10 and >> rabbitmq-server 1.7.2. P1 and P2 are identical as far as I can tell. >> >> Any help would be appreciated. >> >> Thanks, >> ...Ken >> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> > From kenneth at loafman.com Mon May 10 15:29:14 2010 From: kenneth at loafman.com (Kenneth Loafman) Date: Mon, 10 May 2010 09:29:14 -0500 Subject: [rabbitmq-discuss] Firewall Issues In-Reply-To: References: <4BE812AE.2020403@loafman.com> <4BE81674.102@loafman.com> Message-ID: <4BE8183A.1030504@loafman.com> What erlang ports? Just 5672:tcp. ...Ken Matt Calder wrote: > Ken, > > Are the erlang ports open? > > Matt > > On Mon, May 10, 2010 at 10:21 AM, Kenneth Loafman wrote: >> Nope, just a single node service at this point. P1 and P2 do not even >> have RabbitMQ installed, they are just MQ clients. I should have noted >> that in my original message. >> >> The process has worked well for months prior to adding the firewall. >> >> ...Ken >> >> Matt Calder wrote: >>> Ken, >>> >>> It looks like you are setting up a cluster, if so, are they sharing >>> the same cookie? >>> >>> I just went through starting a cluster here is my step-by-step: >>> >>> 1) Start a cluster of rabbits. >>> Assume cluster is on: hostA, hostB (for example) >>> >>> # The rabbitmq processes must be running with the same cookie >>> hostA> sudo rabbitmqctl stop >>> hostA> sudo /etc/init.d/rabbitmq-server stop >>> hostA> sudo rm ~rabbitmq/.erlang.cookie >>> hostA> sudo echo ABC123 | sudo tee ~rabbitmq/.erlang.cookie >>> hostA> sudo chmod 400 ~rabbitmq/.erlang.cookie >>> hostA> sudo chown rabbitmq ~rabbitmq/.erlang.cookie >>> hostA> sudo chgrp rabbitmq ~rabbitmq/.erlang.cookie >>> hostA> sudo /etc/init.d/rabbitmq-server start >>> >>> repeat for hostB >>> >>> # On join hostB to hostA >>> hostB> sudo rabbitmqctl stop_app >>> hostB> sudo rabbitmqctl reset >>> hostB> sudo rabbitmqctl cluster rabbit at hostA >>> >>> Hope that helps. >>> >>> Matt >>> >>> >>> On Mon, May 10, 2010 at 10:05 AM, Kenneth Loafman wrote: >>>> Hi, >>>> >>>> I've got RabbitMQ up on three machines and wanted to add a firewall. >>>> The configuration is simple, MQ serves input to P1 and P2 which do all >>>> the processing. >>>> >>>> MQ >>>> / \ >>>> P1 P2 >>>> >>>> I opened the port 5672:tcp on all machines and between two machines, MQ >>>> and P1, that seems to work. When I added P2, it immediately got a >>>> 'connection refused' message. All machines are running Ubuntu 9.10 and >>>> rabbitmq-server 1.7.2. P1 and P2 are identical as far as I can tell. >>>> >>>> Any help would be appreciated. >>>> >>>> Thanks, >>>> ...Ken >>>> >>>> _______________________________________________ >>>> rabbitmq-discuss mailing list >>>> rabbitmq-discuss at lists.rabbitmq.com >>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>>> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> > From cctrieloff at redhat.com Mon May 10 15:35:17 2010 From: cctrieloff at redhat.com (Carl Trieloff) Date: Mon, 10 May 2010 10:35:17 -0400 Subject: [rabbitmq-discuss] Unofficial guide to AMQP 1.0 PR3 In-Reply-To: <201005071559.07067.jpellerin@leapfrogonline.com> References: <4BE1F35A.2060904@lshift.net> <201005071559.07067.jpellerin@leapfrogonline.com> Message-ID: <4BE819A5.7030104@redhat.com> On 05/07/2010 03:59 PM, Jason Pellerin wrote: >> Flow control acts like a more fine-grained channel.flow for publishers, >> > and like basic.qos for consumers; in each case, the receiving side >> > issues*credit*, which the sending side uses up by transferring >> > messages. To do something like a basic.get, a consumer issues a single >> > unit of*credit*, and waits for the single message to come in. >> > I hope I'm missing something, but this description jumped out at me as looking > like AMQP 1.0 is going to include one of (IMO) 0-10's biggest mistakes. > > As someone using messaging mainly in web applications, basic.get is the best > thing in amqp. When response time matters, having a single command that polls > for a message and returns immediately if one isn't present is incredibly > useful. Replacing that with 2+ commands and replacing polling with waiting -- > ouch. > Having a poll is just a matter of setting the properties. For example Qpid supports a 'get()' opperation with AMQP 0-10. I have not worked through the options in detail in 1-0, but it takes this one step further with not only allowing a get(), but you can even do a get() in a single stateless call i.e. (open get() close) in a single command sequence. This is particularly usefull for web-apps for example and better than any previous version as no connection state needs to kept open as with all previous versions. Carl. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100510/bd59d3f4/attachment-0001.htm From colin at cloudeventprocessing.com Mon May 10 15:32:34 2010 From: colin at cloudeventprocessing.com (Colin Clark) Date: Mon, 10 May 2010 09:32:34 -0500 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE80C00.3080204@jboss.com> References: <4BE80C00.3080204@jboss.com> Message-ID: <4BE81902.4090502@cloudeventprocessing.com> In regards to the once-and-only-once discussion below: In many financial formats, like FIX and others, we utilize message ID's that help with this behavior a lot. It also prevents from messages being delivered out of sequence. For example. Client logs in - server and client at message ID of 0, every message that the server sends has an incremented ID, if the client receives an unexpected ID, it can either request a retransmit from the last known or kill the session, when a client logs back in, the client logs in with the expected ID, server & client negotiate and session resumes. (there are id's for both the client & server messages, both incremented for each message and the above behavior applies on both sides of the connection) FIX employs an optimistic delivery protocol, i.e., assume that it was received. There is no session level ack. Only an ack at the application level; and that ack is not mandatory. Use of the message ID provides the once & only once and in order semantics required for trading; a behavior that is obviously very useful elsewhere as well. Using sequence #'s also allows for advanced concepts such as flow control - I haven't read enough of the spec yet to see if that's a feature yet or not. I do agree, if a message is sent, then an ack is waited for, sending an ack of ack seems a little over kill to me. Perhaps it's time for me to read the whole spec again. On 5/10/2010 8:37 AM, Tim Fox wrote: > I've spent this morning going through the 1.0. PR3 spec, firstly, it's > considerably simpler than 0.10, which is great news :) > > Here's my 2p: > > One thing I find quite strange is that the core spec doesn't actually > seem to mandate any queueing semantics anywhere. I've nothing > particularly against that - in fact, the idea that a node can do > different types of ordering is actually quite nice, however it's not a > queueing protocol. Shouldn't AMQP therefore be renamed to AMTP (Advanced > Message Transfer Protocol) ? ;) > > On a more serious note, my main concerns are mainly around complexity, > and verbosity of the wire format. The latter I suppose is not completely > independent from the former. > > Regarding complexity. IMO a large part of the complexity in the spec. > seems to come from the way it tries to provide a once and only once > delivery guarantee. AIUI the way the spec. implements this guarantee is > something like the following when transferring a message from A to B: > > a) message to be sent from A-->B > b) ack sent back from B-->A > c) "ack of ack" sent from A-->B - now the delivery tag can be removed > from the senders cache > > This results in a complex set of message states, and puts the burden on > both sides of the link to maintain a map of delivery tags, which would > also have to be persisted in order to provide once and only delivery > guarantee in event of failures of node(s). This will also require > several syncs to storage at each transition (for durable messaging). > I.e. slow > > Perhaps a simpler way of getting the once and only guarantee is to > forget the delivery tag altogether and allow the sender to specify a > de-duplication-id - this is just a user generated id - e.g. a String or > a byte[], (can be generated from user application domain concepts - e.g. > order number). > > When sending a message this id can be specified on the transfer. The > receiving end can then maintain a de-duplication cache. The > de-duplication cache can be implemented as a circular buffer which just > overwrites itself when full (this is what we do in HornetQ for reliable > bridging between nodes), this means the interaction c) is not necessary > or can just be sent intermittently to allow the cache to be cleared. The > de-dup cache still requires syncing to non volatile storage to give the > once and only once (for durable messages), however it requires less > writes than the method described in the spec, and it it has one less > interaction (you can get rid of the "ack of ack") > > On recovery after system failure, the sender just blindly sends the > messages again, on receipt at the server any messages seen before will > just be rejected. No need for reattaching, sending maps of unsettled > transfers or other complex stuff like that. > > By removing all this delivery tag book-keeping and session re-attachment > stuff, which seems unnecessary to me, would result in a dramatic > simplification. > > Regarding verbosity of the wire format for message transfer; if you're > just passing a 12 byte message (e.g. stock price - 4 byte identifier + 8 > byte price) then the overall encoded size is much higher than 12 bytes. > > This will kill performance for small messages, making any AMQP compliant > implementation unable to compete in the world of lightweight > publish/subscribe messaging with other, non AMQP implementations which > don't have to conform to the AMQP wire format and can produce much more > lightweight encodings. The key to perf with lightweight pub/sub is to > make the encoded message size as small as possible and cram as many > messages as you can into single socket writes. > > Now, lightweight pub/sub may not be the target domain for AMQP, in which > case it does not need to worry about it, however if a particular > messaging system supports multiple protocols including AMQP, it will not > do much for the adoption of AMQP if the best performance is not > achievable using the AMQP protocol - users will fall back to using the > proprietary protocol offered by the vendor. > > A short comment on transactions. I have to be honest here, I spent about > 30 mins reading the chapter on transactions several times. I have to say > at the end of it I am not much further understanding it. :( > > However maybe that is moot - a part of me is thinking that transactions > don't really belong in the core spec. Perhaps the core spec should be > concerned with allowing the reliable movement of messages between nodes. > With that in place, transactions could be layered on top in another spec (?) > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100510/689406fc/attachment.htm From kenneth at loafman.com Mon May 10 15:35:21 2010 From: kenneth at loafman.com (Kenneth Loafman) Date: Mon, 10 May 2010 09:35:21 -0500 Subject: [rabbitmq-discuss] Firewall Issues In-Reply-To: References: <4BE812AE.2020403@loafman.com> <4BE81674.102@loafman.com> <4BE8183A.1030504@loafman.com> Message-ID: <4BE819A9.4050707@loafman.com> Will test it tonight and let you know. ...Thanks, ...Ken Matt Calder wrote: > By default erlang uses 4369. > > Matt > > On Mon, May 10, 2010 at 10:29 AM, Kenneth Loafman wrote: >> What erlang ports? Just 5672:tcp. >> >> ...Ken >> >> Matt Calder wrote: >>> Ken, >>> >>> Are the erlang ports open? >>> >>> Matt >>> >>> On Mon, May 10, 2010 at 10:21 AM, Kenneth Loafman wrote: >>>> Nope, just a single node service at this point. P1 and P2 do not even >>>> have RabbitMQ installed, they are just MQ clients. I should have noted >>>> that in my original message. >>>> >>>> The process has worked well for months prior to adding the firewall. >>>> >>>> ...Ken >>>> >>>> Matt Calder wrote: >>>>> Ken, >>>>> >>>>> It looks like you are setting up a cluster, if so, are they sharing >>>>> the same cookie? >>>>> >>>>> I just went through starting a cluster here is my step-by-step: >>>>> >>>>> 1) Start a cluster of rabbits. >>>>> Assume cluster is on: hostA, hostB (for example) >>>>> >>>>> # The rabbitmq processes must be running with the same cookie >>>>> hostA> sudo rabbitmqctl stop >>>>> hostA> sudo /etc/init.d/rabbitmq-server stop >>>>> hostA> sudo rm ~rabbitmq/.erlang.cookie >>>>> hostA> sudo echo ABC123 | sudo tee ~rabbitmq/.erlang.cookie >>>>> hostA> sudo chmod 400 ~rabbitmq/.erlang.cookie >>>>> hostA> sudo chown rabbitmq ~rabbitmq/.erlang.cookie >>>>> hostA> sudo chgrp rabbitmq ~rabbitmq/.erlang.cookie >>>>> hostA> sudo /etc/init.d/rabbitmq-server start >>>>> >>>>> repeat for hostB >>>>> >>>>> # On join hostB to hostA >>>>> hostB> sudo rabbitmqctl stop_app >>>>> hostB> sudo rabbitmqctl reset >>>>> hostB> sudo rabbitmqctl cluster rabbit at hostA >>>>> >>>>> Hope that helps. >>>>> >>>>> Matt >>>>> >>>>> >>>>> On Mon, May 10, 2010 at 10:05 AM, Kenneth Loafman wrote: >>>>>> Hi, >>>>>> >>>>>> I've got RabbitMQ up on three machines and wanted to add a firewall. >>>>>> The configuration is simple, MQ serves input to P1 and P2 which do all >>>>>> the processing. >>>>>> >>>>>> MQ >>>>>> / \ >>>>>> P1 P2 >>>>>> >>>>>> I opened the port 5672:tcp on all machines and between two machines, MQ >>>>>> and P1, that seems to work. When I added P2, it immediately got a >>>>>> 'connection refused' message. All machines are running Ubuntu 9.10 and >>>>>> rabbitmq-server 1.7.2. P1 and P2 are identical as far as I can tell. >>>>>> >>>>>> Any help would be appreciated. >>>>>> >>>>>> Thanks, >>>>>> ...Ken >>>>>> >>>>>> _______________________________________________ >>>>>> rabbitmq-discuss mailing list >>>>>> rabbitmq-discuss at lists.rabbitmq.com >>>>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>>>>> >>>> _______________________________________________ >>>> rabbitmq-discuss mailing list >>>> rabbitmq-discuss at lists.rabbitmq.com >>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>>> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> > From rob.j.godfrey at gmail.com Mon May 10 16:18:06 2010 From: rob.j.godfrey at gmail.com (Robert Godfrey) Date: Mon, 10 May 2010 17:18:06 +0200 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE80C00.3080204@jboss.com> References: <4BE80C00.3080204@jboss.com> Message-ID: Hi Tim, thanks for the feedback On 10 May 2010 15:37, Tim Fox wrote: > I've spent this morning going through the 1.0. PR3 spec, firstly, it's > considerably simpler than 0.10, which is great news :) > > Here's my 2p: > > One thing I find quite strange is that the core spec doesn't actually > seem to mandate any queueing semantics anywhere. I've nothing > particularly against that - in fact, the idea that a node can do > different types of ordering is actually quite nice, however it's not a > queueing protocol. Shouldn't AMQP therefore be renamed to AMTP (Advanced > Message Transfer Protocol) ? ;) :-) It is deliberate that we've chosen to break the specification up into distinct layers. The parts covered in PR3 do not form the "whole" of AMQP but what we have been so far referring to as the "core". It is in the plan that on top of this will come definitions of specific node types (such as Queues) and the behaviours that one can expect from them. An "AMQP Broker" will be defined in terms the node types and behaviours required to be supported. That is not to say that you can't have a messaging broker which speaks AMQP which is not an "AMQP Broker". One of the design goals was to enable vendors of existing messaging products to layer AMQP as a protocol on top of their existing product - something that proved very difficult with the 0-x protocols due to the very specific model it imposed on broker behaviour right down to the transport layer. > > On a more serious note, my main concerns are mainly around complexity, > and verbosity of the wire format. The latter I suppose is not completely > independent from the former. > > Regarding complexity. IMO a large part of the complexity in the spec. > seems to come from the way it tries to provide a once and only once > delivery guarantee. AIUI the way the spec. implements this guarantee is > something like the following when transferring a message from A to B: > > a) message to be sent from A-->B > b) ack sent back from B-->A > c) "ack of ack" sent from A-->B - now the delivery tag can be removed > from the senders cache > Just to be clear, while this behaviour is permitted under the spec, it is not mandated that every message exchange follows this pattern. Firstly the protocol will support different reliability guarantees agreed at the link level (at most once, at least once, exactly once, etc) which will allow simpler patterns where the extra guarantees are not required. Secondly even when performing exactly once messaging these acknowledgements are expected to be batched if you are looking for reasonable performance. > This results in a complex set of message states, and puts the burden on > both sides of the link to maintain a map of delivery tags, which would > also have to be persisted in order to provide once and only delivery > guarantee in event of failures of node(s). This will also require > several syncs to storage at each transition (for durable messaging). > I.e. slow For each message you will need to sync when it is assigned to a consumer and when it is dequeued if you want exactly once. I'm not sure how you can easily do it with fewer (other than combining the enqueue with an assignment to a consumer). If you are happy with at least once then you can remove the first of these (though you'd still need the enqueue sync - obviously). If you want at most once you, dequeue on sending. > Perhaps a simpler way of getting the once and only guarantee is to > forget the delivery tag altogether and allow the sender to specify a > de-duplication-id - this is just a user generated id - e.g. a String or > a byte[], (can be generated from user application domain concepts - e.g. > order number). I'm not sure what the difference between this and the delivery-tag is... or are you just suggesting that in the case where you don't need exactly once then you don't need a semantically meaningful (at the application level) tag? > When sending a message this id can be specified on the transfer. The > receiving end can then maintain a de-duplication cache. The > de-duplication cache can be implemented as a circular buffer which just > overwrites itself when full (this is what we do in HornetQ for reliable > bridging between nodes), this means the interaction c) is not necessary > or can just be sent intermittently to allow the cache to be cleared. The > de-dup cache still requires syncing to non volatile storage to give the > once and only once (for durable messages), however it requires less > writes than the method described in the spec, and it it has one less > interaction (you can get rid of the "ack of ack") This is pretty much how the spec works. There is nothing to prevent you implementing your de-dup cache as a circular buffer. One thing that was missed in PR3 but has been rectified since we sent it out is that sequence-no for the low watermark of unsettled transfers should be on the transfer frame as well as the disposition frame. Inspecting this value allows you to clear from your circular buffer safely. > On recovery after system failure, the sender just blindly sends the > messages again, on receipt at the server any messages seen before will > just be rejected. No need for reattaching, sending maps of unsettled > transfers or other complex stuff like that. > By removing all this delivery tag book-keeping and session re-attachment > stuff, which seems unnecessary to me, would result in a dramatic > simplification. I presume by this you mean link reattachment - there is no concept of session reattachment in PR3. I'm not sure exactly how much simplification this gives... the retained state needs to be pretty much the same (the sender needs to hold the in-doubt messages, the receiver the de-dup ids of the in-doubt transfers). On re-attach all we are doing is sending this state (which you will be keeping anyway). The advantage in terms of not sending unnecessary duplicates is possibly only marginal for many people (though it does help solve the case of resuming an interrupted transfer of a large message), however it also allows the disambiguation of the case where one side has actually lost state, so we can determine what to do with the messages where we can no-longer guarantee exactly once. Sending as maps rather than as a sequence allows each end to retain the data without necessarily having to remember the sequence. the point is really that you can *choose* to implement this all using circular buffers (you don't *need* to implement a map)... but we aren't forcing clients to persistently remember the sequence in which they sent/received messages. > Regarding verbosity of the wire format for message transfer; if you're > just passing a 12 byte message (e.g. stock price - 4 byte identifier + 8 > byte price) then the overall encoded size is much higher than 12 bytes. > > This will kill performance for small messages, making any AMQP compliant > implementation unable to compete in the world of lightweight > publish/subscribe messaging with other, non AMQP implementations which > don't have to conform to the AMQP wire format and can produce much more > lightweight encodings. The key to perf with lightweight pub/sub is to > make the encoded message size as small as possible and cram as many > messages as you can into single socket writes. > > Now, lightweight pub/sub may not be the target domain for AMQP, in which > case it does not need to worry about it, however if a particular > messaging system supports multiple protocols including AMQP, it will not > do much for the adoption of AMQP if the best performance is not > achievable using the AMQP protocol - users will fall back to using the > proprietary protocol offered by the vendor. I haven't actually worked out what the per message overhead will be... we've tried to make as many fields optional as possible to reduce overhead, and we'll continue to do so. The efficiency (in terms of number of bytes per value) of the encoding has not been a focus simply because the protocol is designed to admit alternative encodings at a later date. In many use cases we've seen that the ease of encoding/decoding has actually proven a bigger determinant on performance than the number of bytes on the wire. Our view was that trying to optimise this stuff too early would perhaps lead us to focus on the wrong areas. habing said all this, AMQP is specifically not targeting high volume low latency pub/sub at this juncture... and this is an area where protocols targeted at that market will always likely have an advantage over a more general protocol. > A short comment on transactions. I have to be honest here, I spent about > 30 mins reading the chapter on transactions several times. I have to say > at the end of it I am not much further understanding it. :( > > However maybe that is moot - a part of me is thinking that transactions > don't really belong in the core spec. Perhaps the core spec should be > concerned with allowing the reliable movement of messages between nodes. > With that in place, transactions could be layered on top in another spec (?) > The ideas is that the transactions are already layered on top of the transport rather than as a part of it as in prior versions of AMQP. It is quite possible that the transaction documentation needs a little more polishing to make this clear :-) There will more more work coming out on this, including more detailed work on distributed transactions. > > -- > Sent from my BBC Micro Model B The computer of champions :-) -- Rob From rafaels at redhat.com Mon May 10 16:18:25 2010 From: rafaels at redhat.com (Rafael Schloming) Date: Mon, 10 May 2010 11:18:25 -0400 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE80C00.3080204@jboss.com> References: <4BE80C00.3080204@jboss.com> Message-ID: <4BE823C1.5090400@redhat.com> Tim Fox wrote: > I've spent this morning going through the 1.0. PR3 spec, firstly, it's > considerably simpler than 0.10, which is great news :) > > Here's my 2p: > > One thing I find quite strange is that the core spec doesn't actually > seem to mandate any queueing semantics anywhere. I've nothing > particularly against that - in fact, the idea that a node can do > different types of ordering is actually quite nice, however it's not a > queueing protocol. Shouldn't AMQP therefore be renamed to AMTP (Advanced > Message Transfer Protocol) ? ;) The PDF posted actually contains more than one specification. The Transport specification would actually be appropriately named AMTP if we felt like giving it a name. The Messaging specification starts to introduce the basics of store and forward style intermediary nodes, although this probably needs to be clarified a little as mentioned in some of the other threads here, but the intention is to be able to support simple queuing scenarios based solely on the Messaging specification (and its dependents). We do intend to define more specialized node behaviors in layered specifications, as well as the specific node types that an "AMQP Broker" is required to support. However these layered specifications are still in progress. > On a more serious note, my main concerns are mainly around complexity, > and verbosity of the wire format. The latter I suppose is not completely > independent from the former. > > Regarding complexity. IMO a large part of the complexity in the spec. > seems to come from the way it tries to provide a once and only once > delivery guarantee. AIUI the way the spec. implements this guarantee is > something like the following when transferring a message from A to B: > > a) message to be sent from A-->B > b) ack sent back from B-->A > c) "ack of ack" sent from A-->B - now the delivery tag can be removed > from the senders cache > > This results in a complex set of message states, and puts the burden on > both sides of the link to maintain a map of delivery tags, which would > also have to be persisted in order to provide once and only delivery > guarantee in event of failures of node(s). This will also require > several syncs to storage at each transition (for durable messaging). > I.e. slow This interaction is only slow if the Sender or Receiver waits for one message to be settled before moving onto the next. While the spec permits this it does not mandate it, in fact it is really an application choice how large a window of unsettled deliveries to permit, e.g. akin to a JMS producer choosing sync vs async publish, or a JMS consumer choosing sync vs async acknowledgment. Likewise the choice to persist delivery state is really up to the application again, i.e. based on whether the message is persistent or not. > Perhaps a simpler way of getting the once and only guarantee is to > forget the delivery tag altogether and allow the sender to specify a > de-duplication-id - this is just a user generated id - e.g. a String or > a byte[], (can be generated from user application domain concepts - e.g. > order number). > > When sending a message this id can be specified on the transfer. The > receiving end can then maintain a de-duplication cache. The > de-duplication cache can be implemented as a circular buffer which just > overwrites itself when full (this is what we do in HornetQ for reliable > bridging between nodes), this means the interaction c) is not necessary > or can just be sent intermittently to allow the cache to be cleared. The > de-dup cache still requires syncing to non volatile storage to give the > once and only once (for durable messages), however it requires less > writes than the method described in the spec, and it it has one less > interaction (you can get rid of the "ack of ack") What you're describing above is exactly one of the intended usages of the delivery-tag. It is explicitly intended to be open ended so that it can be generated from application domain concepts (order number, filename, uuid, whatever), and the interaction involving settling the transfer state is intended to permit exactly the pattern you describe. One thing that might be confusing here is that all the examples tend to focus on a single isolated transfer which does not convey the potentially asynchronous nature of the conversation. > On recovery after system failure, the sender just blindly sends the > messages again, on receipt at the server any messages seen before will > just be rejected. No need for reattaching, sending maps of unsettled > transfers or other complex stuff like that. > > By removing all this delivery tag book-keeping and session re-attachment > stuff, which seems unnecessary to me, would result in a dramatic > simplification. What you're describing here would be a valid implementation, however exchanging the unsettled state permits you to avoid unnecessary retransmits, and resume large messages part way through. These are behaviors that the spec wants to admit. > Regarding verbosity of the wire format for message transfer; if you're > just passing a 12 byte message (e.g. stock price - 4 byte identifier + 8 > byte price) then the overall encoded size is much higher than 12 bytes. > > This will kill performance for small messages, making any AMQP compliant > implementation unable to compete in the world of lightweight > publish/subscribe messaging with other, non AMQP implementations which > don't have to conform to the AMQP wire format and can produce much more > lightweight encodings. The key to perf with lightweight pub/sub is to > make the encoded message size as small as possible and cram as many > messages as you can into single socket writes. > > Now, lightweight pub/sub may not be the target domain for AMQP, in which > case it does not need to worry about it, however if a particular > messaging system supports multiple protocols including AMQP, it will not > do much for the adoption of AMQP if the best performance is not > achievable using the AMQP protocol - users will fall back to using the > proprietary protocol offered by the vendor. The type system explicitly distinguishes between "types" and "encodings" in order to be able to allow more efficient encodings of a given type in the future. Right now we've chosen a very flexible encoding because it is invaluable to be able to make certain changes (e.g. adding an optional field) and still preserve wire compatibility with any existing implementations. Once the protocol is implemented and we have the benefit of profiling, deployment experience, etc, we can, if we choose to, make allowances for very small messages in a number of ways, e.g. we could reduce overhead by defining a special frame body or even a special frame type for small transfers. > A short comment on transactions. I have to be honest here, I spent about > 30 mins reading the chapter on transactions several times. I have to say > at the end of it I am not much further understanding it. :( > > However maybe that is moot - a part of me is thinking that transactions > don't really belong in the core spec. Perhaps the core spec should be > concerned with allowing the reliable movement of messages between nodes. > With that in place, transactions could be layered on top in another spec (?) The transaction portion is actually already a separate specification (you'll notice that despite being in a single PDF, Types, Transport, Messaging, Transactions, and Security are all labeled "Books" not "Sections" or "Chapters"). --Rafael From rob.j.godfrey at gmail.com Mon May 10 16:30:59 2010 From: rob.j.godfrey at gmail.com (Robert Godfrey) Date: Mon, 10 May 2010 17:30:59 +0200 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE81902.4090502@cloudeventprocessing.com> References: <4BE80C00.3080204@jboss.com> <4BE81902.4090502@cloudeventprocessing.com> Message-ID: Hi Colin, On 10 May 2010 16:32, Colin Clark wrote: > In regards to the once-and-only-once discussion below: > > In many financial formats, like FIX and others, we utilize message ID's that > help with this behavior a lot.? It also prevents from messages being > delivered out of sequence.? For example. > > Client logs in - server and client at message ID of 0, > every message that the server sends has an incremented ID, > if the client receives an unexpected ID, it can either request a retransmit > from the last known or kill the session, > when a client logs back in, the client logs in with the expected ID, server > & client negotiate and session resumes. > (there are id's for both the client & server messages, both incremented for > each message and the above behavior applies on both sides of the connection) > > FIX employs an optimistic delivery protocol, i.e., assume that it was > received.? There is no session level ack.? Only an ack at the application > level; and that ack is not mandatory.? Use of the message ID provides the > once & only once and in order semantics required for trading; a behavior > that is obviously very useful elsewhere as well. > > Using sequence #'s also allows for advanced concepts such as flow control - > I haven't read enough of the spec yet to see if that's a feature yet or not. We use sequence numbers for flow control, this is separate from the tag used for de-duplication. > I do agree, if a message is sent, then an ack is waited for, sending an ack > of ack seems a little over kill to me.? Perhaps it's time for me to read the > whole spec again. > As I (and Rafi who seems to have simultaneously said much the same thing :-) ) have said, this is not required behaviour. You can *choose* to behave in this way, but for the use case above I very much doubt that is how you would want to behave. The receiver can periodically notify the sender as to the high-watermark of messages that it considers settled - this will give the same behaviour as above. Hope this helps, Rob From colin at cloudeventprocessing.com Mon May 10 16:37:29 2010 From: colin at cloudeventprocessing.com (Colin Clark) Date: Mon, 10 May 2010 10:37:29 -0500 Subject: [rabbitmq-discuss] request for help! In-Reply-To: References: <4BE80C00.3080204@jboss.com> <4BE81902.4090502@cloudeventprocessing.com> Message-ID: <4BE82839.2020702@cloudeventprocessing.com> It does, thank you - and it points to the need for me to re-read the spec again! :) On 5/10/2010 10:30 AM, Robert Godfrey wrote: > Hi Colin, > > On 10 May 2010 16:32, Colin Clark wrote: > >> In regards to the once-and-only-once discussion below: >> >> In many financial formats, like FIX and others, we utilize message ID's that >> help with this behavior a lot. It also prevents from messages being >> delivered out of sequence. For example. >> >> Client logs in - server and client at message ID of 0, >> every message that the server sends has an incremented ID, >> if the client receives an unexpected ID, it can either request a retransmit >> from the last known or kill the session, >> when a client logs back in, the client logs in with the expected ID, server >> & client negotiate and session resumes. >> (there are id's for both the client& server messages, both incremented for >> each message and the above behavior applies on both sides of the connection) >> >> FIX employs an optimistic delivery protocol, i.e., assume that it was >> received. There is no session level ack. Only an ack at the application >> level; and that ack is not mandatory. Use of the message ID provides the >> once& only once and in order semantics required for trading; a behavior >> that is obviously very useful elsewhere as well. >> >> Using sequence #'s also allows for advanced concepts such as flow control - >> I haven't read enough of the spec yet to see if that's a feature yet or not. >> > We use sequence numbers for flow control, this is separate from the > tag used for de-duplication. > > >> I do agree, if a message is sent, then an ack is waited for, sending an ack >> of ack seems a little over kill to me. Perhaps it's time for me to read the >> whole spec again. >> >> > As I (and Rafi who seems to have simultaneously said much the same > thing :-) ) have said, this is not required behaviour. You can > *choose* to behave in this way, but for the use case above I very much > doubt that is how you would want to behave. The receiver can > periodically notify the sender as to the high-watermark of messages > that it considers settled - this will give the same behaviour as > above. > > Hope this helps, > Rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100510/759fdec1/attachment.htm From rafaels at redhat.com Mon May 10 17:10:12 2010 From: rafaels at redhat.com (Rafael Schloming) Date: Mon, 10 May 2010 12:10:12 -0400 Subject: [rabbitmq-discuss] request for help! In-Reply-To: References: <4BE80C00.3080204@jboss.com> Message-ID: <4BE82FE4.6050005@redhat.com> Robert Godfrey wrote: > the point is really that > you can *choose* to implement this all using circular buffers (you > don't *need* to implement a map)... but we aren't forcing clients to > persistently remember the sequence in which they sent/received > messages. Perhaps we need to call this point out a bit more in the specification text, i.e. make it clear that the unsettled state retained by the link endpoints is a logical mapping rather than an actual hash table. --Rafael From tim.fox at jboss.com Mon May 10 17:11:09 2010 From: tim.fox at jboss.com (Tim Fox) Date: Mon, 10 May 2010 17:11:09 +0100 Subject: [rabbitmq-discuss] request for help! In-Reply-To: References: <4BE80C00.3080204@jboss.com> Message-ID: <4BE8301D.9000009@jboss.com> On 10/05/10 16:18, Robert Godfrey wrote: > Hi Tim, > > thanks for the feedback > > On 10 May 2010 15:37, Tim Fox wrote: > >> I've spent this morning going through the 1.0. PR3 spec, firstly, it's >> considerably simpler than 0.10, which is great news :) >> >> Here's my 2p: >> >> One thing I find quite strange is that the core spec doesn't actually >> seem to mandate any queueing semantics anywhere. I've nothing >> particularly against that - in fact, the idea that a node can do >> different types of ordering is actually quite nice, however it's not a >> queueing protocol. Shouldn't AMQP therefore be renamed to AMTP (Advanced >> Message Transfer Protocol) ? ;) >> > :-) It is deliberate that we've chosen to break the specification up > into distinct layers. The parts covered in PR3 do not form the > "whole" of AMQP but what we have been so far referring to as the > "core". It is in the plan that on top of this will come definitions > of specific node types (such as Queues) and the behaviours that one > can expect from them. An "AMQP Broker" will be defined in terms the > node types and behaviours required to be supported. That is not to > say that you can't have a messaging broker which speaks AMQP which is > not an "AMQP Broker". One of the design goals was to enable vendors > of existing messaging products to layer AMQP as a protocol on top of > their existing product - something that proved very difficult with the > 0-x protocols due to the very specific model it imposed on broker > behaviour right down to the transport layer. > > >> On a more serious note, my main concerns are mainly around complexity, >> and verbosity of the wire format. The latter I suppose is not completely >> independent from the former. >> >> Regarding complexity. IMO a large part of the complexity in the spec. >> seems to come from the way it tries to provide a once and only once >> delivery guarantee. AIUI the way the spec. implements this guarantee is >> something like the following when transferring a message from A to B: >> >> a) message to be sent from A-->B >> b) ack sent back from B-->A >> c) "ack of ack" sent from A-->B - now the delivery tag can be removed >> from the senders cache >> >> > Just to be clear, while this behaviour is permitted under the spec, it > is not mandated that every message exchange follows this pattern. > Firstly the protocol will support different reliability guarantees > agreed at the link level (at most once, at least once, exactly once, > etc) which will allow simpler patterns where the extra guarantees are > not required. I believe you can use a simpler pattern, but still retain the once and only once guarantee. This is how we do it in HornetQ to give us once and only once when bridging messages from one server A to another B. The sender doesn't maintain any delivery map at all. Each message has a de-duplication-id which can either be set by the client when the message was originally sent, or can be set by the server and derived from the message and node id of the sender. Since the id can be derived from the message, or is already persisted as part of the message there's no need to persist it separately or maintain a map on the client side. The receiving node B simply maintains a circular cache of received ids (which is optionally persisted). If B sees the same de-duplication-id more than once it simply ignores the message. After failure, the sender can just carry on sending any unacked messages as normal and the server will reject any dups. B sends acks back to A asynchronously in a different stream (so everything is pipelined for performance). When A receives the ack, then the message can be removed from storage. This gives us once and only once without having the c) interaction above. I believe it this gives us one less transfer on the wire, but more importantly one less write to storage - on the sender side. I can see that your scheme accomplishes the same goal, but it seems somewhat more complex, unless I am missing something (quite possible ;) ) From rnickel at scea.com Mon May 10 17:11:15 2010 From: rnickel at scea.com (Robert Nickel) Date: Mon, 10 May 2010 09:11:15 -0700 Subject: [rabbitmq-discuss] Really bizarre startup issue... In-Reply-To: <4BE33918.8030209@rabbitmq.com> References: <20100430230143.GR7977@coinelement.989studios.com> <4BE24C18.80008@rabbitmq.com> <20100506170552.GE17952@coinelement.989studios.com> <4BE30BE8.3070105@rabbitmq.com> <20100506195038.GF26133@coinelement.989studios.com> <4BE3281B.7010305@rabbitmq.com> <20100506204136.GI26133@coinelement.989studios.com> <20100506204416.GJ26133@coinelement.989studios.com> <4BE33918.8030209@rabbitmq.com> Message-ID: <20100510161115.GC30392@coinelement.989studios.com> On 2010.05.06 22:48:08 +0100, Matthias Radestock wrote: > Robert, > > Robert Nickel wrote: >> rabbitmq-server is not getting invoked according to the output in >> /var/log/rabbitmq/startup*. >> >> I added an echo and set -x to the script and got nothing. > > The logging could possibly go astray; I suggest you add something like a > 'touch /tmp/foo' right at the beginning to serve as a "got here" marker. > > The {node_start_failed,normal} error you are seeing in the logs > indicates that the rabbit_multi erlang code is attempting to invoke the > rabbitmq-server script but that either somehow fails or at least doesn't > result in a running rabbit server. It's very unusual for that to happen > and not result in some errors in the startup logs. I cannot think of an > easy way of tracking down the cause w/o hacking on the rabbitmq_multi > erlang code. Closing the loop on this issue. I have, unfortunately, run out of time that I can spend chasing this issue. The startup using rabbitmq-multi is still unresolved. I have resorted to altering the init script to call rabbitmq-server and use rabbitmqctl to stop and gather status information. If you see this come up again, please let me know. Thanks for all your help. --Robert From rafaels at redhat.com Mon May 10 18:25:08 2010 From: rafaels at redhat.com (Rafael Schloming) Date: Mon, 10 May 2010 13:25:08 -0400 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE8301D.9000009@jboss.com> References: <4BE80C00.3080204@jboss.com> <4BE8301D.9000009@jboss.com> Message-ID: <4BE84174.1000609@redhat.com> Tim Fox wrote: > On 10/05/10 16:18, Robert Godfrey wrote: >> Just to be clear, while this behaviour is permitted under the spec, it >> is not mandated that every message exchange follows this pattern. >> Firstly the protocol will support different reliability guarantees >> agreed at the link level (at most once, at least once, exactly once, >> etc) which will allow simpler patterns where the extra guarantees are >> not required. > I believe you can use a simpler pattern, but still retain the once and > only once guarantee. > > This is how we do it in HornetQ to give us once and only once when > bridging messages from one server A to another B. > > The sender doesn't maintain any delivery map at all. Each message has a > de-duplication-id which can either be set by the client when the message > was originally sent, or can be set by the server and derived from the > message and node id of the sender. > > Since the id can be derived from the message, or is already persisted as > part of the message there's no need to persist it separately or maintain > a map on the client side. The specification doesn't require you to persist the delivery-tag separately. It's a perfectly valid (and expected) choice to populate it from the message itself as you describe. When you do this the set of unacked messages has all the necessary information to construct the protocol primitives defined in the spec without maintaining a separate map. > The receiving node B simply maintains a circular cache of received ids > (which is optionally persisted). If B sees the same de-duplication-id > more than once it simply ignores the message. As I believe Rob already pointed out, this is all the information necessary to fulfill the protocol contracts from the Receiver's side. > After failure, the sender can just carry on sending any unacked messages > as normal and the server will reject any dups. > > B sends acks back to A asynchronously in a different stream (so > everything is pipelined for performance). When A receives the ack, then > the message can be removed from storage. > > This gives us once and only once without having the c) interaction above. How does B know when A has received the ack? If this fact is communicated on the wire, then it is equivalent to the c) interaction. If this fact isn't communicated on the wire, then B is making an assumption when it purges entries from its cache, and is exposing itself to duplicate messages, i.e. this is only providing a probabilistic exactly-once guarantee. > I believe it this gives us one less transfer on the wire, but more > importantly one less write to storage - on the sender side. The c) interaction has almost no overhead since it is trivially inferred from the window of unsettled deliveries which is piggybacked on message transfers, however both the Sender and Receiver can short circuit the full transfer interaction by indicating that a delivery is settled. This can be done on the initial transfer if fire and forget/at-most-once messaging is desired, or on the initial ack if at-least-once (or probabilistic exactly-once) messaging is desired. > I can see that your scheme accomplishes the same goal, but it seems > somewhat more complex, unless I am missing something (quite possible ;) ) I think perhaps the key point is that the spec is defining the protocol primitives and minimal semantics required for interop, but not actually attempting to prescribe or proscribe a particular implementation strategy. So the intention is very much to permit the sort of things you're describing, but not to constrain implementations to choose only those strategies. As I mentioned to Rob in another post, we could probably be a bit clearer on this in our descriptions and examples. --Rafael From tim.fox at jboss.com Mon May 10 18:43:27 2010 From: tim.fox at jboss.com (Tim Fox) Date: Mon, 10 May 2010 18:43:27 +0100 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE84174.1000609@redhat.com> References: <4BE80C00.3080204@jboss.com> <4BE8301D.9000009@jboss.com> <4BE84174.1000609@redhat.com> Message-ID: <4BE845BF.4060709@jboss.com> On 10/05/10 18:25, Rafael Schloming wrote: > Tim Fox wrote: >> On 10/05/10 16:18, Robert Godfrey wrote: >>> Just to be clear, while this behaviour is permitted under the spec, it >>> is not mandated that every message exchange follows this pattern. >>> Firstly the protocol will support different reliability guarantees >>> agreed at the link level (at most once, at least once, exactly once, >>> etc) which will allow simpler patterns where the extra guarantees are >>> not required. >> I believe you can use a simpler pattern, but still retain the once >> and only once guarantee. >> >> This is how we do it in HornetQ to give us once and only once when >> bridging messages from one server A to another B. >> >> The sender doesn't maintain any delivery map at all. Each message has >> a de-duplication-id which can either be set by the client when the >> message was originally sent, or can be set by the server and derived >> from the message and node id of the sender. >> >> Since the id can be derived from the message, or is already persisted >> as part of the message there's no need to persist it separately or >> maintain a map on the client side. > > The specification doesn't require you to persist the delivery-tag > separately. It's a perfectly valid (and expected) choice to populate > it from the message itself as you describe. When you do this the set > of unacked messages has all the necessary information to construct the > protocol primitives defined in the spec without maintaining a separate > map. > >> The receiving node B simply maintains a circular cache of received >> ids (which is optionally persisted). If B sees the same >> de-duplication-id more than once it simply ignores the message. > > As I believe Rob already pointed out, this is all the information > necessary to fulfill the protocol contracts from the Receiver's side. > >> After failure, the sender can just carry on sending any unacked >> messages as normal and the server will reject any dups. >> >> B sends acks back to A asynchronously in a different stream (so >> everything is pipelined for performance). When A receives the ack, >> then the message can be removed from storage. >> >> This gives us once and only once without having the c) interaction >> above. > > How does B know when A has received the ack? > > If this fact is communicated on the wire, then it is equivalent to the > c) interaction. If this fact isn't communicated on the wire, then B is > making an assumption when it purges entries from its cache, and is > exposing itself to duplicate messages, i.e. this is only providing a > probabilistic exactly-once guarantee. You can tune the duplicate id cache size so that it more than covers the amount of unacked messages you might reasonably expect at any one time. This figure should be close to the flow control window size. So take the figure and multiply by two (or 5 or 10). This should reduce the probability of dups to effectively zero. > >> I believe it this gives us one less transfer on the wire, but more >> importantly one less write to storage - on the sender side. > > The c) interaction has almost no overhead since it is trivially > inferred from the window of unsettled deliveries which is piggybacked > on message transfers, however both the Sender and Receiver can short > circuit the full transfer interaction by indicating that a delivery is > settled. > > This can be done on the initial transfer if fire and > forget/at-most-once messaging is desired, or on the initial ack if > at-least-once (or probabilistic exactly-once) messaging is desired. > >> I can see that your scheme accomplishes the same goal, but it seems >> somewhat more complex, unless I am missing something (quite possible >> ;) ) > > I think perhaps the key point is that the spec is defining the > protocol primitives and minimal semantics required for interop, but > not actually attempting to prescribe or proscribe a particular > implementation strategy. So the intention is very much to permit the > sort of things you're describing, but not to constrain implementations > to choose only those strategies. > > As I mentioned to Rob in another post, we could probably be a bit > clearer on this in our descriptions and examples. > > --Rafael -- Sent from my BBC Micro Model B Tim Fox JBoss HornetQ - putting the buzz in messaging http://hornetq.org http://hornetq.blogspot.com/ http://twitter.com/hornetq irc://irc.freenode.net:6667#hornetq fox at redhat.com From alexyz78 at gmail.com Mon May 10 20:17:32 2010 From: alexyz78 at gmail.com (alexyz78) Date: Mon, 10 May 2010 21:17:32 +0200 Subject: [rabbitmq-discuss] Message delivered even if routing key doen't match Message-ID: I'm starting to write a prototype with RabbitMQ but I've some problem to understand the concept of "routing key", below there's an excerpt of the producer: String exchangeName = "myExchange"; channel.exchangeDeclare(exchangeName, "direct"); String queueName = "myQueue"; channel.queueDeclare(queueName); String routingKey = "testRoute"; channel.queueBind(queueName, exchangeName, routingKey); the consumer's code is the the same except it defines a routingKey = "xyz" Why does the consumer gets the messages even if the routing key that it defines is different from the one defined by the producer? Is there a document that describes the routing algorithm based on the routing key? Thanks and regards, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100510/0b8c12fd/attachment.htm From jasonjwwilliams at gmail.com Mon May 10 23:43:15 2010 From: jasonjwwilliams at gmail.com (Jason J. W. Williams) Date: Mon, 10 May 2010 16:43:15 -0600 Subject: [rabbitmq-discuss] Fwd: active/active In-Reply-To: <3b949f091001181707k15feadd5je82aae41dc60d0be@mail.gmail.com> References: <167204d21001171240j780c5f98oedace8539a884283@mail.gmail.com> <3b949f091001181707k15feadd5je82aae41dc60d0be@mail.gmail.com> Message-ID: It was suggested to me I relay a convo I had with Alexis earlier this year making the case for better active/active fail-over in RabbitMQ. Particularly, when working with durable messaging. ---------- Forwarded message ---------- From: Jason J. W. Williams Date: Mon, Jan 18, 2010 at 7:07 PM Subject: Re: active/active To: Alexis Richardson Hey Alexis, Currently, we have a single RMQ 1.5 pair that are setup active/passive. That is to say, our apps publish to node A and if it is unavailable publish to node B. Nodes A and B are standalone in that they are not in a cluster together. This is because the messages being published are durable, and in the event node A crashes any pending durable messages would not be auto-resubmitted if node A were clustered with node B (node B's queue essentially hides the pendings that were in the queue on node A before the crash). This set up works OK for us, as the load is fairly light and durability is more important for these tasks than availability. That being said we are designing a rework of our statistics logging infrastructure around Rabbit. Our stats is very high volume and availability is more important than durability (in fact none of the messages will be durable). So our intention is to create a new Rabbit cluster with three nodes and a load-balanced IP in front (since auto-redirect based on load is no longer supported....nasty memo to follow... ;) ). Our desire due to the fact that we're moving from a colo'd environment to a cloud environment, is to collapse both Rabbit "clusters" into a single cluster to maximize efficiency. It would also allow our existing app to benefit from the performance of a load-sharing environment. For that to happen however, Rabbit would have to do one of two things when clustered regarding durable messages: 1.) When a crashed node is restarted, replay the pending/durable messages into the queue on the node now responsible for the queue after the crash. 2.) Replicate all durable queues to more than one node, so that durable queue contents continue after a node crash. Frankly, option 1 is just fine with us and would solve our issue. Does this help? Thank you for being concerned. -J From mikeb at lshift.net Tue May 11 00:08:04 2010 From: mikeb at lshift.net (Michael Bridgen) Date: Tue, 11 May 2010 00:08:04 +0100 Subject: [rabbitmq-discuss] Message delivered even if routing key doen't match In-Reply-To: References: Message-ID: <4BE891D4.2000903@lshift.net> Alex, > I'm starting to write a prototype with RabbitMQ but I've some problem to > understand the concept of "routing key", below there's an excerpt of the > producer: > > String exchangeName = "myExchange"; > channel.exchangeDeclare(exchangeName, "direct"); > String queueName = "myQueue"; > channel.queueDeclare(queueName); > String routingKey = "testRoute"; > channel.queueBind(queueName, exchangeName, routingKey); > > the consumer's code is the the same except it defines a routingKey = "xyz" (See the answer on routing algorithms, below, first.) All of exchange.declare, queue.declare, and queue.bind are idempotent given the same arguments; in this case though you're giving two different arguments to queue.bind, so you end up with two bindings from a single exchange to a single queue. Hence messages to the exchange with a routing key of "xyz" OR a routing key of "testRoute" will be delivered to the queue. > Why does the consumer gets the messages even if the routing key that it > defines is different from the one defined by the producer? > > Is there a document that describes the routing algorithm based on the > routing key? In the case above, what you're supplying is not a routing key but a /binding key/. Individual messages have routing keys; routing involves comparing the message's /routing key/ with each binding's /binding key/ to see which queues (via the bindings) should be delivered the message. For a direct exchange, the algorithm is (informally) "deliver via all bindings with a binding key equal to the message's routing key". A fanout exchange ignores binding keys and routing keys, and delivers via all bindings. A topic exchange does a kind of wildcard matching on the routing key, with binding keys giving patterns. Wikipedia is not bad on this: http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol#Exchange_types_and_the_effect_of_bindings Michael. From shane at digitalsanctum.com Tue May 11 04:07:42 2010 From: shane at digitalsanctum.com (Shane) Date: Mon, 10 May 2010 20:07:42 -0700 (PDT) Subject: [rabbitmq-discuss] getting started Message-ID: <5a5b6326-7eb8-4eb8-be39-c921f1f59a14@k29g2000yqh.googlegroups.com> I've looked over docs but nothing seems to jump out. I've put together a simple single node broker with one publisher and one client using the amqp Ruby gem on my local LAN. I'm now attempting to move the broker to a public server and connect to it from my existing LAN client. I have the broker up and running but when I attempt to connect to it using a local client (my workstation), I get the following message: /Library/Ruby/Gems/1.8/gems/amqp-0.6.7/lib/amqp/client.rb:65:in `initialize': Could not connect to server ds1:5672 (AMQP::Error) from /Library/Ruby/Gems/1.8/gems/amqp-0.6.7/lib/amqp/client.rb:97:in `call' from /Library/Ruby/Gems/1.8/gems/amqp-0.6.7/lib/amqp/client.rb:97:in `unbind' I've updated my /etc/hosts file so ds1 points to the IP address of the public broker. Although I'm using the amqp Ruby gem, this feels more like a rabbitmq/network configuration issue. Can someone let me know what I might be doing wrong? Thanks, Shane From RadhakrishnanD at ivycomptech.com Tue May 11 07:35:55 2010 From: RadhakrishnanD at ivycomptech.com (Radha Krishnan D) Date: Tue, 11 May 2010 12:05:55 +0530 Subject: [rabbitmq-discuss] RabbitMQ config file. Message-ID: <49A7BA114AAC6A48B9C44CB06B7B987E0A211478@HYDSVWIN004X.ivycomptech.partygaming.local> Hi, We are evaluating rabbitMQ's performance for our use cases. We are using rabbitmq-server-1.7.2 ( downloaded under the heading generic Linux ). Since our linux machine RAM is 8 GB and it is a 32 bit machine. RabbitMQ takes 1638 MB and it prints it in the logs. How ever when I want to increase the size by using {rabbit, [{vm_memory_high_watermark, 2.0}]} the rabbitMQ server is not recognizing this configuration change at all. I did a change in the rabbitmq-server file pointing CONFIG_FILE=/home/ppoker/MessagingPOC/RabbitMQ/rabbitmq rabbitmq.config is my file name. Earlier, in the default run. You have mentioned that the default config file for generic unix will be in /etc/rabbitmq/rabbitmq.config. I did not get this file there. Where am I going wrong ? Please suggest me a solution and a sample copy of the rabbitmq.config file. Also please clear us about the difference between rabbitmq.conf file and rabbitmq.config file. Thanks and Regards, D.Radhakrishnan Trainee Engineer-Architecture IVY Comptech Private Limited Cyber Spazio,Road No 2, Banjara Hills, Hyderabad-500034, Andhra Pradesh. Phone + 91 (40) 66721000 - 4638 Mobile + 91 (0) 9030842104 This email and any attachments are confidential, legally privileged and protected by copyright. If you are not the intended recipient, dissemination or copying this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorized. Any actions taken on the basis of this email are at recipient's own risk. This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy Comptech Private Limited is a limited liability company. This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract on behalf of Ivy Comptech Private Limited unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. Registered office: Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, Hyderabad 500 033, Andhra Pradesh, India. Registered number: 37994. Registered in India. A list of members' names is available for inspection at the registered office. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100511/e379cb55/attachment.htm From mikeb at lshift.net Tue May 11 10:01:56 2010 From: mikeb at lshift.net (Michael Bridgen) Date: Tue, 11 May 2010 10:01:56 +0100 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE2EC65.9010108@redhat.com> References: <4BE2970B.9070208@250bpm.com> <4BE2A943.6070305@250bpm.com> <4BE2C191.5030402@250bpm.com> <4BE2CC29.2050101@lshift.net> <4BE2E931.6050303@redhat.com> <4BE2EC65.9010108@redhat.com> Message-ID: <4BE91D04.6040800@lshift.net> > On 05/06/2010 05:12 PM, Alexis Richardson wrote: >> On Thu, May 6, 2010 at 5:07 PM, Gordon Sim wrote: >>> I would expect an implementation to define policy around where links >>> with these two types of distribution mode can be used. E.g. a pub-sub >>> topic might only allow non-destructive links were valid, a plain queue >>> might only allow destructive links and a browsable queue might allow >>> both (with what I think are then obvious if non-deterministic >>> implications for concurrent links with different modes). >>> >> Is there any use case where 'destructive' or 'non destructive' >> behaviour should be a property of the LINK rather than the NODE? > > Browsing a queue (you would want to allow consumers and browsers, though > most likely at different times). Actually in some sense it should be in both -- the source of disagreement, as I see it, is that "distribution mode" is used both for distinguishing between "all-matching" (e.g., exchanges) and "one-matching" (e.g., queues), and for distinguishing between enumerating through messages and actively acquiring them. The first distinction really belongs in the node, and the second, arguably, in the link (or possibly in flow controls, but I imagine Rob and Rafi will have already chased that idea down). Michael. From tonyg at lshift.net Tue May 11 10:16:24 2010 From: tonyg at lshift.net (Tony Garnock-Jones) Date: Tue, 11 May 2010 21:16:24 +1200 Subject: [rabbitmq-discuss] Firewall Issues In-Reply-To: <4BE819A9.4050707@loafman.com> References: <4BE812AE.2020403@loafman.com> <4BE81674.102@loafman.com> <4BE8183A.1030504@loafman.com> <4BE819A9.4050707@loafman.com> Message-ID: <4BE92068.9040706@lshift.net> Hi Kenneth, If you're just speaking AMQP between (P1 and MQ) and (P2 and MQ), port 5672 should be all you need open. I'm curious though, which *direction* are connections running between the hosts? Does P1 only ever connect to MQ, or does MQ sometimes connect to P1? How are you relaying messages -- using shovel, or something else? Tony Kenneth Loafman wrote: > Will test it tonight and let you know. > > ...Thanks, > ...Ken > > Matt Calder wrote: >> By default erlang uses 4369. >> >> Matt >> >> On Mon, May 10, 2010 at 10:29 AM, Kenneth Loafman wrote: >>> What erlang ports? Just 5672:tcp. >>> >>> ...Ken >>> >>> Matt Calder wrote: >>>> Ken, >>>> >>>> Are the erlang ports open? >>>> >>>> Matt >>>> >>>> On Mon, May 10, 2010 at 10:21 AM, Kenneth Loafman wrote: >>>>> Nope, just a single node service at this point. P1 and P2 do not even >>>>> have RabbitMQ installed, they are just MQ clients. I should have noted >>>>> that in my original message. >>>>> >>>>> The process has worked well for months prior to adding the firewall. >>>>> >>>>> ...Ken >>>>> >>>>> Matt Calder wrote: >>>>>> Ken, >>>>>> >>>>>> It looks like you are setting up a cluster, if so, are they sharing >>>>>> the same cookie? >>>>>> >>>>>> I just went through starting a cluster here is my step-by-step: >>>>>> >>>>>> 1) Start a cluster of rabbits. >>>>>> Assume cluster is on: hostA, hostB (for example) >>>>>> >>>>>> # The rabbitmq processes must be running with the same cookie >>>>>> hostA> sudo rabbitmqctl stop >>>>>> hostA> sudo /etc/init.d/rabbitmq-server stop >>>>>> hostA> sudo rm ~rabbitmq/.erlang.cookie >>>>>> hostA> sudo echo ABC123 | sudo tee ~rabbitmq/.erlang.cookie >>>>>> hostA> sudo chmod 400 ~rabbitmq/.erlang.cookie >>>>>> hostA> sudo chown rabbitmq ~rabbitmq/.erlang.cookie >>>>>> hostA> sudo chgrp rabbitmq ~rabbitmq/.erlang.cookie >>>>>> hostA> sudo /etc/init.d/rabbitmq-server start >>>>>> >>>>>> repeat for hostB >>>>>> >>>>>> # On join hostB to hostA >>>>>> hostB> sudo rabbitmqctl stop_app >>>>>> hostB> sudo rabbitmqctl reset >>>>>> hostB> sudo rabbitmqctl cluster rabbit at hostA >>>>>> >>>>>> Hope that helps. >>>>>> >>>>>> Matt >>>>>> >>>>>> >>>>>> On Mon, May 10, 2010 at 10:05 AM, Kenneth Loafman wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I've got RabbitMQ up on three machines and wanted to add a firewall. >>>>>>> The configuration is simple, MQ serves input to P1 and P2 which do all >>>>>>> the processing. >>>>>>> >>>>>>> MQ >>>>>>> / \ >>>>>>> P1 P2 >>>>>>> >>>>>>> I opened the port 5672:tcp on all machines and between two machines, MQ >>>>>>> and P1, that seems to work. When I added P2, it immediately got a >>>>>>> 'connection refused' message. All machines are running Ubuntu 9.10 and >>>>>>> rabbitmq-server 1.7.2. P1 and P2 are identical as far as I can tell. >>>>>>> >>>>>>> Any help would be appreciated. >>>>>>> >>>>>>> Thanks, >>>>>>> ...Ken >>>>>>> >>>>>>> _______________________________________________ >>>>>>> rabbitmq-discuss mailing list >>>>>>> rabbitmq-discuss at lists.rabbitmq.com >>>>>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>>>>>> >>>>> _______________________________________________ >>>>> rabbitmq-discuss mailing list >>>>> rabbitmq-discuss at lists.rabbitmq.com >>>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>>>> >>> _______________________________________________ >>> rabbitmq-discuss mailing list >>> rabbitmq-discuss at lists.rabbitmq.com >>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>> > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From tonyg at lshift.net Tue May 11 10:22:39 2010 From: tonyg at lshift.net (Tony Garnock-Jones) Date: Tue, 11 May 2010 21:22:39 +1200 Subject: [rabbitmq-discuss] Message delivered even if routing key doen't match In-Reply-To: References: Message-ID: <4BE921DF.1030304@lshift.net> Hi Alex, alexyz78 wrote: > I'm starting to write a prototype with RabbitMQ but I've some problem to > understand the concept of "routing key", below there's an excerpt of the > producer: > > channel.queueDeclare(queueName); > channel.queueBind(queueName, exchangeName, routingKey); It seems a bit odd that a producer is declaring a queue at all. Information flow in AMQP is asymmetric. Producers send messages to exchanges, which route on to queues, which deliver to consumers. A producer doesn't need to declare or manipulate queues: if one piece of code both publishes to an exchange and reads off a queue, it's performing in both the producer and the consumer roles. Not sure if this sheds any light on your issue of course :-) Tony From david at rabbitmq.com Tue May 11 10:24:33 2010 From: david at rabbitmq.com (David Wragg) Date: Tue, 11 May 2010 10:24:33 +0100 Subject: [rabbitmq-discuss] getting started In-Reply-To: <5a5b6326-7eb8-4eb8-be39-c921f1f59a14@k29g2000yqh.googlegroups.com> (shane@digitalsanctum.com's message of "Mon\, 10 May 2010 20\:07\:42 -0700 \(PDT\)") References: <5a5b6326-7eb8-4eb8-be39-c921f1f59a14@k29g2000yqh.googlegroups.com> Message-ID: Hi Shane, Shane writes: > I've looked over docs but nothing seems to jump out. I've put together > a simple single node broker with one publisher and one client using > the amqp Ruby gem on my local LAN. I'm now attempting to move the > broker to a public server and connect to it from my existing LAN > client. I have the broker up and running but when I attempt to connect > to it using a local client (my workstation), I get the following > message: > > /Library/Ruby/Gems/1.8/gems/amqp-0.6.7/lib/amqp/client.rb:65:in > `initialize': Could not connect to server ds1:5672 (AMQP::Error) > from /Library/Ruby/Gems/1.8/gems/amqp-0.6.7/lib/amqp/client.rb:97:in > `call' > from /Library/Ruby/Gems/1.8/gems/amqp-0.6.7/lib/amqp/client.rb:97:in > `unbind' Is it possible that a firewall or similar is blocking connections to your public server? Make sure TCP port 5672 (the AMQP port) is open to the outside world. Or are you on a very locked-down corporate network, where the policy might be to block connections to the outside world? Those kind of explanations seem most likely. David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware From tonyg at lshift.net Tue May 11 10:29:06 2010 From: tonyg at lshift.net (Tony Garnock-Jones) Date: Tue, 11 May 2010 21:29:06 +1200 Subject: [rabbitmq-discuss] getting started In-Reply-To: <5a5b6326-7eb8-4eb8-be39-c921f1f59a14@k29g2000yqh.googlegroups.com> References: <5a5b6326-7eb8-4eb8-be39-c921f1f59a14@k29g2000yqh.googlegroups.com> Message-ID: <4BE92362.3070507@lshift.net> Hi Shane, Shane wrote: > /Library/Ruby/Gems/1.8/gems/amqp-0.6.7/lib/amqp/client.rb:65:in > `initialize': Could not connect to server ds1:5672 (AMQP::Error) > from /Library/Ruby/Gems/1.8/gems/amqp-0.6.7/lib/amqp/client.rb:97:in > `call' > from /Library/Ruby/Gems/1.8/gems/amqp-0.6.7/lib/amqp/client.rb:97:in > `unbind' I suggest checking the RabbitMQ log files on your server machine to see if they give any clues. (Also, is what's 'unbind' doing in there? Looking at the rb amqp sources, it looks like that's a kind of disconnected-indicator? Perhaps you're falling foul of the AMQP spec rule that says servers have to be brutal and silent when rejecting a user's login for invalid credentials: are the username and password correct for the new cloudy server?) Tony From tonyg at lshift.net Tue May 11 10:42:01 2010 From: tonyg at lshift.net (Tony Garnock-Jones) Date: Tue, 11 May 2010 21:42:01 +1200 Subject: [rabbitmq-discuss] message/artifact chunking? In-Reply-To: References: <736738BF-7CDA-4AF0-A111-4ACFD898EF98@npcinternational.com> Message-ID: <4BE92669.3030306@lshift.net> Marek Majkowski wrote: > Putting a large file over RabbitMQ obviously will work, but I'd say > it's a bad idea. It's just easier to put the big things to some > temporary storage, and transfer only light requests over message bus. Furthermore, until the new persister lands, sending *really* big messages will cause problems with memory exhaustion. HTTP has all sorts of neat machinery for reliably transferring very large payloads a piece at a time, resuming aborted transfers, and so on. It even has a verb, DELETE, that can be pressed into service as a poor-man's acknowledge-and-release-message signal (which can work especially nicely on a server file system supporting hard links: give every potential receiver a distinct URL to retrieve and delete, and you get a kind of automatic garbage collection). I'd go with HTTP for transferring large chunks of data, and the messaging system for carrying the URLs. The problems with that system I can think of: 1. when is it safe to stop serving a piece of information from the HTTP server? and 2. how do you get the chunk up to the HTTP server in the first place? Not every client can run an httpd, and HTTP sadly (!) lacks resumable PUT/POST. To solve 1: If you know you have a single receiver, use DELETE. If you know you have exactly n receivers, hardlink the file on the server a few times for URL-uniqueness, and use DELETE. If you don't know the set of receivers, you're in trouble, and a timeout is likely your only sensible option. To solve 2: Either run an httpd on clients wishing to send Very Large Files (with associated firewall and configuration headaches), or use ReverseHTTP to be httpd-like without the firewall and configuration hassle, or put a CGI script or similar on the server that supports a protocol you can use to reliably upload files in a resumable fashion for later download by other clients. Or yeah, if it's not going to kill your server, just send the big files as large messages. Resumability of partial transfers goes out the window, of course. Tony From tonyg at lshift.net Tue May 11 10:48:47 2010 From: tonyg at lshift.net (Tony Garnock-Jones) Date: Tue, 11 May 2010 21:48:47 +1200 Subject: [rabbitmq-discuss] MTU In-Reply-To: References: <4BE43170.5060606@rabbitmq.com> <20100509193022.GA22170@wellquite.org> Message-ID: <4BE927FF.7010803@lshift.net> Gustavo Aquino wrote: > Just for example the Qpid package have a oversize > in message larger than RabbitMQ until you can send 32k messages per > second using 100mbps you can do only 16k messages per second with Qpid > with the same 100mbps. (Messages with 213bytes). This is curious. Are you talking about a Qpid version speaking some other AMQP protocol variant, such as 0-10, perhaps? Cheers, Tony From tonyg at lshift.net Tue May 11 10:54:29 2010 From: tonyg at lshift.net (Tony Garnock-Jones) Date: Tue, 11 May 2010 21:54:29 +1200 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: <4BE48F2A.5070603@dataraker.com> References: <4BE3013E.9080308@dataraker.com> <89839F8F-ABB1-4B04-AAAD-633E4CF60185@gmail.com> <20100507120026.GJ2739@mrnibble.lshift.net> <4BE476C3.8040707@dataraker.com> <4BE48685.8070307@rabbitmq.com> <4BE48F2A.5070603@dataraker.com> Message-ID: <4BE92955.3010202@lshift.net> Hi Wayne, Wayne Van Den Handel wrote: >> And, as Colin suggests, if you can post the code then we can try to >> reproduce the problem. > My code is reading data from a MySQL database as the source so this > "scenario" is not portable. Could you set it up to publish and consume dummy test data of appropriate sizes instead? Essentially simulate everything except the contents of the messages going through the system: the routing keys, the exchange names, the bindings, the queues, etc. Tony From aquino.gustavo at gmail.com Tue May 11 11:28:32 2010 From: aquino.gustavo at gmail.com (Gustavo Aquino) Date: Tue, 11 May 2010 07:28:32 -0300 Subject: [rabbitmq-discuss] MTU In-Reply-To: <4BE927FF.7010803@lshift.net> References: <4BE43170.5060606@rabbitmq.com> <20100509193022.GA22170@wellquite.org> <4BE927FF.7010803@lshift.net> Message-ID: Hi Tony, Yes, Im talking about Qpid 0-10. Regards. Gustavo On Tue, May 11, 2010 at 6:48 AM, Tony Garnock-Jones wrote: > Gustavo Aquino wrote: > > Just for example the Qpid package have a oversize > > in message larger than RabbitMQ until you can send 32k messages per > > second using 100mbps you can do only 16k messages per second with Qpid > > with the same 100mbps. (Messages with 213bytes). > > This is curious. Are you talking about a Qpid version speaking some other > AMQP > protocol variant, such as 0-10, perhaps? > > Cheers, > Tony > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100511/f824d7f1/attachment.htm From tim.fox at jboss.com Tue May 11 11:51:24 2010 From: tim.fox at jboss.com (Tim Fox) Date: Tue, 11 May 2010 11:51:24 +0100 Subject: [rabbitmq-discuss] request for help! In-Reply-To: <4BE84174.1000609@redhat.com> References: <4BE80C00.3080204@jboss.com> <4BE8301D.9000009@jboss.com> <4BE84174.1000609@redhat.com> Message-ID: <4BE936AC.8080505@jboss.com> On 10/05/10 18:25, Rafael Schloming wrote: > Tim Fox wrote: >> On 10/05/10 16:18, Robert Godfrey wrote: >>> Just to be clear, while this behaviour is permitted under the spec, it >>> is not mandated that every message exchange follows this pattern. >>> Firstly the protocol will support different reliability guarantees >>> agreed at the link level (at most once, at least once, exactly once, >>> etc) which will allow simpler patterns where the extra guarantees are >>> not required. >> I believe you can use a simpler pattern, but still retain the once >> and only once guarantee. >> >> This is how we do it in HornetQ to give us once and only once when >> bridging messages from one server A to another B. >> >> The sender doesn't maintain any delivery map at all. Each message has >> a de-duplication-id which can either be set by the client when the >> message was originally sent, or can be set by the server and derived >> from the message and node id of the sender. >> >> Since the id can be derived from the message, or is already persisted >> as part of the message there's no need to persist it separately or >> maintain a map on the client side. > > The specification doesn't require you to persist the delivery-tag > separately. It's a perfectly valid (and expected) choice to populate > it from the message itself as you describe. When you do this the set > of unacked messages has all the necessary information to construct the > protocol primitives defined in the spec without maintaining a separate > map. I'm a bit confused then. Section 6.10 of the spec states: "The application upon initiating a transfer will supply the sending link endpoint (Sender) with the message data and its associated delivery-tag. ** The Sender will create an entry in its unsettled map **" This implies to me that the implementor needs to maintain a settled map. But if I read your latest comment correctly, you're saying that actually I don't have to maintain a settled map, and the set of unacked messages will do fine. Reading this chapter, it seems that it's mandating a way to implement once and only once. If instead, this is just an illustration of a possible implementation, and in fact, implementors are free to implement once and only once in a simpler way and still remain AMQP compliant, I think it would be a good idea to make that clear in the spec. > >> The receiving node B simply maintains a circular cache of received >> ids (which is optionally persisted). If B sees the same >> de-duplication-id more than once it simply ignores the message. > > As I believe Rob already pointed out, this is all the information > necessary to fulfill the protocol contracts from the Receiver's side. > >> After failure, the sender can just carry on sending any unacked >> messages as normal and the server will reject any dups. >> >> B sends acks back to A asynchronously in a different stream (so >> everything is pipelined for performance). When A receives the ack, >> then the message can be removed from storage. >> >> This gives us once and only once without having the c) interaction >> above. > > How does B know when A has received the ack? > > If this fact is communicated on the wire, then it is equivalent to the > c) interaction. If this fact isn't communicated on the wire, then B is > making an assumption when it purges entries from its cache, and is > exposing itself to duplicate messages, i.e. this is only providing a > probabilistic exactly-once guarantee. > >> I believe it this gives us one less transfer on the wire, but more >> importantly one less write to storage - on the sender side. > > The c) interaction has almost no overhead since it is trivially > inferred from the window of unsettled deliveries which is piggybacked > on message transfers, however both the Sender and Receiver can short > circuit the full transfer interaction by indicating that a delivery is > settled. > > This can be done on the initial transfer if fire and > forget/at-most-once messaging is desired, or on the initial ack if > at-least-once (or probabilistic exactly-once) messaging is desired. > >> I can see that your scheme accomplishes the same goal, but it seems >> somewhat more complex, unless I am missing something (quite possible >> ;) ) > > I think perhaps the key point is that the spec is defining the > protocol primitives and minimal semantics required for interop, but > not actually attempting to prescribe or proscribe a particular > implementation strategy. So the intention is very much to permit the > sort of things you're describing, but not to constrain implementations > to choose only those strategies. > > As I mentioned to Rob in another post, we could probably be a bit > clearer on this in our descriptions and examples. > > --Rafael -- Sent from my BBC Micro Model B Tim Fox JBoss HornetQ - putting the buzz in messaging http://hornetq.org http://hornetq.blogspot.com/ http://twitter.com/hornetq irc://irc.freenode.net:6667#hornetq fox at redhat.com From kenneth at loafman.com Tue May 11 12:05:46 2010 From: kenneth at loafman.com (Kenneth Loafman) Date: Tue, 11 May 2010 06:05:46 -0500 Subject: [rabbitmq-discuss] Firewall Issues In-Reply-To: <4BE92068.9040706@lshift.net> References: <4BE812AE.2020403@loafman.com> <4BE81674.102@loafman.com> <4BE8183A.1030504@loafman.com> <4BE819A9.4050707@loafman.com> <4BE92068.9040706@lshift.net> Message-ID: <4BE93A0A.1060408@loafman.com> Tony, P1 and P2 both connect to MQ, there are no connections from MQ to Px. MQ collects data from the web and queues it to the Px instances. We're using Python Carrot for access, which is based on amqplib. Most of the data flows from MQ to Px, however some status and alert data flows from Px to MQ for queuing to other processes. ...Thanks, ...Ken Tony Garnock-Jones wrote: > Hi Kenneth, > > If you're just speaking AMQP between (P1 and MQ) and (P2 and MQ), port 5672 > should be all you need open. I'm curious though, which *direction* are > connections running between the hosts? Does P1 only ever connect to MQ, or does > MQ sometimes connect to P1? How are you relaying messages -- using shovel, or > something else? > > Tony > > > Kenneth Loafman wrote: >> Will test it tonight and let you know. >> >> ...Thanks, >> ...Ken >> >> Matt Calder wrote: >>> By default erlang uses 4369. >>> >>> Matt >>> >>> On Mon, May 10, 2010 at 10:29 AM, Kenneth Loafman wrote: >>>> What erlang ports? Just 5672:tcp. >>>> >>>> ...Ken >>>> >>>> Matt Calder wrote: >>>>> Ken, >>>>> >>>>> Are the erlang ports open? >>>>> >>>>> Matt >>>>> >>>>> On Mon, May 10, 2010 at 10:21 AM, Kenneth Loafman wrote: >>>>>> Nope, just a single node service at this point. P1 and P2 do not even >>>>>> have RabbitMQ installed, they are just MQ clients. I should have noted >>>>>> that in my original message. >>>>>> >>>>>> The process has worked well for months prior to adding the firewall. >>>>>> >>>>>> ...Ken >>>>>> >>>>>> Matt Calder wrote: >>>>>>> Ken, >>>>>>> >>>>>>> It looks like you are setting up a cluster, if so, are they sharing >>>>>>> the same cookie? >>>>>>> >>>>>>> I just went through starting a cluster here is my step-by-step: >>>>>>> >>>>>>> 1) Start a cluster of rabbits. >>>>>>> Assume cluster is on: hostA, hostB (for example) >>>>>>> >>>>>>> # The rabbitmq processes must be running with the same cookie >>>>>>> hostA> sudo rabbitmqctl stop >>>>>>> hostA> sudo /etc/init.d/rabbitmq-server stop >>>>>>> hostA> sudo rm ~rabbitmq/.erlang.cookie >>>>>>> hostA> sudo echo ABC123 | sudo tee ~rabbitmq/.erlang.cookie >>>>>>> hostA> sudo chmod 400 ~rabbitmq/.erlang.cookie >>>>>>> hostA> sudo chown rabbitmq ~rabbitmq/.erlang.cookie >>>>>>> hostA> sudo chgrp rabbitmq ~rabbitmq/.erlang.cookie >>>>>>> hostA> sudo /etc/init.d/rabbitmq-server start >>>>>>> >>>>>>> repeat for hostB >>>>>>> >>>>>>> # On join hostB to hostA >>>>>>> hostB> sudo rabbitmqctl stop_app >>>>>>> hostB> sudo rabbitmqctl reset >>>>>>> hostB> sudo rabbitmqctl cluster rabbit at hostA >>>>>>> >>>>>>> Hope that helps. >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> >>>>>>> On Mon, May 10, 2010 at 10:05 AM, Kenneth Loafman wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've got RabbitMQ up on three machines and wanted to add a firewall. >>>>>>>> The configuration is simple, MQ serves input to P1 and P2 which do all >>>>>>>> the processing. >>>>>>>> >>>>>>>> MQ >>>>>>>> / \ >>>>>>>> P1 P2 >>>>>>>> >>>>>>>> I opened the port 5672:tcp on all machines and between two machines, MQ >>>>>>>> and P1, that seems to work. When I added P2, it immediately got a >>>>>>>> 'connection refused' message. All machines are running Ubuntu 9.10 and >>>>>>>> rabbitmq-server 1.7.2. P1 and P2 are identical as far as I can tell. >>>>>>>> >>>>>>>> Any help would be appreciated. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> ...Ken >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> rabbitmq-discuss mailing list >>>>>>>> rabbitmq-discuss at lists.rabbitmq.com >>>>>>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>>>>>>> >>>>>> _______________________________________________ >>>>>> rabbitmq-discuss mailing list >>>>>> rabbitmq-discuss at lists.rabbitmq.com >>>>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>>>>> >>>> _______________________________________________ >>>> rabbitmq-discuss mailing list >>>> rabbitmq-discuss at lists.rabbitmq.com >>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>>> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > From kenneth at loafman.com Tue May 11 12:07:58 2010 From: kenneth at loafman.com (Kenneth Loafman) Date: Tue, 11 May 2010 06:07:58 -0500 Subject: [rabbitmq-discuss] Firewall Issues In-Reply-To: References: <4BE812AE.2020403@loafman.com> <4BE81674.102@loafman.com> <4BE8183A.1030504@loafman.com> Message-ID: <4BE93A8E.1030506@loafman.com> I opened both ports and the same thing happened, P1 could connect to MQ, but P2 could not. I don't see anything in the logs to indicate problems, either system or rabbitmq. ...Ken Matt Calder wrote: > So, to be clear, I think you may need 4369 and 5672 open. > > Matt > > On Mon, May 10, 2010 at 10:31 AM, Matt Calder wrote: >> By default erlang uses 4369. >> >> Matt >> >> On Mon, May 10, 2010 at 10:29 AM, Kenneth Loafman wrote: >>> What erlang ports? Just 5672:tcp. >>> >>> ...Ken >>> >>> Matt Calder wrote: >>>> Ken, >>>> >>>> Are the erlang ports open? >>>> >>>> Matt >>>> >>>> On Mon, May 10, 2010 at 10:21 AM, Kenneth Loafman wrote: >>>>> Nope, just a single node service at this point. P1 and P2 do not even >>>>> have RabbitMQ installed, they are just MQ clients. I should have noted >>>>> that in my original message. >>>>> >>>>> The process has worked well for months prior to adding the firewall. >>>>> >>>>> ...Ken >>>>> >>>>> Matt Calder wrote: >>>>>> Ken, >>>>>> >>>>>> It looks like you are setting up a cluster, if so, are they sharing >>>>>> the same cookie? >>>>>> >>>>>> I just went through starting a cluster here is my step-by-step: >>>>>> >>>>>> 1) Start a cluster of rabbits. >>>>>> Assume cluster is on: hostA, hostB (for example) >>>>>> >>>>>> # The rabbitmq processes must be running with the same cookie >>>>>> hostA> sudo rabbitmqctl stop >>>>>> hostA> sudo /etc/init.d/rabbitmq-server stop >>>>>> hostA> sudo rm ~rabbitmq/.erlang.cookie >>>>>> hostA> sudo echo ABC123 | sudo tee ~rabbitmq/.erlang.cookie >>>>>> hostA> sudo chmod 400 ~rabbitmq/.erlang.cookie >>>>>> hostA> sudo chown rabbitmq ~rabbitmq/.erlang.cookie >>>>>> hostA> sudo chgrp rabbitmq ~rabbitmq/.erlang.cookie >>>>>> hostA> sudo /etc/init.d/rabbitmq-server start >>>>>> >>>>>> repeat for hostB >>>>>> >>>>>> # On join hostB to hostA >>>>>> hostB> sudo rabbitmqctl stop_app >>>>>> hostB> sudo rabbitmqctl reset >>>>>> hostB> sudo rabbitmqctl cluster rabbit at hostA >>>>>> >>>>>> Hope that helps. >>>>>> >>>>>> Matt >>>>>> >>>>>> >>>>>> On Mon, May 10, 2010 at 10:05 AM, Kenneth Loafman wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I've got RabbitMQ up on three machines and wanted to add a firewall. >>>>>>> The configuration is simple, MQ serves input to P1 and P2 which do all >>>>>>> the processing. >>>>>>> >>>>>>> MQ >>>>>>> / \ >>>>>>> P1 P2 >>>>>>> >>>>>>> I opened the port 5672:tcp on all machines and between two machines, MQ >>>>>>> and P1, that seems to work. When I added P2, it immediately got a >>>>>>> 'connection refused' message. All machines are running Ubuntu 9.10 and >>>>>>> rabbitmq-server 1.7.2. P1 and P2 are identical as far as I can tell. >>>>>>> >>>>>>> Any help would be appreciated. >>>>>>> >>>>>>> Thanks, >>>>>>> ...Ken >>>>>>> >>>>>>> _______________________________________________ >>>>>>> rabbitmq-discuss mailing list >>>>>>> rabbitmq-discuss at lists.rabbitmq.com >>>>>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>>>>>> >>>>> _______________________________________________ >>>>> rabbitmq-discuss mailing list >>>>> rabbitmq-discuss at lists.rabbitmq.com >>>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>>>> >>> _______________________________________________ >>> rabbitmq-discuss mailing list >>> rabbitmq-discuss at lists.rabbitmq.com >>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>> > From wvandenhandel at dataraker.com Tue May 11 12:14:51 2010 From: wvandenhandel at dataraker.com (Wayne Van Den Handel) Date: Tue, 11 May 2010 07:14:51 -0400 Subject: [rabbitmq-discuss] Scalability? In-Reply-To: <4BE92955.3010202@lshift.net> References: <4BE3013E.9080308@dataraker.com> <89839F8F-ABB1-4B04-AAAD-633E4CF60185@gmail.com> <20100507120026.GJ2739@mrnibble.lshift.net> <4BE476C3.8040707@dataraker.com> <4BE48685.8070307@rabbitmq.com> <4BE48F2A.5070603@dataraker.com> <4BE92955.3010202@lshift.net> Message-ID: <4BE93C2B.3020505@dataraker.com> An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100511/266909d9/attachment.htm From shane at digitalsanctum.com Tue May 11 14:02:59 2010 From: shane at digitalsanctum.com (Shane) Date: Tue, 11 May 2010 06:02:59 -0700 (PDT) Subject: [rabbitmq-discuss] getting started In-Reply-To: <4BE92362.3070507@lshift.net> References: <5a5b6326-7eb8-4eb8-be39-c921f1f59a14@k29g2000yqh.googlegroups.com> <4BE92362.3070507@lshift.net> Message-ID: Thanks for the responses so far although I haven't found the cause of the issue yet. I've verified that iptables has port 5672 open and I checked the the rabbitmq log and there doesn't appear to be an issue and indicates it starts a listener on 0.0.0.0:5672. I'm not behind a corporate firewall so that's moot here. The broker install is the out- of-the-box config so I have the defaults set for everything including the user/pass (I intend on changing this after I get the initial setup working). Any other ideas? Thanks, Shane On May 11, 5:29?am, Tony Garnock-Jones wrote: > Hi Shane, > > Shane wrote: > > /Library/Ruby/Gems/1.8/gems/amqp-0.6.7/lib/amqp/client.rb:65:in > > `initialize': Could not connect to server ds1:5672 (AMQP::Error) > > ? ?from /Library/Ruby/Gems/1.8/gems/amqp-0.6.7/lib/amqp/client.rb:97:in > > `call' > > ? ?from /Library/Ruby/Gems/1.8/gems/amqp-0.6.7/lib/amqp/client.rb:97:in > > `unbind' > > I suggest checking the RabbitMQ log files on your server machine to see if they > give any clues. > > (Also, is what's 'unbind' doing in there? Looking at the rb amqp sources, it > looks like that's a kind of disconnected-indicator? Perhaps you're falling foul > of the AMQP spec rule that says servers have to be brutal and silent when > rejecting a user's login for invalid credentials: are the username and password > correct for the new cloudy server?) > > Tony > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-disc... at lists.rabbitmq.comhttp://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > -- > You received this message because you are subscribed to the Google Groups "rabbitmq-discuss" group. > To post to this group, send email to rabbitmq-discuss at googlegroups.com. > To unsubscribe from this group, send email to rabbitmq-discuss+unsubscribe at googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rabbitmq-discuss?hl=en. From davorin.rusevljan at gmail.com Tue May 11 14:16:30 2010 From: davorin.rusevljan at gmail.com (Davorin Rusevljan) Date: Tue, 11 May 2010 15:16:30 +0200 Subject: [rabbitmq-discuss] getting started In-Reply-To: References: <5a5b6326-7eb8-4eb8-be39-c921f1f59a14@k29g2000yqh.googlegroups.com> <4BE92362.3070507@lshift.net> Message-ID: On Tue, May 11, 2010 at 3:02 PM, Shane wrote: > Thanks for the responses so far although I haven't found the cause of > the issue yet. I've verified that iptables has port 5672 open and I > checked the the rabbitmq log and there doesn't appear to be an issue > and indicates it starts a listener on 0.0.0.0:5672. I'm not behind a > corporate firewall so that's moot here. The broker install is the out- > of-the-box config so I have the defaults set for everything including > the user/pass (I intend on changing this after I get the initial setup > working). > > Any other ideas? > > try to open port 5672 on the server from your local machine, with some other program, telnet perhaps. rush http://www.cloud208.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100511/efa4d6d5/attachment.htm From alexis at rabbitmq.com Tue May 11 15:01:38 2010 From: alexis at rabbitmq.com (Alexis Richardson) Date: Tue, 11 May 2010 15:01:38 +0100 Subject: [rabbitmq-discuss] RabbitMQ config file. In-Reply-To: <49A7BA114AAC6A48B9C44CB06B7B987E0A211478@HYDSVWIN004X.ivycomptech.partygaming.local> References: <49A7BA114AAC6A48B9C44CB06B7B987E0A211478@HYDSVWIN004X.ivycomptech.partygaming.local> Message-ID: Radha Please could you tell us a bit more about your use cases? Best wishes alexis On Tue, May 11, 2010 at 7:35 AM, Radha Krishnan D wrote: > Hi, > > > > ??????????? We are evaluating rabbitMQ?s performance for our use cases. We > are using rabbitmq-server-1.7.2? ( downloaded under the heading generic > Linux ). Since our linux machine RAM is 8 GB and it is a 32 bit machine. > RabbitMQ takes 1638 MB and it prints it in the logs. How ever when I want to > increase the size by using?? {rabbit, [{vm_memory_high_watermark,? 2.0}]} > the rabbitMQ server is not recognizing this configuration change ?at all. > > > > I did a change in the rabbitmq-server file pointing > CONFIG_FILE=/home/ppoker/MessagingPOC/RabbitMQ/rabbitmq???? rabbitmq.config > is my file name. > > > > Earlier, in the default run. You have mentioned that the default config file > for generic unix will be in /etc/rabbitmq/rabbitmq.config. I did not get > this file there. > > > > Where am I going wrong ? > > Please suggest me a solution and a sample copy of the rabbitmq.config file. > > Also please clear us about the difference between rabbitmq.conf file and > rabbitmq.config file. > > > > > > Thanks and Regards, > > D.Radhakrishnan > Trainee?Engineer-Architecture > > IVY Comptech Private Limited > Cyber Spazio,Road No 2, Banjara Hills, > Hyderabad-500034, Andhra Pradesh. > > Phone + 91 (40) 66721000 ? 4638 > Mobile + 91 (0) 9030842104 > > This email and any attachments are confidential, legally privileged and > protected by copyright. If you are not the intended recipient, dissemination > or copying this email is prohibited. If you have received this in error, > please notify the sender by replying by email and then delete the email > completely from your system. > > Any views or opinions are solely those of? the sender. This communication is > not intended to form a binding contract unless expressly indicated to the > contrary and properly authorized. Any actions taken on the basis of this > email are at recipient?s own risk. > > > > ________________________________ > > This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy > Comptech Private Limited is a limited liability company. > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended recipient > dissemination or copying of this email is prohibited. If you have received > this in error, please notify the sender by replying by email and then delete > the email completely from your system. Any views or opinions are solely > those of the sender.? This communication is not intended to form a binding > contract on behalf of Ivy Comptech Private Limited unless expressly > indicated to the contrary and properly authorised. Any actions taken on the > basis of this email are at the recipient's own risk. > > Registered?Office: > > Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, > Hyderabad 500 033, Andhra Pradesh, India. > > Registered number: 37994. Registered in India. A list of members' names is > available for inspection at the registered office. > > ________________________________ > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > From RadhakrishnanD at ivycomptech.com Tue May 11 15:08:25 2010 From: RadhakrishnanD at ivycomptech.com (Radha Krishnan D) Date: Tue, 11 May 2010 19:38:25 +0530 Subject: [rabbitmq-discuss] RabbitMQ config file. In-Reply-To: References: <49A7BA114AAC6A48B9C44CB06B7B987E0A211478@HYDSVWIN004X.ivycomptech.partygaming.local> Message-ID: <49A7BA114AAC6A48B9C44CB06B7B987E0A211A97@HYDSVWIN004X.ivycomptech.partygaming.local> Hi alex, We are now trying to sent messages from one producer to the exchange and a consumer takes that message from the queue binded to that exchange. In the producer side : ------------------------- 10 threads send messages continuosly In the receiver side ---------------------- One thread receives all messages. we used the default configuration of rabbitmq-server and start the test. In the logs it has printed saying 1638MB of memory is used. After some time, the server runs out of memory and says Erlang has closed. We don t know how to increase the size from 1638 MB. we tried defining a new config file but the rabbitmq server is not recognizing it even though we specified the path in the rabbitmq-server file. Thanks and Regards, D.Radhakrishnan Trainee Engineer-Architecture IVY Comptech Private Limited Cyber Spazio,Road No 2, Banjara Hills, Hyderabad-500034, Andhra Pradesh. Phone + 91 (40) 66721000 - 4638 Mobile + 91 (0) 9030842104 This email and any attachments are confidential, legally privileged and protected by copyright. If you are not the intended recipient, dissemination or copying this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorized. Any actions taken on the basis of this email are at recipient's own risk. -----Original Message----- From: alexis.richardson at gmail.com [mailto:alexis.richardson at gmail.com] On Behalf Of Alexis Richardson Sent: Tuesday, May 11, 2010 7:32 PM To: Radha Krishnan D Cc: rabbitmq info; RabbitMQ Discuss Subject: Re: [rabbitmq-discuss] RabbitMQ config file. Radha Please could you tell us a bit more about your use cases? Best wishes alexis On Tue, May 11, 2010 at 7:35 AM, Radha Krishnan D wrote: > Hi, > > > > ??????????? We are evaluating rabbitMQ's performance for our use cases. We > are using rabbitmq-server-1.7.2? ( downloaded under the heading generic > Linux ). Since our linux machine RAM is 8 GB and it is a 32 bit machine. > RabbitMQ takes 1638 MB and it prints it in the logs. How ever when I want to > increase the size by using?? {rabbit, [{vm_memory_high_watermark,? 2.0}]} > the rabbitMQ server is not recognizing this configuration change ?at all. > > > > I did a change in the rabbitmq-server file pointing > CONFIG_FILE=/home/ppoker/MessagingPOC/RabbitMQ/rabbitmq???? rabbitmq.config > is my file name. > > > > Earlier, in the default run. You have mentioned that the default config file > for generic unix will be in /etc/rabbitmq/rabbitmq.config. I did not get > this file there. > > > > Where am I going wrong ? > > Please suggest me a solution and a sample copy of the rabbitmq.config file. > > Also please clear us about the difference between rabbitmq.conf file and > rabbitmq.config file. > > > > > > Thanks and Regards, > > D.Radhakrishnan > Trainee?Engineer-Architecture > > IVY Comptech Private Limited > Cyber Spazio,Road No 2, Banjara Hills, > Hyderabad-500034, Andhra Pradesh. > > Phone + 91 (40) 66721000 - 4638 > Mobile + 91 (0) 9030842104 > > This email and any attachments are confidential, legally privileged and > protected by copyright. If you are not the intended recipient, dissemination > or copying this email is prohibited. If you have received this in error, > please notify the sender by replying by email and then delete the email > completely from your system. > > Any views or opinions are solely those of? the sender. This communication is > not intended to form a binding contract unless expressly indicated to the > contrary and properly authorized. Any actions taken on the basis of this > email are at recipient's own risk. > > > > ________________________________ > > This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy > Comptech Private Limited is a limited liability company. > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended recipient > dissemination or copying of this email is prohibited. If you have received > this in error, please notify the sender by replying by email and then delete > the email completely from your system. Any views or opinions are solely > those of the sender.? This communication is not intended to form a binding > contract on behalf of Ivy Comptech Private Limited unless expressly > indicated to the contrary and properly authorised. Any actions taken on the > basis of this email are at the recipient's own risk. > > Registered?Office: > > Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, > Hyderabad 500 033, Andhra Pradesh, India. > > Registered number: 37994. Registered in India. A list of members' names is > available for inspection at the registered office. > > ________________________________ > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy Comptech Private Limited is a limited liability company. This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract on behalf of Ivy Comptech Private Limited unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. Registered office: Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, Hyderabad 500 033, Andhra Pradesh, India. Registered number: 37994. Registered in India. A list of members' names is available for inspection at the registered office. From mvcalder at gmail.com Tue May 11 16:20:12 2010 From: mvcalder at gmail.com (Matt Calder) Date: Tue, 11 May 2010 11:20:12 -0400 Subject: [rabbitmq-discuss] Clustering question Message-ID: Hi, I am following along the clustering guide and not getting expected results. I have two machines running rabbitmq, and they can communicate (each can send messages to the other). So as per the clustering guide I run: ubuntu at domU-2:~/tmp$ sudo rabbitmqctl stop_app Stopping node 'rabbit at domU-2 ... ...done. ubuntu at domU-2:~/tmp$ sudo rabbitmqctl reset Resetting node 'rabbit at domU-2' ... ...done. ubuntu at domU-2:~/tmp$ sudo rabbitmqctl cluster rabbit at domU-1 Clustering node 'rabbit at domU-2' with ['rabbit at domU-1'] ... ...done. ubuntu at domU-2:~/tmp$ sudo rabbitmqctl status Status of node 'rabbit at domU-2' ... [{running_applications,[{sasl,"SASL CXC 138 11","2.1.6"}, {stdlib,"ERTS CXC 138 10","1.16.2"}, {kernel,"ERTS CXC 138 10","2.13.2"}]}, {nodes,['rabbit at domU-2']}, {running_nodes,[]}] ...done. So despite the fact that it appeared to run, you can see that there are no running nodes. On the other machine: ubuntu at domU-1:~/tmp$ sudo rabbitmqctl status Status of node 'rabbit at domU-1' ... [{running_applications,[{rabbit,"RabbitMQ","1.6.0"}, {mnesia,"MNESIA CXC 138 12","4.4.10"}, {os_mon,"CPO CXC 138 46","2.2.2"}, {sasl,"SASL CXC 138 11","2.1.6"}, {stdlib,"ERTS CXC 138 10","1.16.2"}, {kernel,"ERTS CXC 138 10","2.13.2"}]}, {nodes,['rabbit at domU1','rabbit at domU-2']}, {running_nodes,['rabbit at domU-1']}] ...done. So the this machine is aware of the other, but is unable to communicate with it. Both machines have the same cookie in ~rabbitmq/.erlang.cookie . I do not see any errors in the logs. Like I said above, I can communicate from each machine to the other withou a problem. Any suggestions would be helpful, thanks. Matt From matthew at lshift.net Tue May 11 16:28:59 2010 From: matthew at lshift.net (Matthew Sackman) Date: Tue, 11 May 2010 16:28:59 +0100 Subject: [rabbitmq-discuss] Clustering question In-Reply-To: References: Message-ID: <20100511152859.GA11279@wellquite.org> Hi Matt, On Tue, May 11, 2010 at 11:20:12AM -0400, Matt Calder wrote: > I am following along the clustering guide and not getting expected > results. I have two machines running rabbitmq, and they can > communicate (each can send messages to the other). So as per the > clustering guide I run: > > ubuntu at domU-2:~/tmp$ sudo rabbitmqctl stop_app > Stopping node 'rabbit at domU-2 ... > ...done. > ubuntu at domU-2:~/tmp$ sudo rabbitmqctl reset > Resetting node 'rabbit at domU-2' ... > ...done. > ubuntu at domU-2:~/tmp$ sudo rabbitmqctl cluster rabbit at domU-1 > Clustering node 'rabbit at domU-2' with ['rabbit at domU-1'] ... > ...done. > ubuntu at domU-2:~/tmp$ sudo rabbitmqctl status > Status of node 'rabbit at domU-2' ... > [{running_applications,[{sasl,"SASL CXC 138 11","2.1.6"}, > {stdlib,"ERTS CXC 138 10","1.16.2"}, > {kernel,"ERTS CXC 138 10","2.13.2"}]}, > {nodes,['rabbit at domU-2']}, > {running_nodes,[]}] > ...done. > > So despite the fact that it appeared to run, you can see that there > are no running nodes. The crucial step you're missing is to restart rabbit: ubuntu at domU-2:~/tmp$ sudo rabbitmqctl start_app > On the other machine: > > ubuntu at domU-1:~/tmp$ sudo rabbitmqctl status > Status of node 'rabbit at domU-1' ... > [{running_applications,[{rabbit,"RabbitMQ","1.6.0"}, > {mnesia,"MNESIA CXC 138 12","4.4.10"}, > {os_mon,"CPO CXC 138 46","2.2.2"}, > {sasl,"SASL CXC 138 11","2.1.6"}, > {stdlib,"ERTS CXC 138 10","1.16.2"}, > {kernel,"ERTS CXC 138 10","2.13.2"}]}, > {nodes,['rabbit at domU1','rabbit at domU-2']}, > {running_nodes,['rabbit at domU-1']}] > ...done. domU-1 knows of the existence of domU-2 now (hence it being listed in nodes), but as you've not started it up again, it's not running. Matthew From jewel at subvert-the-dominant-paradigm.net Tue May 11 16:34:40 2010 From: jewel at subvert-the-dominant-paradigm.net (John Leuner) Date: Tue, 11 May 2010 17:34:40 +0200 Subject: [rabbitmq-discuss] Bugs filed against debian rabbitmq-server package Message-ID: <1273592080.5318.10.camel@cmalu.WAG54GS> Hi Guys There are a few bugs filed against the debian package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540328 rabbitmq-server: INSTALL file installed to /usr/lib/erlang/lib/rabbitmq_server-*/ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552434 rabbitmq-server: Provide defaults in init.d http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543638 rabbitmq-server: Please provide /etc/default/rabbitmq, /etc/rabbitmq/rabbitmq.conf Can you comment on these? Thanks John Leuner From matthew at lshift.net Tue May 11 16:49:11 2010 From: matthew at lshift.net (Matthew Sackman) Date: Tue, 11 May 2010 16:49:11 +0100 Subject: [rabbitmq-discuss] Bugs filed against debian rabbitmq-server package In-Reply-To: <1273592080.5318.10.camel@cmalu.WAG54GS> References: <1273592080.5318.10.camel@cmalu.WAG54GS> Message-ID: <20100511154910.GB11279@wellquite.org> Hi John, On Tue, May 11, 2010 at 05:34:40PM +0200, John Leuner wrote: > There are a few bugs filed against the debian package: Thanks for bringing these to our attention. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540328 > rabbitmq-server: INSTALL file installed > to /usr/lib/erlang/lib/rabbitmq_server-*/ Hmm, that's filed against 1.6.0 which is pretty ancient. However, it's still current: matthew at mrnibble:~$ dpkg -c /home/matthew/Download/rabbitmq-server_1.7.2-1_all.deb | grep INSTALL -rw-r--r-- root/root 23346 2010-02-15 16:01 ./usr/lib/rabbitmq/lib/rabbitmq_server-1.7.2/INSTALL I'll file a bug internally to get this fixed in the next release - looks to me like it still exists in our source tree. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552434 > rabbitmq-server: Provide defaults in init.d Yup, again looks valid - we seem to have blank lines for these cases: # Default-Start: # Default-Stop: it's possible that there's a reason for that, but I'll check and get it fixed if not. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543638 > rabbitmq-server: Please > provide /etc/default/rabbitmq, /etc/rabbitmq/rabbitmq.conf Yeah, our configuration system isn't in the best of health, and related documentation is anemic at best. We have a pretty high priority bug open to sort all of this out but it's unlikely to make it for the next major release. Matthew From mvcalder at gmail.com Tue May 11 17:53:19 2010 From: mvcalder at gmail.com (Matt Calder) Date: Tue, 11 May 2010 12:53:19 -0400 Subject: [rabbitmq-discuss] Clustering question In-Reply-To: <20100511152859.GA11279@wellquite.org> References: <20100511152859.GA11279@wellquite.org> Message-ID: Matt, Uh, yep. Thanks. Matt On Tue, May 11, 2010 at 11:28 AM, Matthew Sackman wrote: > Hi Matt, > > On Tue, May 11, 2010 at 11:20:12AM -0400, Matt Calder wrote: >> I am following along the clustering guide and not getting expected >> results. I have two machines running rabbitmq, and they can >> communicate (each can send messages to the other). So as per the >> clustering guide I run: >> >> ubuntu at domU-2:~/tmp$ sudo rabbitmqctl stop_app >> Stopping node 'rabbit at domU-2 ... >> ...done. >> ubuntu at domU-2:~/tmp$ sudo rabbitmqctl reset >> Resetting node 'rabbit at domU-2' ... >> ...done. >> ubuntu at domU-2:~/tmp$ sudo rabbitmqctl cluster rabbit at domU-1 >> Clustering node 'rabbit at domU-2' with ['rabbit at domU-1'] ... >> ...done. >> ubuntu at domU-2:~/tmp$ sudo rabbitmqctl status >> Status of node 'rabbit at domU-2' ... >> [{running_applications,[{sasl,"SASL ?CXC 138 11","2.1.6"}, >> ? ? ? ? ? ? ? ? ? ? ? ? {stdlib,"ERTS ?CXC 138 10","1.16.2"}, >> ? ? ? ? ? ? ? ? ? ? ? ? {kernel,"ERTS ?CXC 138 10","2.13.2"}]}, >> ?{nodes,['rabbit at domU-2']}, >> ?{running_nodes,[]}] >> ...done. >> >> So despite the fact that it appeared to run, you can see that there >> are no running nodes. > > The crucial step you're missing is to restart rabbit: > > ubuntu at domU-2:~/tmp$ sudo rabbitmqctl start_app > >> On the other machine: >> >> ubuntu at domU-1:~/tmp$ sudo rabbitmqctl status >> Status of node 'rabbit at domU-1' ... >> [{running_applications,[{rabbit,"RabbitMQ","1.6.0"}, >> ? ? ? ? ? ? ? ? ? ? ? ? {mnesia,"MNESIA ?CXC 138 12","4.4.10"}, >> ? ? ? ? ? ? ? ? ? ? ? ? {os_mon,"CPO ?CXC 138 46","2.2.2"}, >> ? ? ? ? ? ? ? ? ? ? ? ? {sasl,"SASL ?CXC 138 11","2.1.6"}, >> ? ? ? ? ? ? ? ? ? ? ? ? {stdlib,"ERTS ?CXC 138 10","1.16.2"}, >> ? ? ? ? ? ? ? ? ? ? ? ? {kernel,"ERTS ?CXC 138 10","2.13.2"}]}, >> ?{nodes,['rabbit at domU1','rabbit at domU-2']}, >> ?{running_nodes,['rabbit at domU-1']}] >> ...done. > > domU-1 knows of the existence of domU-2 now (hence it being listed in > nodes), but as you've not started it up again, it's not running. > > Matthew > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > From florian.haas at linbit.com Tue May 11 18:09:37 2010 From: florian.haas at linbit.com (Florian Haas) Date: Tue, 11 May 2010 19:09:37 +0200 Subject: [rabbitmq-discuss] [PATCH 00 of 10] Several improvements to the OCF resource agent Message-ID: Greetings, I was only recently made aware of the existence of the rabbitmq-server OCF resource agent (through the howto at http://www.rabbitmq.com/pacemaker.html), had a quick look, and took the liberty to fix a few simple issues. The individual patch descriptions should be fairly self-explanatory (I hope) -- please do fire questions back at me if I left anything unclear, or misunderstood some concept and hence introduced something bogus. These modifications should support resource-agents (on debian: cluster-agents) 1.0.3 and above. Hope this is useful. Cheers, Florian From florian.haas at linbit.com Tue May 11 18:09:41 2010 From: florian.haas at linbit.com (Florian Haas) Date: Tue, 11 May 2010 19:09:41 +0200 Subject: [rabbitmq-discuss] [PATCH 04 of 10] OCF resource agent: on error, exit, don't return In-Reply-To: References: Message-ID: # HG changeset patch # User Florian Haas # Date 1273593909 -7200 # Node ID f0a7e4621b20a35c6cf20b2393d7d6b3f02fbc7b # Parent 62ca42a0d9e9ee39a7c4348795693c1a71af269b OCF resource agent: on error, exit, don't return When they encounter an error condition, OCF RAs can simply exit. No need to return from the relevant functions. diff -r 62ca42a0d9e9 -r f0a7e4621b20 packaging/common/rabbitmq-server.ocf --- a/packaging/common/rabbitmq-server.ocf Tue May 11 17:50:42 2010 +0200 +++ b/packaging/common/rabbitmq-server.ocf Tue May 11 18:05:09 2010 +0200 @@ -204,34 +204,34 @@ rabbit_validate_partial() { if [ ! -x $RABBITMQ_MULTI ]; then ocf_log err "rabbitmq-server multi $RABBITMQ_MULTI does not exist or is not executable"; - return $OCF_ERR_ARGS; + exit $OCF_ERR_ARGS; fi if [ ! -x $RABBITMQ_CTL ]; then ocf_log err "rabbitmq-server ctl $RABBITMQ_CTL does not exist or is not executable"; - return $OCF_ERR_ARGS; + exit $OCF_ERR_ARGS; fi } rabbit_validate_full() { if [ ! -z $RABBITMQ_CLUSTER_CONFIG_FILE ] && [ ! -e $RABBITMQ_CLUSTER_CONFIG_FILE ]; then ocf_log err "rabbitmq-server cluster_config_file $RABBITMQ_CLUSTER_CONFIG_FILE does not exist or is not a file"; - return $OCF_ERR_ARGS; + exit $OCF_ERR_ARGS; fi if [ ! -z $RABBITMQ_CONFIG_FILE ] && [ ! -e $RABBITMQ_CONFIG_FILE ]; then ocf_log err "rabbitmq-server config_file $RABBITMQ_CONFIG_FILE does not exist or is not a file"; - return $OCF_ERR_ARGS; + exit $OCF_ERR_ARGS; fi if [ ! -z $RABBITMQ_LOG_BASE ] && [ ! -d $RABBITMQ_LOG_BASE ]; then ocf_log err "rabbitmq-server log_base $RABBITMQ_LOG_BASE does not exist or is not a directory"; - return $OCF_ERR_ARGS; + exit $OCF_ERR_ARGS; fi if [ ! -z $RABBITMQ_MNESIA_BASE ] && [ ! -d $RABBITMQ_MNESIA_BASE ]; then ocf_log err "rabbitmq-server mnesia_base $RABBITMQ_MNESIA_BASE does not exist or is not a directory"; - return $OCF_ERR_ARGS; + exit $OCF_ERR_ARGS; fi rabbit_validate_partial @@ -252,7 +252,7 @@ ;; *) ocf_log err "Unexpected return from rabbitmqctl $NODENAME_ARG status: $rc" - return $OCF_ERR_GENERIC + exit $OCF_ERR_GENERIC esac } @@ -285,7 +285,7 @@ elif [ "$rc" != $OCF_NOT_RUNNING ]; then ocf_log info "rabbitmq-server start failed: $rc" - return $OCF_ERR_GENERIC + exit $OCF_ERR_GENERIC fi sleep 2 done @@ -320,7 +320,7 @@ break elif [ "$rc" != $OCF_SUCCESS ]; then ocf_log info "rabbitmq-server stop failed: $rc" - return $OCF_ERR_GENERIC + exit $OCF_ERR_GENERIC fi sleep 2 done @@ -345,9 +345,9 @@ esac if ocf_is_probe; then - rabbit_validate_partial || exit + rabbit_validate_partial else - rabbit_validate_full || exit + rabbit_validate_full fi case $__OCF_ACTION in From florian.haas at linbit.com Tue May 11 18:09:38 2010 From: florian.haas at linbit.com (Florian Haas) Date: Tue, 11 May 2010 19:09:38 +0200 Subject: [rabbitmq-discuss] [PATCH 01 of 10] OCF resource agent: use $OCF_FUNCTIONS_DIR In-Reply-To: References: Message-ID: # HG changeset patch # User Florian Haas # Date 1273592708 -7200 # Node ID d3292da34f9963c156ea2987cd0a15fd313b61d5 # Parent 2270e05861f9b19a85b934b3a3cfff92ffb88440 OCF resource agent: use $OCF_FUNCTIONS_DIR Linux-HA introduced the $OCF_FUNCTIONS_DIR variable to make resource agents executable in-place. diff -r 2270e05861f9 -r d3292da34f99 packaging/common/rabbitmq-server.ocf --- a/packaging/common/rabbitmq-server.ocf Fri May 07 17:43:08 2010 +0100 +++ b/packaging/common/rabbitmq-server.ocf Tue May 11 17:45:08 2010 +0200 @@ -49,7 +49,8 @@ ####################################################################### # Initialization: -. ${OCF_ROOT}/resource.d/heartbeat/.ocf-shellfuncs +: ${OCF_FUNCTIONS_DIR=${OCF_ROOT}/resource.d/heartbeat} +. ${OCF_FUNCTIONS_DIR}/.ocf-shellfuncs ####################################################################### @@ -359,4 +360,4 @@ ;; esac -exit $? \ No newline at end of file +exit $? From florian.haas at linbit.com Tue May 11 18:09:40 2010 From: florian.haas at linbit.com (Florian Haas) Date: Tue, 11 May 2010 19:09:40 +0200 Subject: [rabbitmq-discuss] [PATCH 03 of 10] OCF resource agent: correctly behave on start and stop In-Reply-To: References: Message-ID: <62ca42a0d9e9ee39a7c4.1273597780@gluehwein.linbit> # HG changeset patch # User Florian Haas # Date 1273593042 -7200 # Node ID 62ca42a0d9e9ee39a7c4348795693c1a71af269b # Parent 756422c2ee0871e255ffae831d1fbddc9a2d7fb5 OCF resource agent: correctly behave on start and stop Stopping a stopped resource must return without error. Likewise, starting a started resource must return without error. Check for status before blindly invoking start and stop. diff -r 756422c2ee08 -r 62ca42a0d9e9 packaging/common/rabbitmq-server.ocf --- a/packaging/common/rabbitmq-server.ocf Tue May 11 17:47:48 2010 +0200 +++ b/packaging/common/rabbitmq-server.ocf Tue May 11 17:50:42 2010 +0200 @@ -259,6 +259,11 @@ rabbit_start() { local rc + if rabbit_status; then + ocf_log info "Resource already running." + return $OCF_SUCCESS + fi + export_vars $RABBITMQ_MULTI start_all 1 > ${RABBITMQ_LOG_BASE}/startup_log 2> ${RABBITMQ_LOG_BASE}/startup_err & @@ -290,6 +295,12 @@ rabbit_stop() { local rc + + if ! rabbit_status; then + ocf_log info "Resource not running." + return $OCF_SUCCESS + fi + $RABBITMQ_MULTI stop_all & rc=$? From florian.haas at linbit.com Tue May 11 18:09:44 2010 From: florian.haas at linbit.com (Florian Haas) Date: Tue, 11 May 2010 19:09:44 +0200 Subject: [rabbitmq-discuss] [PATCH 07 of 10] OCF resource agent: add status operation In-Reply-To: References: Message-ID: # HG changeset patch # User Florian Haas # Date 1273594291 -7200 # Node ID b3e53e4d8fefabe130b4340a7efaebb14edd1b68 # Parent 26aaf9c7bf34750b15b272f4cbf096abaf7acca6 OCF resource agent: add status operation Even when it is identical to monitor, a status operation should still be advertised. diff -r 26aaf9c7bf34 -r b3e53e4d8fef packaging/common/rabbitmq-server.ocf --- a/packaging/common/rabbitmq-server.ocf Tue May 11 18:07:53 2010 +0200 +++ b/packaging/common/rabbitmq-server.ocf Tue May 11 18:11:31 2010 +0200 @@ -162,6 +162,7 @@ + @@ -172,7 +173,7 @@ rabbit_usage() { cat < References: Message-ID: <26aaf9c7bf34750b15b2.1273597783@gluehwein.linbit> # HG changeset patch # User Florian Haas # Date 1273594073 -7200 # Node ID 26aaf9c7bf34750b15b272f4cbf096abaf7acca6 # Parent 2a468e9f5b96c9d31554525c5b00852f0f302487 OCF resource agent: fix incorrect parameter type Any IP port should be an integer. Fix metadata so GUIs and the CRM shell report the parameter type correctly. diff -r 2a468e9f5b96 -r 26aaf9c7bf34 packaging/common/rabbitmq-server.ocf --- a/packaging/common/rabbitmq-server.ocf Tue May 11 18:06:46 2010 +0200 +++ b/packaging/common/rabbitmq-server.ocf Tue May 11 18:07:53 2010 +0200 @@ -114,7 +114,7 @@ The IP Port for rabbitmq-server to listen on IP Port - + From florian.haas at linbit.com Tue May 11 18:09:46 2010 From: florian.haas at linbit.com (Florian Haas) Date: Tue, 11 May 2010 19:09:46 +0200 Subject: [rabbitmq-discuss] [PATCH 09 of 10] OCF resource agent: log debug messages on status In-Reply-To: References: Message-ID: # HG changeset patch # User Florian Haas # Date 1273594852 -7200 # Node ID d3688173161f9cbaf4010258ca3bce8d3fb7d5ec # Parent c038772a3687102366ae5d54c39c754f3aedbab8 OCF resource agent: log debug messages on status Log simple debug messages when the resource is running, or has been stopped gracefully. diff -r c038772a3687 -r d3688173161f packaging/common/rabbitmq-server.ocf --- a/packaging/common/rabbitmq-server.ocf Tue May 11 18:12:29 2010 +0200 +++ b/packaging/common/rabbitmq-server.ocf Tue May 11 18:20:52 2010 +0200 @@ -246,9 +246,11 @@ rc=$? case "$rc" in 0) + ocf_log debug "RabbitMQ server is running normally" return $OCF_SUCCESS ;; 2) + ocf_log debug "RabbitMQ server is not running" return $OCF_NOT_RUNNING ;; *) From florian.haas at linbit.com Tue May 11 18:09:42 2010 From: florian.haas at linbit.com (Florian Haas) Date: Tue, 11 May 2010 19:09:42 +0200 Subject: [rabbitmq-discuss] [PATCH 05 of 10] OCF resource agent: fix validate exit codes In-Reply-To: References: Message-ID: <2a468e9f5b96c9d31554.1273597782@gluehwein.linbit> # HG changeset patch # User Florian Haas # Date 1273594006 -7200 # Node ID 2a468e9f5b96c9d31554525c5b00852f0f302487 # Parent f0a7e4621b20a35c6cf20b2393d7d6b3f02fbc7b OCF resource agent: fix validate exit codes Exit with $OCF_ERR_INSTALLED if validate fails due to non-availability of a required binary, or config file. diff -r f0a7e4621b20 -r 2a468e9f5b96 packaging/common/rabbitmq-server.ocf --- a/packaging/common/rabbitmq-server.ocf Tue May 11 18:05:09 2010 +0200 +++ b/packaging/common/rabbitmq-server.ocf Tue May 11 18:06:46 2010 +0200 @@ -204,34 +204,34 @@ rabbit_validate_partial() { if [ ! -x $RABBITMQ_MULTI ]; then ocf_log err "rabbitmq-server multi $RABBITMQ_MULTI does not exist or is not executable"; - exit $OCF_ERR_ARGS; + exit $OCF_ERR_INSTALLED; fi if [ ! -x $RABBITMQ_CTL ]; then ocf_log err "rabbitmq-server ctl $RABBITMQ_CTL does not exist or is not executable"; - exit $OCF_ERR_ARGS; + exit $OCF_ERR_INSTALLED; fi } rabbit_validate_full() { if [ ! -z $RABBITMQ_CLUSTER_CONFIG_FILE ] && [ ! -e $RABBITMQ_CLUSTER_CONFIG_FILE ]; then ocf_log err "rabbitmq-server cluster_config_file $RABBITMQ_CLUSTER_CONFIG_FILE does not exist or is not a file"; - exit $OCF_ERR_ARGS; + exit $OCF_ERR_INSTALLED; fi if [ ! -z $RABBITMQ_CONFIG_FILE ] && [ ! -e $RABBITMQ_CONFIG_FILE ]; then ocf_log err "rabbitmq-server config_file $RABBITMQ_CONFIG_FILE does not exist or is not a file"; - exit $OCF_ERR_ARGS; + exit $OCF_ERR_INSTALLED; fi if [ ! -z $RABBITMQ_LOG_BASE ] && [ ! -d $RABBITMQ_LOG_BASE ]; then ocf_log err "rabbitmq-server log_base $RABBITMQ_LOG_BASE does not exist or is not a directory"; - exit $OCF_ERR_ARGS; + exit $OCF_ERR_INSTALLED; fi if [ ! -z $RABBITMQ_MNESIA_BASE ] && [ ! -d $RABBITMQ_MNESIA_BASE ]; then ocf_log err "rabbitmq-server mnesia_base $RABBITMQ_MNESIA_BASE does not exist or is not a directory"; - exit $OCF_ERR_ARGS; + exit $OCF_ERR_INSTALLED; fi rabbit_validate_partial From florian.haas at linbit.com Tue May 11 18:09:45 2010 From: florian.haas at linbit.com (Florian Haas) Date: Tue, 11 May 2010 19:09:45 +0200 Subject: [rabbitmq-discuss] [PATCH 08 of 10] OCF resource agent: remove bogus parameters for monitor op In-Reply-To: References: Message-ID: # HG changeset patch # User Florian Haas # Date 1273594349 -7200 # Node ID c038772a3687102366ae5d54c39c754f3aedbab8 # Parent b3e53e4d8fefabe130b4340a7efaebb14edd1b68 OCF resource agent: remove bogus parameters for monitor op "depth" is actually not used, and "start-delay" is strongly deprecated. No need to advertise them. diff -r b3e53e4d8fef -r c038772a3687 packaging/common/rabbitmq-server.ocf --- a/packaging/common/rabbitmq-server.ocf Tue May 11 18:11:31 2010 +0200 +++ b/packaging/common/rabbitmq-server.ocf Tue May 11 18:12:29 2010 +0200 @@ -163,7 +163,7 @@ - + From florian.haas at linbit.com Tue May 11 18:09:39 2010 From: florian.haas at linbit.com (Florian Haas) Date: Tue, 11 May 2010 19:09:39 +0200 Subject: [rabbitmq-discuss] [PATCH 02 of 10] OCF resource agent: use ocf_is_probe In-Reply-To: References: Message-ID: <756422c2ee0871e255ff.1273597779@gluehwein.linbit> # HG changeset patch # User Florian Haas # Date 1273592868 -7200 # Node ID 756422c2ee0871e255ffae831d1fbddc9a2d7fb5 # Parent d3292da34f9963c156ea2987cd0a15fd313b61d5 OCF resource agent: use ocf_is_probe Linux-HA comes with the ocf_is_probe function to determine whether a probe operation is in progress. Use this to determine whether to do full or partial validation. diff -r d3292da34f99 -r 756422c2ee08 packaging/common/rabbitmq-server.ocf --- a/packaging/common/rabbitmq-server.ocf Tue May 11 17:45:08 2010 +0200 +++ b/packaging/common/rabbitmq-server.ocf Tue May 11 17:47:48 2010 +0200 @@ -259,12 +259,6 @@ rabbit_start() { local rc - rabbit_validate_full - rc=$? - if [ "$rc" != $OCF_SUCCESS ]; then - return $rc - fi - export_vars $RABBITMQ_MULTI start_all 1 > ${RABBITMQ_LOG_BASE}/startup_log 2> ${RABBITMQ_LOG_BASE}/startup_err & @@ -339,7 +333,11 @@ ;; esac -rabbit_validate_partial || exit +if ocf_is_probe; then + rabbit_validate_partial || exit +else + rabbit_validate_full || exit +fi case $__OCF_ACTION in start) From florian.haas at linbit.com Tue May 11 18:09:47 2010 From: florian.haas at linbit.com (Florian Haas) Date: Tue, 11 May 2010 19:09:47 +0200 Subject: [rabbitmq-discuss] [PATCH 10 of 10] OCF resource agent: replace "sleep 2" with "sleep 1" In-Reply-To: References: Message-ID: <67da08a10160c47a02ae.1273597787@gluehwein.linbit> # HG changeset patch # User Florian Haas # Date 1273594970 -7200 # Node ID 67da08a10160c47a02aee3e5119d631d1a6d107c # Parent d3688173161f9cbaf4010258ca3bce8d3fb7d5ec OCF resource agent: replace "sleep 2" with "sleep 1" We want to complete operations as quickly as possible, and whether we check the server's status every 2 seconds or every 1 second makes hardly any difference to Pacemaker. diff -r d3688173161f -r 67da08a10160 packaging/common/rabbitmq-server.ocf --- a/packaging/common/rabbitmq-server.ocf Tue May 11 18:20:52 2010 +0200 +++ b/packaging/common/rabbitmq-server.ocf Tue May 11 18:22:50 2010 +0200 @@ -290,7 +290,7 @@ ocf_log info "rabbitmq-server start failed: $rc" exit $OCF_ERR_GENERIC fi - sleep 2 + sleep 1 done return $OCF_SUCCESS @@ -325,7 +325,7 @@ ocf_log info "rabbitmq-server stop failed: $rc" exit $OCF_ERR_GENERIC fi - sleep 2 + sleep 1 done return $OCF_SUCCESS From matthew at lshift.net Tue May 11 19:01:17 2010 From: matthew at lshift.net (Matthew Sackman) Date: Tue, 11 May 2010 19:01:17 +0100 Subject: [rabbitmq-discuss] [PATCH 00 of 10] Several improvements to the OCF resource agent In-Reply-To: References: Message-ID: <20100511180116.GC11279@wellquite.org> Hi Florian, On Tue, May 11, 2010 at 07:09:37PM +0200, Florian Haas wrote: > I was only recently made aware of the existence of the rabbitmq-server > OCF resource agent (through the howto at > http://www.rabbitmq.com/pacemaker.html), had a quick look, and took the > liberty to fix a few simple issues. The individual patch descriptions > should be fairly self-explanatory (I hope) -- please do fire questions > back at me if I left anything unclear, or misunderstood some concept and > hence introduced something bogus. These are excellent, and I have no doubt they will likely all be accepted. As I'm sure you've been able to gather, some of the documentation and example scripts that I've read in order to be able to write the OCF script are out of date themselves, hence some of the issues you've spotted and corrected. Many thanks indeed for your patches, and I'll be in touch if anything else comes up (we /may/ need copyright assignment from you, not sure yet). Matthew From florian.haas at linbit.com Tue May 11 19:50:19 2010 From: florian.haas at linbit.com (Florian Haas) Date: Tue, 11 May 2010 20:50:19 +0200 Subject: [rabbitmq-discuss] [PATCH 00 of 10] Several improvements to the OCF resource agent In-Reply-To: <20100511180116.GC11279@wellquite.org> References: <20100511180116.GC11279@wellquite.org> Message-ID: <4BE9A6EB.3000908@linbit.com> On 05/11/2010 08:01 PM, Matthew Sackman wrote: > These are excellent, and I have no doubt they will likely all be > accepted. As I'm sure you've been able to gather, some of the > documentation and example scripts that I've read in order to be able to > write the OCF script are out of date themselves, hence some of the > issues you've spotted and corrected. Would you mind sharing exactly what documentation and example scripts you were following? We should get those fixed. > Many thanks indeed for your patches, and I'll be in touch if anything > else comes up (we /may/ need copyright assignment from you, not sure > yet). One other thing that came to mind while looking at the RA: the recommended minimum start timeout of 600s seems a bit excessive. Starting with Pacemaker 1.0.8 the crm shell will warn if the configuration provides for shorter timeouts than the RA recommends. Sure you need a 10-minute start timeout? Cheers, Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100511/8d5a14e6/attachment.pgp From johndapps at gmail.com Tue May 11 19:59:17 2010 From: johndapps at gmail.com (John Apps) Date: Tue, 11 May 2010 20:59:17 +0200 Subject: [rabbitmq-discuss] Fwd: Fwd: active/active In-Reply-To: References: <167204d21001171240j780c5f98oedace8539a884283@mail.gmail.com> <3b949f091001181707k15feadd5je82aae41dc60d0be@mail.gmail.com> Message-ID: Jason suggested I post my response to his note rather than a private reply to him. Well, it just so happens that that is what I intended, but managed to get the email addresses all mixed - again. It is my belief that the world does need truly durable/persistent/reliable messaging. It is also the case that there are many applications out there which use it even when they had no need originally. DECmessageQ (Oracle Message Queue these days) is an example in point. ---------- Forwarded message ---------- From: Jason J. W. Williams Date: Tue, May 11, 2010 at 20:46 Subject: Re: [rabbitmq-discuss] Fwd: active/active To: John Apps Hi John, It'd be great if you could share that with the list. Regarding duplication, I think that's easily addressed. If you're in a situation where the sender is going to re-send if they don't get confirmation it was accepted/processed on the other side, then you don't need durable messages. You're providing the durability. So the replay concept would only apply to durable messages and would allow all involved to make the assumption the message will eventually arrive and trust RabbitMQ to get it there...something that can't be assumed at the moment with clustering. -J On Tue, May 11, 2010 at 1:25 AM, John Apps wrote: > Option 1 below is neat and something that a product called Reliable > Transaction Router (RTR) has offered for many years with considerable > success. So, what, you might ask, has that to do with RabbitMQ? Well, quite > simply, only to show that the concept is a viable one and has been used in > practice for many years. > One of the caveats with it is when the queues are feeding into two > databases, one a copy of the other; no, not mirrored in the classic sense, > rather, the messages are sent to both. The thing to take care of here is > that when messages are being replayed, i.e., one server has been down and > comes back up, whereupon the other server then plays the missed messages to > it, is that the DB on the server processing the messages MUST not have been > changed whilst the server was down. > What would be 'nice to have' in this scenario is a flag stating that the > messages are being re-played. This helps to avoid the problem of possible > duplicate messages by making one aware of the fact that a re-play is in > progress. > With the purchase of GemStone, perhaps the folks at RabbitMQ can use some of > the distributed messaging technology from that product suite? > > On Tue, May 11, 2010 at 00:43, Jason J. W. Williams > wrote: >> >> It was suggested to me I relay a convo I had with Alexis earlier this >> year making the case for better active/active fail-over in RabbitMQ. >> Particularly, when working with durable messaging. >> >> >> ---------- Forwarded message ---------- >> From: Jason J. W. Williams >> Date: Mon, Jan 18, 2010 at 7:07 PM >> Subject: Re: active/active >> To: Alexis Richardson >> >> >> Hey Alexis, >> >> Currently, we have a single RMQ 1.5 pair that are setup >> active/passive. That is to say, our apps publish to node A and if it >> is unavailable publish to node B. Nodes A and B are standalone in that >> they are not in a cluster together. This is because the messages being >> published are durable, and in the event node A crashes any pending >> durable messages would not be auto-resubmitted if node A were >> clustered with node B (node B's queue essentially hides the pendings >> that were in the queue on node A before the crash). >> >> This set up works OK for us, as the load is fairly light and >> durability is more important for these tasks than availability. >> >> That being said we are designing a rework of our statistics logging >> infrastructure around Rabbit. Our stats is very high volume and >> availability is more important than durability (in fact none of the >> messages will be durable). So our intention is to create a new Rabbit >> cluster with three nodes and a load-balanced IP in front (since >> auto-redirect based on load is no longer supported....nasty memo to >> follow... ;) ). >> >> Our desire due to the fact that we're moving from a colo'd environment >> to a cloud environment, is to collapse both Rabbit "clusters" >> into a single cluster to maximize efficiency. It would also allow our >> existing app to benefit from the performance of a load-sharing >> environment. For that to happen however, Rabbit would have to do one >> of two things when clustered regarding durable messages: >> >> 1.) When a crashed node is restarted, replay the pending/durable >> messages into the queue on the node now responsible for the queue >> after the crash. >> 2.) Replicate all durable queues to more than one node, so that >> durable queue contents continue after a node crash. >> >> Frankly, option 1 is just fine with us and would solve our issue. >> >> Does this help? Thank you for being concerned. >> >> -J >> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > > > -- > --- > John Apps > (49) 171 869 1813 > -- --- John Apps (49) 171 869 1813 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100511/551af758/attachment.htm From matthew at lshift.net Tue May 11 20:04:45 2010 From: matthew at lshift.net (Matthew Sackman) Date: Tue, 11 May 2010 20:04:45 +0100 Subject: [rabbitmq-discuss] [PATCH 00 of 10] Several improvements to the OCF resource agent In-Reply-To: <4BE9A6EB.3000908@linbit.com> References: <20100511180116.GC11279@wellquite.org> <4BE9A6EB.3000908@linbit.com> Message-ID: <20100511190445.GA20197@wellquite.org> On Tue, May 11, 2010 at 08:50:19PM +0200, Florian Haas wrote: > On 05/11/2010 08:01 PM, Matthew Sackman wrote: > > These are excellent, and I have no doubt they will likely all be > > accepted. As I'm sure you've been able to gather, some of the > > documentation and example scripts that I've read in order to be able to > > write the OCF script are out of date themselves, hence some of the > > issues you've spotted and corrected. > > Would you mind sharing exactly what documentation and example scripts > you were following? We should get those fixed. Sure, a lot of it was just done from reading other OCF scripts, such as the DRBD, IPAddr and such like. But I think I got the most out of the docs at http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ap-ocf.html For example, that only talks of the monitor action, not status, and no where that I found is there any real documentation as to what the library of functions that is supplied with pacemaker do, nor how or when they should be used (eg the ocf_is_probe function you've used). > One other thing that came to mind while looking at the RA: the > recommended minimum start timeout of 600s seems a bit excessive. > Starting with Pacemaker 1.0.8 the crm shell will warn if the > configuration provides for shorter timeouts than the RA recommends. Sure > you need a 10-minute start timeout? Currently, startup time can be very long if you have an awful lot of data to recover from disk. We think this might be partially fixed very soon as some work that's recently been done will all Rabbit to come up even before all recovery is complete (only the queues still being recovered will continue to be unavailable). However, even in this case, there are still some internal resources that must be fully recovered before Rabbit can be in any way considered to be up, and that can be proportional to the amount of data it has previously stored on disk. Thus, in conclusion, yes, 10 mins may be far too long. But in some cases it may also be too short. Any advice you have as to what we should be doing wrt the OCF script would be gratefully received. Matthew From jon.brisbin at npcinternational.com Tue May 11 20:10:23 2010 From: jon.brisbin at npcinternational.com (Jon Brisbin) Date: Tue, 11 May 2010 14:10:23 -0500 Subject: [rabbitmq-discuss] Caching proxy for cloud HA Message-ID: I'm banging around an idea for an HA load-balancer because, frankly, Apache sucks at being a dynamic, cloud-friendly Proxy for application servers. I can't find anything else that will work for me, so I'm yet again going to try and write the basics of what I need myself. I'm going to run Apache servers on non-standard ports for the PHP apps we have, and proxy those just like I will my application servers. I'm thinking I can also proxy my RabbitMQ servers for HA as well. My proxies would be immediately responsive to changes in my cloud services, so servers will drop off and join the cloud at unknown intervals. I'm thinking I could have my RMQ clients connect to the HA proxy, which load-balances requests to the configured back-end servers. I could easily introduce caching here because the proxy is transparent. The client has no idea it's not actually talking to the real RMQ server. I could duplicate data coming in to multiple back-end servers or I could do round-robin or somesuch. I'm wondering what happens to a client's subscriptions if a back-end RMQ server goes down? If I'm replicating the incoming bytes to more than one server at a time, then I'd get some failover, right? Could my proxy tell what the client is asking to do and route the data differently depending on whether the requests were subscriptions or declares (versus publishes, etc...). The proxy could de-dup using a simple one-way "valve" (like a countdown latch in Java). Jon Brisbin Portal Webmaster NPC International, Inc. From florian.haas at linbit.com Tue May 11 20:26:00 2010 From: florian.haas at linbit.com (Florian Haas) Date: Tue, 11 May 2010 21:26:00 +0200 Subject: [rabbitmq-discuss] [PATCH 00 of 10] Several improvements to the OCF resource agent In-Reply-To: <20100511190445.GA20197@wellquite.org> References: <20100511180116.GC11279@wellquite.org> <4BE9A6EB.3000908@linbit.com> <20100511190445.GA20197@wellquite.org> Message-ID: <4BE9AF48.60002@linbit.com> On 05/11/2010 09:04 PM, Matthew Sackman wrote: > On Tue, May 11, 2010 at 08:50:19PM +0200, Florian Haas wrote: >> On 05/11/2010 08:01 PM, Matthew Sackman wrote: >>> These are excellent, and I have no doubt they will likely all be >>> accepted. As I'm sure you've been able to gather, some of the >>> documentation and example scripts that I've read in order to be able to >>> write the OCF script are out of date themselves, hence some of the >>> issues you've spotted and corrected. >> >> Would you mind sharing exactly what documentation and example scripts >> you were following? We should get those fixed. > > Sure, a lot of it was just done from reading other OCF scripts, such as > the DRBD, IPAddr and such like. But I think I got the most out of the > docs at > http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ap-ocf.html > > For example, that only talks of the monitor action, not status, and no > where that I found is there any real documentation as to what the > library of functions that is supplied with pacemaker do, nor how or when > they should be used (eg the ocf_is_probe function you've used). Those are not part of Pacemaker, they ship with the Linux-HA resource agents package. The relevant functions library is in $OCF_ROOT/resource.d/heartbeat/.ocf-shellfuncs. >> One other thing that came to mind while looking at the RA: the >> recommended minimum start timeout of 600s seems a bit excessive. >> Starting with Pacemaker 1.0.8 the crm shell will warn if the >> configuration provides for shorter timeouts than the RA recommends. Sure >> you need a 10-minute start timeout? > > Currently, startup time can be very long if you have an awful lot of > data to recover from disk. We think this might be partially fixed very > soon as some work that's recently been done will all Rabbit to come up > even before all recovery is complete (only the queues still being > recovered will continue to be unavailable). However, even in this case, > there are still some internal resources that must be fully recovered > before Rabbit can be in any way considered to be up, and that can be > proportional to the amount of data it has previously stored on disk. > > Thus, in conclusion, yes, 10 mins may be far too long. But in some cases > it may also be too short. Any advice you have as to what we should be > doing wrt the OCF script would be gratefully received. There's a misconception in play here, I'm afraid. What you define as the timeout in the RA metadata is just a recommendation for the minimum timeout the cluster administrator should configure. It doesn't actually set or enforce that timeout, it merely recommends one to be set. Long story short: you don't want to set this piece of metadata to the maximum time you'd expect startup to take, but the time that most real-word configurations will take to start, plus some 20-30% extra. MySQL (with InnoDB recovery) has much similar issues when failing over hard on DRBD or shared storage. The recommended minimum start timeout there is 120s. Cheers, Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100511/f20ec55c/attachment.pgp From shane at digitalsanctum.com Tue May 11 22:50:43 2010 From: shane at digitalsanctum.com (Shane) Date: Tue, 11 May 2010 14:50:43 -0700 (PDT) Subject: [rabbitmq-discuss] getting started In-Reply-To: References: <5a5b6326-7eb8-4eb8-be39-c921f1f59a14@k29g2000yqh.googlegroups.com> <4BE92362.3070507@lshift.net> Message-ID: <1ea411ac-c8f5-4587-ab92-46f910f94aee@d27g2000yqc.googlegroups.com> Thanks to everyone that responded. The issue was apparently my iptables rules which were FUBAR (still trying to determine the rules that are at fault). I flushed all rules and voila! I was able to connect to the broker. On May 11, 9:16?am, Davorin Rusevljan wrote: > On Tue, May 11, 2010 at 3:02 PM, Shane wrote: > > Thanks for the responses so far although I haven't found the cause of > > the issue yet. I've verified that iptables has port 5672 open and I > > checked the the rabbitmq log and there doesn't appear to be an issue > > and indicates it starts a listener on 0.0.0.0:5672. I'm not behind a > > corporate firewall so that's moot here. The broker install is the out- > > of-the-box config so I have the defaults set for everything including > > the user/pass (I intend on changing this after I get the initial setup > > working). > > > Any other ideas? > > try to open port 5672 on the server from your local machine, with some other > program, telnet perhaps. > > rushhttp://www.cloud208.com/ > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-disc... at lists.rabbitmq.comhttp://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > -- > You received this message because you are subscribed to the Google Groups "rabbitmq-discuss" group. > To post to this group, send email to rabbitmq-discuss at googlegroups.com. > To unsubscribe from this group, send email to rabbitmq-discuss+unsubscribe at googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rabbitmq-discuss?hl=en. From akalend at mail.ru Wed May 12 01:05:03 2010 From: akalend at mail.ru (Alexandre Kalendarev) Date: Wed, 12 May 2010 04:05:03 +0400 Subject: [rabbitmq-discuss] the amqp-rest project Message-ID: Hi all, I create the HTTP amqp-rest service for WEB/AJAX exchange. The amqp-rest is hi-perfomance (more 1300 rps) light (600K) HTTP server based libevent, realise two methods: - HTTP GET - the reading from queue one item by BASIC.GET AMQP method - HTTP POST - publish to exchange by BASIC.PUBLISH AMQP method the result from HTTP server return by json. I think, it will usefull for WEB development. if need, I can realise the any amqp methods, but I think that create/delete and bind must be doing only backend. Any ideas as big plus to project. From alexis at rabbitmq.com Wed May 12 01:07:11 2010 From: alexis at rabbitmq.com (Alexis Richardson) Date: Wed, 12 May 2010 01:07:11 +0100 Subject: [rabbitmq-discuss] the amqp-rest project In-Reply-To: References: Message-ID: Alexandre Very cool. Could you post the code on Github perhaps? alexis On Wed, May 12, 2010 at 1:05 AM, Alexandre Kalendarev wrote: > Hi all, > > I create the HTTP amqp-rest service for WEB/AJAX exchange. > The amqp-rest is hi-perfomance ?(more 1300 rps) ?light (600K) HTTP server based libevent, realise two methods: > ?- HTTP GET - the reading from queue one item by BASIC.GET AMQP method > ?- HTTP POST - publish to exchange by BASIC.PUBLISH AMQP method > > the result from HTTP server return by json. > I think, it will usefull for WEB development. > > if need, I can realise the any amqp methods, but I think that create/delete and bind must be doing only backend. > > Any ideas as big plus to project. > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > From RadhakrishnanD at ivycomptech.com Wed May 12 05:12:00 2010 From: RadhakrishnanD at ivycomptech.com (Radha Krishnan D) Date: Wed, 12 May 2010 09:42:00 +0530 Subject: [rabbitmq-discuss] RabbitMQ config file. In-Reply-To: <49A7BA114AAC6A48B9C44CB06B7B987E06445F38@HYDSVWIN004X.ivycomptech.partygaming.local> References: <49A7BA114AAC6A48B9C44CB06B7B987E06445F38@HYDSVWIN004X.ivycomptech.partygaming.local> Message-ID: <49A7BA114AAC6A48B9C44CB06B7B987E0A211B97@HYDSVWIN004X.ivycomptech.partygaming.local> Hi alex, That problem is solved now. [ {mnesia, [{dump_log_write_threshold, 1000}]}, {rabbit, [{vm_memory_high_watermark, 2.0}]} ] . This is our config file. The problem was that we did not add the . (dot) at the end of the config file. Now I sent 80000 messages of size 1933 bytes from producer to the broker. The consumer receives 76000 at one run , 68000 at another run. There is a drop of messages. We are using amq.topic mode. Please help us how to solve the message dropping problem. Thanks and Regards, D.Radhakrishnan Trainee Engineer-Architecture IVY Comptech Private Limited Cyber Spazio,Road No 2, Banjara Hills, Hyderabad-500034, Andhra Pradesh. Phone + 91 (40) 66721000 - 4638 Mobile + 91 (0) 9030842104 This email and any attachments are confidential, legally privileged and protected by copyright. If you are not the intended recipient, dissemination or copying this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorized. Any actions taken on the basis of this email are at recipient's own risk. -----Original Message----- From: Radha Krishnan D Sent: Tuesday, May 11, 2010 7:38 PM To: 'Alexis Richardson' Cc: 'rabbitmq info'; 'RabbitMQ Discuss' Subject: RE: [rabbitmq-discuss] RabbitMQ config file. Hi alex, We are now trying to sent messages from one producer to the exchange and a consumer takes that message from the queue binded to that exchange. In the producer side : ------------------------- 10 threads send messages continuosly In the receiver side ---------------------- One thread receives all messages. we used the default configuration of rabbitmq-server and start the test. In the logs it has printed saying 1638MB of memory is used. After some time, the server runs out of memory and says Erlang has closed. We don t know how to increase the size from 1638 MB. we tried defining a new config file but the rabbitmq server is not recognizing it even though we specified the path in the rabbitmq-server file. Thanks and Regards, D.Radhakrishnan Trainee Engineer-Architecture IVY Comptech Private Limited Cyber Spazio,Road No 2, Banjara Hills, Hyderabad-500034, Andhra Pradesh. Phone + 91 (40) 66721000 - 4638 Mobile + 91 (0) 9030842104 This email and any attachments are confidential, legally privileged and protected by copyright. If you are not the intended recipient, dissemination or copying this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorized. Any actions taken on the basis of this email are at recipient's own risk. -----Original Message----- From: alexis.richardson at gmail.com [mailto:alexis.richardson at gmail.com] On Behalf Of Alexis Richardson Sent: Tuesday, May 11, 2010 7:32 PM To: Radha Krishnan D Cc: rabbitmq info; RabbitMQ Discuss Subject: Re: [rabbitmq-discuss] RabbitMQ config file. Radha Please could you tell us a bit more about your use cases? Best wishes alexis On Tue, May 11, 2010 at 7:35 AM, Radha Krishnan D wrote: > Hi, > > > > ??????????? We are evaluating rabbitMQ's performance for our use cases. We > are using rabbitmq-server-1.7.2? ( downloaded under the heading generic > Linux ). Since our linux machine RAM is 8 GB and it is a 32 bit machine. > RabbitMQ takes 1638 MB and it prints it in the logs. How ever when I want to > increase the size by using?? {rabbit, [{vm_memory_high_watermark,? 2.0}]} > the rabbitMQ server is not recognizing this configuration change ?at all. > > > > I did a change in the rabbitmq-server file pointing > CONFIG_FILE=/home/ppoker/MessagingPOC/RabbitMQ/rabbitmq???? rabbitmq.config > is my file name. > > > > Earlier, in the default run. You have mentioned that the default config file > for generic unix will be in /etc/rabbitmq/rabbitmq.config. I did not get > this file there. > > > > Where am I going wrong ? > > Please suggest me a solution and a sample copy of the rabbitmq.config file. > > Also please clear us about the difference between rabbitmq.conf file and > rabbitmq.config file. > > > > > > Thanks and Regards, > > D.Radhakrishnan > Trainee?Engineer-Architecture > > IVY Comptech Private Limited > Cyber Spazio,Road No 2, Banjara Hills, > Hyderabad-500034, Andhra Pradesh. > > Phone + 91 (40) 66721000 - 4638 > Mobile + 91 (0) 9030842104 > > This email and any attachments are confidential, legally privileged and > protected by copyright. If you are not the intended recipient, dissemination > or copying this email is prohibited. If you have received this in error, > please notify the sender by replying by email and then delete the email > completely from your system. > > Any views or opinions are solely those of? the sender. This communication is > not intended to form a binding contract unless expressly indicated to the > contrary and properly authorized. Any actions taken on the basis of this > email are at recipient's own risk. > > > > ________________________________ > > This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy > Comptech Private Limited is a limited liability company. > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended recipient > dissemination or copying of this email is prohibited. If you have received > this in error, please notify the sender by replying by email and then delete > the email completely from your system. Any views or opinions are solely > those of the sender.? This communication is not intended to form a binding > contract on behalf of Ivy Comptech Private Limited unless expressly > indicated to the contrary and properly authorised. Any actions taken on the > basis of this email are at the recipient's own risk. > > Registered?Office: > > Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, > Hyderabad 500 033, Andhra Pradesh, India. > > Registered number: 37994. Registered in India. A list of members' names is > available for inspection at the registered office. > > ________________________________ > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy Comptech Private Limited is a limited liability company. This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract on behalf of Ivy Comptech Private Limited unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. Registered office: Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, Hyderabad 500 033, Andhra Pradesh, India. Registered number: 37994. Registered in India. A list of members' names is available for inspection at the registered office. From lists at zopyx.com Wed May 12 06:21:24 2010 From: lists at zopyx.com (Andreas Jung) Date: Wed, 12 May 2010 07:21:24 +0200 Subject: [rabbitmq-discuss] [Alice] Proper configuration Message-ID: <4BEA3AD4.8080805@zopyx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, trying to get Alice http://willcodeforfoo.com/2009/07/13/announcing-alice/ running with RabbitMQ. RabbitMQ is running: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvqOtQACgkQCJIWIbr9KYzalACgnotSHCrOJK2LRqEsnXk3tefm tHMAn0cwwQgbhqJmKXRuVD/dLZAzhKaR =R6Ce -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: lists.vcf Type: text/x-vcard Size: 316 bytes Desc: not available Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100512/002faadd/attachment-0001.vcf From lists at zopyx.com Wed May 12 06:23:46 2010 From: lists at zopyx.com (Andreas Jung) Date: Wed, 12 May 2010 07:23:46 +0200 Subject: [rabbitmq-discuss] [Alice] Proper configuration? Message-ID: <4BEA3B62.3040005@zopyx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, trying to get Alice http://willcodeforfoo.com/2009/07/13/announcing-alice/ running with RabbitMQ. RabbitMQ is running: ajung at blackmoon:~/sandboxes/occ> bin/rabbitmqctl status Status of node rabbit at blackmoon ... [{running_applications,[{rabbit,"RabbitMQ","1.7.2"}, {mnesia,"MNESIA CXC 138 12","4.4.10"}, {os_mon,"CPO CXC 138 46","2.2.2"}, {sasl,"SASL CXC 138 11","2.1.6"}, {stdlib,"ERTS CXC 138 10","1.16.2"}, {kernel,"ERTS CXC 138 10","2.13.2"}]}, {nodes,[rabbit at blackmoon]}, {running_nodes,[rabbit at blackmoon]}] ...done. Starting Alice fails: ajung at blackmoon:~/sandboxes/occ/alice> sh start.sh make[1]: Entering directory `/data/develop/sandboxes/occ/alice/deps/mochiweb' (cd src;make all) make[2]: Entering directory `/data/develop/sandboxes/occ/alice/deps/mochiweb/src' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/data/develop/sandboxes/occ/alice/deps/mochiweb/src' make[1]: Leaving directory `/data/develop/sandboxes/occ/alice/deps/mochiweb' (cd ebin; erl -pa deps/mochiweb/ebin -pa ebin -noshell -run make_boot write_scripts alice) write_scripts for "alice" Writing to "alice.rel" (as alice) *WARNING* alice: Source code not found: alice_app.erl *WARNING* alice: Source code not found: alice_log.erl *WARNING* alice: Source code not found: rest_app.erl {error_logger,{{2010,5,12},{7,23,7}},"Protocol: ~p: register error: ~p~n",["inet_tcp",{{badmatch,{error,duplicate_name}},[{inet_tcp_dist,listen,1},{net_kernel,start_protos,4},{net_kernel,start_protos,3},{net_kernel,init_node,2},{net_kernel,init,1},{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}]} {error_logger,{{2010,5,12},{7,23,7}},crash_report,[[{initial_call,{net_kernel,init,['Argument__1']}},{pid,<0.21.0>},{registered_name,[]},{error_info,{exit,{error,badarg},[{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}},{ancestors,[net_sup,kernel_sup,<0.8.0>]},{messages,[]},{links,[#Port<0.120>,<0.18.0>]},{dictionary,[{longnames,true}]},{trap_exit,true},{status,running},{heap_size,610},{stack_size,24},{reductions,459}],[]]} {error_logger,{{2010,5,12},{7,23,7}},supervisor_report,[{supervisor,{local,net_sup}},{errorContext,start_error},{reason,{'EXIT',nodistribution}},{offender,[{pid,undefined},{name,net_kernel},{mfa,{net_kernel,start_link,[[alice,longnames]]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]}]} {error_logger,{{2010,5,12},{7,23,7}},supervisor_report,[{supervisor,{local,kernel_sup}},{errorContext,start_error},{reason,shutdown},{offender,[{pid,undefined},{name,net_sup},{mfa,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]}]} {error_logger,{{2010,5,12},{7,23,7}},std_info,[{application,kernel},{exited,{shutdown,{kernel,start,[normal,[]]}}},{type,permanent}]} {"Kernel pid terminated",application_controller,"{application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}"} Crash dump was written to: erl_crash.dump Kernel pid terminated (application_controller) ({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}) Anything I am missing? Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvqO2IACgkQCJIWIbr9KYyw9ACfWZf1E0pnCeoyLl7VCqhKIAQX +2gAn2ZNEeR7H8XGMFOymyM41VsFnTVL =OC0A -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: lists.vcf Type: text/x-vcard Size: 316 bytes Desc: not available Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100512/d55f05d4/attachment.vcf From matthias at rabbitmq.com Wed May 12 09:23:31 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Wed, 12 May 2010 09:23:31 +0100 Subject: [rabbitmq-discuss] rabbitmq-mochiweb In-Reply-To: References: Message-ID: <4BEA6583.50800@rabbitmq.com> Benjamin, Benjamin Polidore wrote: > hey, i can't seem to get past this. i'm probably doing something > silly, but i keep getting: > > {"version":"1.1","id":null,"error":{"name":"JSONRPCError","code":404,"message":"Procedure > not found","error":["http://h5pro.local:55672/rpc/rabbitmq",""]}} > > when i run the test.js from my mac's apache server. Did you figure out what the problem was? If not, could you perhaps try to get this working on some other machine? Preferably one to which you can grant one of the rabbit team access if things still go wrong. Regards, Matthias. From videlalvaro at gmail.com Wed May 12 10:08:22 2010 From: videlalvaro at gmail.com (Alvaro Videla) Date: Wed, 12 May 2010 17:08:22 +0800 Subject: [rabbitmq-discuss] Meeting in London Message-ID: <041EFDD7-CA57-4E35-B321-CD88CD67FBC7@gmail.com> Hi guys/gals, I'll asked Alexis about this and he told me to ask here: I'll be in London next June for the Erlang Factory. Since I'm traveling from China and I won't be going there any time like every week :) I would like to meet with some of the RabbitMQ guys in London, can we arrange something? Perhaps going to a pub or something? Regards, Alvaro From matthias at rabbitmq.com Wed May 12 10:18:18 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Wed, 12 May 2010 10:18:18 +0100 Subject: [rabbitmq-discuss] high number of unack'ed messages when queue grows large In-Reply-To: References: <20100507134921.GB9487@mrnibble.lshift.net> <20100507140502.GD9487@mrnibble.lshift.net> Message-ID: <4BEA725A.2070807@rabbitmq.com> mmenti at gmail.com wrote: > On Fri, May 7, 2010 at 3:05 PM, Matthew Sackman > wrote: > > On Fri, May 07, 2010 at 02:59:26PM +0100, mmenti at gmail.com > wrote: > > Strangely we already have prefetch set to 1 on the consumers, and > still see > > this issue. > > That's bizarre. Are you doing some gets as well? They're not counted in > the qos setting. Also, which client are you using? > > > We're using MQ, from the tmm1-amqp gem, and no, not doing any gets.. Can you send us the consumer code? Alternatively, please connect one consumer via the tracer (http://www.rabbitmq.com/examples.html#tracer) - preferably when there are only a few messages in the queue - and send us the output. Regards, Matthias. From matthias at rabbitmq.com Wed May 12 11:11:32 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Wed, 12 May 2010 11:11:32 +0100 Subject: [rabbitmq-discuss] Firewall Issues In-Reply-To: <4BE93A0A.1060408@loafman.com> References: <4BE812AE.2020403@loafman.com> <4BE81674.102@loafman.com> <4BE8183A.1030504@loafman.com> <4BE819A9.4050707@loafman.com> <4BE92068.9040706@lshift.net> <4BE93A0A.1060408@loafman.com> Message-ID: <4BEA7ED4.6070401@rabbitmq.com> Kenneth, Kenneth Loafman wrote: > P1 and P2 both connect to MQ, there are no connections from MQ to Px. > MQ collects data from the web and queues it to the Px instances. We're > using Python Carrot for access, which is based on amqplib. > > Most of the data flows from MQ to Px, however some status and alert data > flows from Px to MQ for queuing to other processes. When you attempt to connect from P2, does the connection show up in the rabbit.log? There should be messages like INFO REPORT==== 10-May-2010::18:27:25 === accepted TCP connection on 0.0.0.0:5672 from :38557 =INFO REPORT==== 10-May-2010::18:27:25 === starting TCP connection <0.13252.0> from :38557 Does connecting to port 5672 on MQ from Px using something like 'telnet' work? Regards, Matthias. From alexis at rabbitmq.com Wed May 12 11:58:32 2010 From: alexis at rabbitmq.com (Alexis Richardson) Date: Wed, 12 May 2010 11:58:32 +0100 Subject: [rabbitmq-discuss] Meeting in London In-Reply-To: <041EFDD7-CA57-4E35-B321-CD88CD67FBC7@gmail.com> References: <041EFDD7-CA57-4E35-B321-CD88CD67FBC7@gmail.com> Message-ID: Alvaro That sounds like an excellent plan. Perhaps it's time for another 'pubsub' meet-up? If it is the week of the EF then we can invite a lot of 'NoSQL' folks along too... alexis On Wed, May 12, 2010 at 10:08 AM, Alvaro Videla wrote: > Hi guys/gals, > > I'll asked Alexis about this and he told me to ask here: > > I'll be in London next June for the Erlang Factory. Since I'm traveling from China and I won't be going there any time like every week :) I would like to meet with some of the RabbitMQ guys in London, can we arrange something? > > Perhaps going to a pub or something? > > Regards, > > Alvaro > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > From videlalvaro at gmail.com Wed May 12 12:00:06 2010 From: videlalvaro at gmail.com (Alvaro Videla) Date: Wed, 12 May 2010 19:00:06 +0800 Subject: [rabbitmq-discuss] Meeting in London In-Reply-To: References: <041EFDD7-CA57-4E35-B321-CD88CD67FBC7@gmail.com> Message-ID: <70EA4610-9E8F-434B-ADD9-F49A4947610C@gmail.com> I'll be in London from June 9th till June 14th. EF conference is 10th and 11th. So can we find something those days? -Alvaro On May 12, 2010, at 6:58 PM, Alexis Richardson wrote: > Alvaro > > That sounds like an excellent plan. Perhaps it's time for another > 'pubsub' meet-up? If it is the week of the EF then we can invite a > lot of 'NoSQL' folks along too... > > alexis > > > On Wed, May 12, 2010 at 10:08 AM, Alvaro Videla wrote: >> Hi guys/gals, >> >> I'll asked Alexis about this and he told me to ask here: >> >> I'll be in London next June for the Erlang Factory. Since I'm traveling from China and I won't be going there any time like every week :) I would like to meet with some of the RabbitMQ guys in London, can we arrange something? >> >> Perhaps going to a pub or something? >> >> Regards, >> >> Alvaro >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> From alexis at rabbitmq.com Wed May 12 12:09:45 2010 From: alexis at rabbitmq.com (Alexis Richardson) Date: Wed, 12 May 2010 12:09:45 +0100 Subject: [rabbitmq-discuss] Meeting in London In-Reply-To: References: <041EFDD7-CA57-4E35-B321-CD88CD67FBC7@gmail.com> Message-ID: On Wed, May 12, 2010 at 12:05 PM, James Governor wrote: > Pub sub. Lets pick it up. Les plans diaboliques. Merveilleux. > When in june? Do as the junians do? I suggest Wednesday June 9th. alexis > > > -----Original Message----- > From: alexis.richardson at gmail.com [mailto:alexis.richardson at gmail.com] On > Behalf Of Alexis Richardson > Sent: 12 May 2010 11:59 > To: Alvaro Videla > Cc: rabbitmq-discuss; James Governor; Jonathan Lister > Subject: Re: [rabbitmq-discuss] Meeting in London > > Alvaro > > That sounds like an excellent plan. ?Perhaps it's time for another > 'pubsub' meet-up? ?If it is the week of the EF then we can invite a > lot of 'NoSQL' folks along too... > > alexis > > > On Wed, May 12, 2010 at 10:08 AM, Alvaro Videla > wrote: >> Hi guys/gals, >> >> I'll asked Alexis about this and he told me to ask here: >> >> I'll be in London next June for the Erlang Factory. Since I'm traveling > from China and I won't be going there any time like every week :) I would > like to meet with some of the RabbitMQ guys in London, can we arrange > something? >> >> Perhaps going to a pub or something? >> >> Regards, >> >> Alvaro >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> > From videlalvaro at gmail.com Wed May 12 12:22:58 2010 From: videlalvaro at gmail.com (Alvaro Videla) Date: Wed, 12 May 2010 19:22:58 +0800 Subject: [rabbitmq-discuss] Meeting in London In-Reply-To: References: <041EFDD7-CA57-4E35-B321-CD88CD67FBC7@gmail.com> Message-ID: <97CFF954-18B9-43F1-B481-FBA8FEC72A72@gmail.com> That's OK for me, since I'll be arriving in the morning On May 12, 2010, at 7:09 PM, Alexis Richardson wrote: > On Wed, May 12, 2010 at 12:05 PM, James Governor wrote: >> Pub sub. Lets pick it up. Les plans diaboliques. > > Merveilleux. > > > > >> When in june? > > Do as the junians do? > > I suggest Wednesday June 9th. > > alexis > > >> >> >> -----Original Message----- >> From: alexis.richardson at gmail.com [mailto:alexis.richardson at gmail.com] On >> Behalf Of Alexis Richardson >> Sent: 12 May 2010 11:59 >> To: Alvaro Videla >> Cc: rabbitmq-discuss; James Governor; Jonathan Lister >> Subject: Re: [rabbitmq-discuss] Meeting in London >> >> Alvaro >> >> That sounds like an excellent plan. Perhaps it's time for another >> 'pubsub' meet-up? If it is the week of the EF then we can invite a >> lot of 'NoSQL' folks along too... >> >> alexis >> >> >> On Wed, May 12, 2010 at 10:08 AM, Alvaro Videla >> wrote: >>> Hi guys/gals, >>> >>> I'll asked Alexis about this and he told me to ask here: >>> >>> I'll be in London next June for the Erlang Factory. Since I'm traveling >> from China and I won't be going there any time like every week :) I would >> like to meet with some of the RabbitMQ guys in London, can we arrange >> something? >>> >>> Perhaps going to a pub or something? >>> >>> Regards, >>> >>> Alvaro >>> _______________________________________________ >>> rabbitmq-discuss mailing list >>> rabbitmq-discuss at lists.rabbitmq.com >>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>> >> From jvaughn at criticalmention.com Wed May 12 13:21:56 2010 From: jvaughn at criticalmention.com (James Vaughn) Date: Wed, 12 May 2010 08:21:56 -0400 Subject: [rabbitmq-discuss] Fwd: Lessons From Reddit Fail: Cassandra and RabbitMQ In-Reply-To: References: Message-ID: Article a coworker sent me, primarily about problems with Cassandra but there are some gripes about RabbitMQ about halfway through under the "she must have been pregnant" heading. http://blog.reddit.com/2010/05/reddits-may-2010-state-of-servers.html From videlalvaro at gmail.com Wed May 12 13:24:09 2010 From: videlalvaro at gmail.com (Alvaro Videla) Date: Wed, 12 May 2010 20:24:09 +0800 Subject: [rabbitmq-discuss] Fwd: Lessons From Reddit Fail: Cassandra and RabbitMQ In-Reply-To: References: Message-ID: <1F64B312-6097-4E1D-B27B-F20A0183AD9C@gmail.com> Take a look at this couple of comments, from the same article: http://www.reddit.com/r/announcements/comments/c2spc/reddits_may_2010_state_of_the_servers_report_or/c0ptv2x?context=3 Regards, Alvaro On May 12, 2010, at 8:21 PM, James Vaughn wrote: > Article a coworker sent me, primarily about problems with Cassandra > but there are some gripes about RabbitMQ about halfway through under > the "she must have been pregnant" heading. > > http://blog.reddit.com/2010/05/reddits-may-2010-state-of-servers.html > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From lists at zopyx.com Wed May 12 14:34:05 2010 From: lists at zopyx.com (Andreas Jung) Date: Wed, 12 May 2010 15:34:05 +0200 Subject: [rabbitmq-discuss] New persister Message-ID: <4BEAAE4D.1040301@zopyx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reading about the "new persister"...is it part of RabbitMQ 1.7.2 or available through some nightly build? Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvqrkwACgkQCJIWIbr9KYwbygCfbAwMiPaDBygVItciHJJgcE5P j1oAoKFRHZR+VE3ucszkMgduSEBxB3Ac =1Oqa -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: lists.vcf Type: text/x-vcard Size: 316 bytes Desc: not available Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100512/67b9cf2d/attachment.vcf From kenneth at loafman.com Wed May 12 14:56:41 2010 From: kenneth at loafman.com (Kenneth Loafman) Date: Wed, 12 May 2010 08:56:41 -0500 Subject: [rabbitmq-discuss] Firewall Issues In-Reply-To: <4BEA7ED4.6070401@rabbitmq.com> References: <4BE812AE.2020403@loafman.com> <4BE81674.102@loafman.com> <4BE8183A.1030504@loafman.com> <4BE819A9.4050707@loafman.com> <4BE92068.9040706@lshift.net> <4BE93A0A.1060408@loafman.com> <4BEA7ED4.6070401@rabbitmq.com> Message-ID: <4BEAB399.3010701@loafman.com> Matthias Radestock wrote: > Kenneth, > > Kenneth Loafman wrote: >> P1 and P2 both connect to MQ, there are no connections from MQ to Px. >> MQ collects data from the web and queues it to the Px instances. We're >> using Python Carrot for access, which is based on amqplib. >> >> Most of the data flows from MQ to Px, however some status and alert data >> flows from Px to MQ for queuing to other processes. > > When you attempt to connect from P2, does the connection show up in the > rabbit.log? There should be messages like > > INFO REPORT==== 10-May-2010::18:27:25 === > accepted TCP connection on 0.0.0.0:5672 from :38557 > > =INFO REPORT==== 10-May-2010::18:27:25 === > starting TCP connection <0.13252.0> from :38557 > > > Does connecting to port 5672 on MQ from Px using something like 'telnet' > work? Got it fixed, and it was a firewall problem on my end. P2, the system that was unable to connect, did not have the same access rules as P1. And yes, the only port I needed to have open was 5672. ...Thanks, ...Ken From alexis at rabbitmq.com Wed May 12 14:58:27 2010 From: alexis at rabbitmq.com (Alexis Richardson) Date: Wed, 12 May 2010 14:58:27 +0100 Subject: [rabbitmq-discuss] New persister In-Reply-To: <4BEAAE4D.1040301@zopyx.com> References: <4BEAAE4D.1040301@zopyx.com> Message-ID: Andreas It is not in 1.7.2 but it is targetted for an upcoming release. It's in pretty good shape, and some people are using it, but it *is* still undergoing QA. You can use it if you build from source including the new persister branch (bug21673). alexis On Wed, May 12, 2010 at 2:34 PM, Andreas Jung wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Reading about the "new persister"...is it part of RabbitMQ 1.7.2 or > available through some nightly build? > > Andreas > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkvqrkwACgkQCJIWIbr9KYwbygCfbAwMiPaDBygVItciHJJgcE5P > j1oAoKFRHZR+VE3ucszkMgduSEBxB3Ac > =1Oqa > -----END PGP SIGNATURE----- > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > From sebastian.wain at nektra.com Wed May 12 17:47:29 2010 From: sebastian.wain at nektra.com (srw) Date: Wed, 12 May 2010 09:47:29 -0700 (PDT) Subject: [rabbitmq-discuss] Bound Queues In-Reply-To: <4BC3D9E4.8030804@lshift.net> References: <4BC3D9E4.8030804@lshift.net> Message-ID: <28538369.post@talk.nabble.com> Tony Garnock-Jones-2 wrote: > > Dan Di Spaltro wrote: >> Is there anyway you can specify a memory/disk/length limit to a queue >> size with the action being a similar to a fixed window? > > Not at the moment, no. > >> If not, is there any chance it is on the roadmap? I know its not in >> the amqp spec, but it could be treated like a header. > > It's not exactly on the roadmap > ... > ... > ... > As a RabbitMQ newbie I was thinking on this issue too: is it possible to block publisher's send while the queue is above a certain threshold? I am experiencing many RabbitMQ crashes because the queue size surpass the machine memory. This is happening in many scenarios where the ratio between #published_messages/#consumed_messages is very high (and the message size is big). Don't know if it's very uncommon. My use case is a long text mining pipeline where there is a lot of input data and some processes cause a bottleneck (but with the solution exposed above the bottleneck will just slow the publishers and every process will finish). Thanks, srw -- View this message in context: http://old.nabble.com/Bound-Queues-tp28224659p28538369.html Sent from the RabbitMQ mailing list archive at Nabble.com. From colin at cloudeventprocessing.com Wed May 12 17:54:19 2010 From: colin at cloudeventprocessing.com (Colin Clark) Date: Wed, 12 May 2010 11:54:19 -0500 Subject: [rabbitmq-discuss] Bound Queues In-Reply-To: <28538369.post@talk.nabble.com> References: <4BC3D9E4.8030804@lshift.net> <28538369.post@talk.nabble.com> Message-ID: <4BEADD3B.9040109@cloudeventprocessing.com> Are you not able to add more consumers? On 5/12/2010 11:47 AM, srw wrote: > > Tony Garnock-Jones-2 wrote: > >> Dan Di Spaltro wrote: >> >>> Is there anyway you can specify a memory/disk/length limit to a queue >>> size with the action being a similar to a fixed window? >>> >> Not at the moment, no. >> >> >>> If not, is there any chance it is on the roadmap? I know its not in >>> the amqp spec, but it could be treated like a header. >>> >> It's not exactly on the roadmap >> ... >> ... >> ... >> >> > As a RabbitMQ newbie I was thinking on this issue too: is it possible to > block publisher's send while the queue is above a certain threshold? > > I am experiencing many RabbitMQ crashes because the queue size surpass the > machine memory. This is happening in many scenarios where the ratio between > #published_messages/#consumed_messages is very high (and the message size is > big). Don't know if it's very uncommon. My use case is a long text mining > pipeline where there is a lot of input data and some processes cause a > bottleneck (but with the solution exposed above the bottleneck will just > slow the publishers and every process will finish). > > Thanks, > srw > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100512/643a64a9/attachment.htm From tonyg at lshift.net Wed May 12 21:09:18 2010 From: tonyg at lshift.net (Tony Garnock-Jones) Date: Thu, 13 May 2010 08:09:18 +1200 Subject: [rabbitmq-discuss] Presence exchange plugin Message-ID: <4BEB0AEE.90004@lshift.net> Hi all, I've just committed http://github.com/tonyg/presence-exchange, an experimental RabbitMQ five-minute-hack exchange plugin that notifies bound queues when other bindings appear and disappear. The code itself is trivially short: http://github.com/tonyg/presence-exchange/blob/master/src/presence_exchange.erl#L37-L67 Crude documentation can be found in the README: http://github.com/tonyg/presence-exchange#readme Instructions on building and deploying plugins can be found here: http://www.rabbitmq.com/plugin-development.html#getting-started Cheers, Tony From sebastian.wain at nektra.com Wed May 12 23:31:28 2010 From: sebastian.wain at nektra.com (srw) Date: Wed, 12 May 2010 15:31:28 -0700 (PDT) Subject: [rabbitmq-discuss] Bound Queues In-Reply-To: <4BEADD3B.9040109@cloudeventprocessing.com> References: <4BC3D9E4.8030804@lshift.net> <28538369.post@talk.nabble.com> <4BEADD3B.9040109@cloudeventprocessing.com> Message-ID: <28541854.post@talk.nabble.com> Colin Clark-5 wrote: > > Are you not able to add more consumers? > Theoretically yes but not in this case because the publisher speed is very high and the overall throughput is fine, so there isn't a real need for more subscribers. I can put an sleep there... or do another trick but don't feel comfortably with that solution. I think Weblogic JMS (and multithreading Python Queues too) provides this kind of feature. Don't know if formally this is right or wrong. Thanks, srw -- View this message in context: http://old.nabble.com/Bound-Queues-tp28224659p28541854.html Sent from the RabbitMQ mailing list archive at Nabble.com. From tonyg at lshift.net Wed May 12 23:34:44 2010 From: tonyg at lshift.net (Tony Garnock-Jones) Date: Thu, 13 May 2010 10:34:44 +1200 Subject: [rabbitmq-discuss] Bound Queues In-Reply-To: <28538369.post@talk.nabble.com> References: <4BC3D9E4.8030804@lshift.net> <28538369.post@talk.nabble.com> Message-ID: <4BEB2D04.20304@lshift.net> srw wrote: > As a RabbitMQ newbie I was thinking on this issue too: is it possible to > block publisher's send while the queue is above a certain threshold? Hmm. Well there's a builtin feature that if memory usage gets above a threshold for the server *as a whole*, a "channel.flow" notification (like XOFF) gets sent out to connected clients until the backlog clears. It's enabled by default, though, so maybe something's wrong. Which client library are you using? Some of them don't pay attention to channel.flow, in violation of the spec, which can lead to overflowing the server. Tony From sebastian.wain at nektra.com Wed May 12 23:38:31 2010 From: sebastian.wain at nektra.com (srw) Date: Wed, 12 May 2010 15:38:31 -0700 (PDT) Subject: [rabbitmq-discuss] Bound Queues In-Reply-To: <4BEB2D04.20304@lshift.net> References: <4BC3D9E4.8030804@lshift.net> <28538369.post@talk.nabble.com> <4BEB2D04.20304@lshift.net> Message-ID: <28541903.post@talk.nabble.com> Tony Garnock-Jones-2 wrote: > > ... Which client library are you using? > I am using Python Carrot. Thanks, srw -- View this message in context: http://old.nabble.com/Bound-Queues-tp28224659p28541903.html Sent from the RabbitMQ mailing list archive at Nabble.com. From tonyg at lshift.net Thu May 13 00:03:46 2010 From: tonyg at lshift.net (Tony Garnock-Jones) Date: Thu, 13 May 2010 11:03:46 +1200 Subject: [rabbitmq-discuss] Bound Queues In-Reply-To: <28541903.post@talk.nabble.com> References: <4BC3D9E4.8030804@lshift.net> <28538369.post@talk.nabble.com> <4BEB2D04.20304@lshift.net> <28541903.post@talk.nabble.com> Message-ID: <4BEB33D2.3090304@lshift.net> srw wrote: > Tony Garnock-Jones-2 wrote: >> ... Which client library are you using? >> > I am using Python Carrot. With which backend library? Tony From tonyg at lshift.net Thu May 13 01:12:15 2010 From: tonyg at lshift.net (Tony Garnock-Jones) Date: Thu, 13 May 2010 12:12:15 +1200 Subject: [rabbitmq-discuss] Bound Queues In-Reply-To: <28541903.post@talk.nabble.com> References: <4BC3D9E4.8030804@lshift.net> <28538369.post@talk.nabble.com> <4BEB2D04.20304@lshift.net> <28541903.post@talk.nabble.com> Message-ID: <4BEB43DF.2070505@lshift.net> If it's py-amqplib, I *think* it doesn't deal with channel.flow properly, which could well be the issue! I have an experimental patch you could try: http://gist.github.com/399282 Tony srw wrote: > > Tony Garnock-Jones-2 wrote: >> ... Which client library are you using? >> > > I am using Python Carrot. > > Thanks, > srw > > From listuser at codeshrink.com Thu May 13 05:57:19 2010 From: listuser at codeshrink.com (Roaan Vos) Date: Thu, 13 May 2010 06:57:19 +0200 Subject: [rabbitmq-discuss] RabbitMQ configuration Message-ID: Hi, We've been having problems with RabbitMQ just "hanging". This is with the default installation, i.e no configuration. Can any one help with a configuration file or point me to where I can find information on how to configure RabbitMQ. We're running RabbitMQ 1.7.2 on a single node on Windows 2008 Server. Also we're aiming on having about 10 thousand clients (connections) each with their own queue. (Using Topics) Is this feasable? Thanks Roaan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100513/2101ad90/attachment.htm From videlalvaro at gmail.com Thu May 13 09:36:29 2010 From: videlalvaro at gmail.com (Alvaro Videla) Date: Thu, 13 May 2010 16:36:29 +0800 Subject: [rabbitmq-discuss] new RabbitMQ admin console in PHP Message-ID: <23F39FD3-401B-4745-8DA1-3CFEA3B503D5@gmail.com> Hi, I'd like to share our new RabbitMQ Administration Console: http://github.com/tnc/rac Is written in PHP which makes it very easy to deploy. Let me know if you have any questions on how to run it, or if you have any feature requests or bug reports. Regards, Alvaro From matthew at lshift.net Thu May 13 10:45:39 2010 From: matthew at lshift.net (Matthew Sackman) Date: Thu, 13 May 2010 10:45:39 +0100 Subject: [rabbitmq-discuss] RabbitMQ configuration In-Reply-To: References: Message-ID: <20100513094538.GA20620@mrnibble.lshift.net> Hi Roaan, On Thu, May 13, 2010 at 06:57:19AM +0200, Roaan Vos wrote: > We've been having problems with RabbitMQ just "hanging". > This is with the default installation, i.e no configuration. It's likely you've run out of memory and Rabbit's raised the channel.flow flag, preventing you from publishing more messages to it. Check the logs for memory high watermark warnings. This issue is fixed with the new persister branch as messages can be sent to disk and forgotten from RAM. > Can any one help with a configuration file or point me to where I can find > information on how to configure RabbitMQ. There's not a great deal you can do to fix this issue other than compiling from source with the new persister branch (bug21673), or installing much more memory. > We're running RabbitMQ 1.7.2 on a single node on Windows 2008 Server. Windows is a bad idea because there is no 64-bit Erlang available. As such, it doesn't matter how much RAM you have installed, only 2GB will be available to Rabbit. If you need to use Windows then your only solution will be to use the new persister branch (but compiling under Windows is involved to say the least - you'll need to start with cygwin). Really we'd recommend a Linux server here. That said, all my assumptions may be totally wrong - how many messages (and what size) are you buffering in Rabbit? Are you correctly acking messages when you're consuming them? > Also we're aiming on having about 10 thousand clients (connections) each > with their own queue. (Using Topics) > Is this feasable? Connections - yes. You will probably need to raise the process limit - about a million should be fine. Under non-Windows this would involve putting SERVER_START_ARGS="+P 1048576" into the rabbitmq.conf file (which normally lives under /etc/rabbitmq). However, because of lack of features of Windows BAT files, there is no such .conf file, so you need to set the environment variable RABBITMQ_SERVER_START_ARGS and set the value to "+P 1048576". That should do the trick. Topic exchanges are inefficient in our current implementation. It's not normally necessary to use them either - unless your domain of routing keys really is unbounded. Can you describe more about your use case and we should be able to advise you further. Matthew From lists at zopyx.com Thu May 13 11:02:04 2010 From: lists at zopyx.com (Andreas Jung) Date: Thu, 13 May 2010 12:02:04 +0200 Subject: [rabbitmq-discuss] High-number of unack-ed messages Message-ID: <4BEBCE1C.7040808@zopyx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, doing some "mass" tests with RabbitMQ 1.7.2. I inserted some 500k messages with one produce into the queue. Then I attached one consumer to the queue feeding the messages into Solr. The consumer is implemented as callback using the Carrot bindings for Python. Every message is directly acknowledged. However "Alice" always shows me between 300 and 500 unacknowledged messages. Shouldn't that number be 0 or 1? Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvrzhwACgkQCJIWIbr9KYzYzACgwmkBIyvXaDIMsHCg58oM5Gty tIIAnjpSEk9EH66tW/Uhw9upyIeM/J/Y =9t+D -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: lists.vcf Type: text/x-vcard Size: 316 bytes Desc: not available Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100513/2ca688ac/attachment-0001.vcf From listuser at codeshrink.com Thu May 13 13:30:55 2010 From: listuser at codeshrink.com (Roaan Vos) Date: Thu, 13 May 2010 14:30:55 +0200 Subject: [rabbitmq-discuss] RabbitMQ configuration In-Reply-To: <20100513094538.GA20620@mrnibble.lshift.net> References: <20100513094538.GA20620@mrnibble.lshift.net> Message-ID: Hi, Thanks for the reply. Unfortunately it has to be windows as our company does not support non windows. As to our usage. We're processing messages from a stock exchange and setup a routing key containing of "level.isin" where the level can be level 1 or level 2 depending on the type of information and the isin is the stock. "Clients" can then bind to a specific routing key to get just the information they need. I'm thus using RabbitMQ as a way to transfer data and demultiplex the information that comes through. I could use RabbitMQ just for the message transfer and then do the demultiplexing myself but I thought I'd take a shortcut. On the configuration. Is there some documentation on what or how RabbitMQ can be configured. Currently I can't find a configuration file anywhere so don't know where/how to start. Thanks again Roaan On Thu, May 13, 2010 at 11:45 AM, Matthew Sackman wrote: > Hi Roaan, > > On Thu, May 13, 2010 at 06:57:19AM +0200, Roaan Vos wrote: > > We've been having problems with RabbitMQ just "hanging". > > This is with the default installation, i.e no configuration. > > It's likely you've run out of memory and Rabbit's raised the > channel.flow flag, preventing you from publishing more messages to it. > Check the logs for memory high watermark warnings. This issue is fixed > with the new persister branch as messages can be sent to disk and > forgotten from RAM. > > > Can any one help with a configuration file or point me to where I can > find > > information on how to configure RabbitMQ. > > There's not a great deal you can do to fix this issue other than > compiling from source with the new persister branch (bug21673), or > installing much more memory. > > > We're running RabbitMQ 1.7.2 on a single node on Windows 2008 Server. > > Windows is a bad idea because there is no 64-bit Erlang available. As > such, it doesn't matter how much RAM you have installed, only 2GB will > be available to Rabbit. If you need to use Windows then your only > solution will be to use the new persister branch (but compiling under > Windows is involved to say the least - you'll need to start with > cygwin). Really we'd recommend a Linux server here. > > That said, all my assumptions may be totally wrong - how many messages > (and what size) are you buffering in Rabbit? Are you correctly acking > messages when you're consuming them? > > > Also we're aiming on having about 10 thousand clients (connections) each > > with their own queue. (Using Topics) > > Is this feasable? > > Connections - yes. You will probably need to raise the process limit - > about a million should be fine. Under non-Windows this would involve > putting SERVER_START_ARGS="+P 1048576" into the rabbitmq.conf file > (which normally lives under /etc/rabbitmq). However, because of lack of > features of Windows BAT files, there is no such .conf file, so you need > to set the environment variable RABBITMQ_SERVER_START_ARGS and set the > value to "+P 1048576". That should do the trick. > > Topic exchanges are inefficient in our current implementation. It's not > normally necessary to use them either - unless your domain of routing > keys really is unbounded. Can you describe more about your use case and > we should be able to advise you further. > > Matthew > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100513/2760723e/attachment.htm From matthew at lshift.net Thu May 13 14:26:16 2010 From: matthew at lshift.net (Matthew Sackman) Date: Thu, 13 May 2010 14:26:16 +0100 Subject: [rabbitmq-discuss] shovel terminating, channel.flow_ok? In-Reply-To: <3E976A21-45BF-4E72-8F75-87D6C66B93FF@admob.com> References: <3E976A21-45BF-4E72-8F75-87D6C66B93FF@admob.com> Message-ID: <20100513132616.GC20620@mrnibble.lshift.net> Hi Mark, On Mon, May 03, 2010 at 11:25:15AM -0700, Mark Lin wrote: > Getting the following errors when shovel terminates. Once this starts to happen, shovel would just keep retrying connection until rabbit-server quits. Has anyone seen this? Sorry we didn't get back to you sooner. We actually tracked this down to a bug in the server, which has now been fixed and as of today is in the default branch - compiling the server from source should now solve this. Please let us know if you spot any further issues. Best wishes, Matthew From matthew at lshift.net Thu May 13 14:40:24 2010 From: matthew at lshift.net (Matthew Sackman) Date: Thu, 13 May 2010 14:40:24 +0100 Subject: [rabbitmq-discuss] High-number of unack-ed messages In-Reply-To: <4BEBCE1C.7040808@zopyx.com> References: <4BEBCE1C.7040808@zopyx.com> Message-ID: <20100513134024.GD20620@mrnibble.lshift.net> Hi Andreas, On Thu, May 13, 2010 at 12:02:04PM +0200, Andreas Jung wrote: > I inserted some 500k messages with one produce into the queue. > Then I attached one consumer to the queue feeding the messages into > Solr. The consumer is implemented as callback using the Carrot bindings > for Python. Every message is directly acknowledged. However "Alice" > always shows me between 300 and 500 unacknowledged messages. Shouldn't > that number be 0 or 1? Well. It should be low, but if there's no QoS being set by Alice then it can get quite high. I would only trust it to be 0 or 1 if Alice was also setting a QoS prefetch of 1, and even then, there are cases where the unack count can be higher than that. After Alice had drained all 500k messages, was the unack count still high, or had it dropped to 0 by then? Matthew From matthew at lshift.net Thu May 13 14:52:38 2010 From: matthew at lshift.net (Matthew Sackman) Date: Thu, 13 May 2010 14:52:38 +0100 Subject: [rabbitmq-discuss] RabbitMQ config file. In-Reply-To: <49A7BA114AAC6A48B9C44CB06B7B987E0A211478@HYDSVWIN004X.ivycomptech.partygaming.local> References: <49A7BA114AAC6A48B9C44CB06B7B987E0A211478@HYDSVWIN004X.ivycomptech.partygaming.local> Message-ID: <20100513135238.GF20620@mrnibble.lshift.net> Hi Radha, On Tue, May 11, 2010 at 12:05:55PM +0530, Radha Krishnan D wrote: > We are using rabbitmq-server-1.7.2 ( downloaded under the heading > generic Linux ). Since our linux machine RAM is 8 GB and it is a 32 bit > machine. RabbitMQ takes 1638 MB and it prints it in the logs. How ever > when I want to increase the size by using {rabbit, > [{vm_memory_high_watermark, 2.0}]} the rabbitMQ server is not > recognizing this configuration change at all. Err, if you're using a 32-bit OS, it's not going to be able to allocate more than 4GB to any single application. The 0.4 by default then looks to be correct, as 1638/0.4 = 4095, i.e. 4GB. The 0.4 is carefully chosen to accomodate the possibility of Erlang's GC temporarily using up an awful lot more RAM. If you ever have the case where Erlang runs out of address space then it will crash, and take down Rabbit with it. I believe from your subsequent email that you've sorted out the configuration issue. > Also please clear us about the difference between rabbitmq.conf file and > rabbitmq.config file. .conf is a shell file which should be used to set environment variables which influence Rabbit. .config is an Erlang term file. Originally we only had the .conf file. However as time passed, and we needed to allow more complex configurations, the .config file came along (which is also used for configuring plugins). Currently, it's a bit of a mess as some things you can configure in either place, and others you can't. We have a fairly high priority bug to unify, document and generally sort all of this out. Matthew From matthew at lshift.net Thu May 13 14:56:11 2010 From: matthew at lshift.net (Matthew Sackman) Date: Thu, 13 May 2010 14:56:11 +0100 Subject: [rabbitmq-discuss] RabbitMQ config file. In-Reply-To: <49A7BA114AAC6A48B9C44CB06B7B987E0A211B97@HYDSVWIN004X.ivycomptech.partygaming.local> References: <49A7BA114AAC6A48B9C44CB06B7B987E06445F38@HYDSVWIN004X.ivycomptech.partygaming.local> <49A7BA114AAC6A48B9C44CB06B7B987E0A211B97@HYDSVWIN004X.ivycomptech.partygaming.local> Message-ID: <20100513135609.GG20620@mrnibble.lshift.net> On Wed, May 12, 2010 at 09:42:00AM +0530, Radha Krishnan D wrote: > Now I sent 80000 messages of size 1933 bytes from producer to the broker. > The consumer receives 76000 at one run , 68000 at another run. > There is a drop of messages. How do you know that the queues are empty? Also, are you certain the queues exist before the publishes begin? Matthew From vivek at khera.org Thu May 13 15:39:55 2010 From: vivek at khera.org (Vick Khera) Date: Thu, 13 May 2010 10:39:55 -0400 Subject: [rabbitmq-discuss] Bound Queues In-Reply-To: <28541854.post@talk.nabble.com> References: <4BC3D9E4.8030804@lshift.net> <28538369.post@talk.nabble.com> <4BEADD3B.9040109@cloudeventprocessing.com> <28541854.post@talk.nabble.com> Message-ID: On Wed, May 12, 2010 at 6:31 PM, srw wrote: > Colin Clark-5 wrote: >> >> Are you not able to add more consumers? >> > > Theoretically yes but not in this case because the publisher speed is very > high and the overall throughput is fine, so there isn't a real need for more > subscribers. I can put an sleep there... or do another trick but don't feel > comfortably with that solution. > I'm looking at a situation where I have a lot of producers doing work, but one part of logging the info must be done via a single-threaded process to avoid deadlocks across the workers. So basically I'll have one consumer and a bunch of producers. The backlog can get large -- I'm not worried about the delay of processing the requests -- but I need to not lose any requests. Anyone know if Theo's Net::RabbitMQ perl module honors the channel.flow? It appears to be built upon the C client. What if my producers used the "mandatory" flag to detect if the queue is full, and then just pause for a while if it is? If I use a large-RAM box for my queue server, will rabbitmq use more of it? Thanks. From johndapps at gmail.com Thu May 13 16:04:08 2010 From: johndapps at gmail.com (John Apps) Date: Thu, 13 May 2010 17:04:08 +0200 Subject: [rabbitmq-discuss] RabbitMQ configuration In-Reply-To: References: <20100513094538.GA20620@mrnibble.lshift.net> Message-ID: http://www.rabbitmq.com/install.html is a good place to start. On Thu, May 13, 2010 at 14:30, Roaan Vos wrote: > Hi, > > Thanks for the reply. > > Unfortunately it has to be windows as our company does not support non > windows. > > As to our usage. > > We're processing messages from a stock exchange and setup a routing key > containing of "level.isin" > where the level can be level 1 or level 2 depending on the type of > information and the isin is the stock. > > "Clients" can then bind to a specific routing key to get just the > information they need. > I'm thus using RabbitMQ as a way to transfer data and demultiplex the > information that comes through. > I could use RabbitMQ just for the message transfer and then do the > demultiplexing myself but I thought I'd take a shortcut. > > On the configuration. Is there some documentation on what or how RabbitMQ > can be configured. > Currently I can't find a configuration file anywhere so don't know > where/how to start. > > Thanks again > > Roaan > > > On Thu, May 13, 2010 at 11:45 AM, Matthew Sackman wrote: > >> Hi Roaan, >> >> On Thu, May 13, 2010 at 06:57:19AM +0200, Roaan Vos wrote: >> > We've been having problems with RabbitMQ just "hanging". >> > This is with the default installation, i.e no configuration. >> >> It's likely you've run out of memory and Rabbit's raised the >> channel.flow flag, preventing you from publishing more messages to it. >> Check the logs for memory high watermark warnings. This issue is fixed >> with the new persister branch as messages can be sent to disk and >> forgotten from RAM. >> >> > Can any one help with a configuration file or point me to where I can >> find >> > information on how to configure RabbitMQ. >> >> There's not a great deal you can do to fix this issue other than >> compiling from source with the new persister branch (bug21673), or >> installing much more memory. >> >> > We're running RabbitMQ 1.7.2 on a single node on Windows 2008 Server. >> >> Windows is a bad idea because there is no 64-bit Erlang available. As >> such, it doesn't matter how much RAM you have installed, only 2GB will >> be available to Rabbit. If you need to use Windows then your only >> solution will be to use the new persister branch (but compiling under >> Windows is involved to say the least - you'll need to start with >> cygwin). Really we'd recommend a Linux server here. >> >> That said, all my assumptions may be totally wrong - how many messages >> (and what size) are you buffering in Rabbit? Are you correctly acking >> messages when you're consuming them? >> >> > Also we're aiming on having about 10 thousand clients (connections) each >> > with their own queue. (Using Topics) >> > Is this feasable? >> >> Connections - yes. You will probably need to raise the process limit - >> about a million should be fine. Under non-Windows this would involve >> putting SERVER_START_ARGS="+P 1048576" into the rabbitmq.conf file >> (which normally lives under /etc/rabbitmq). However, because of lack of >> features of Windows BAT files, there is no such .conf file, so you need >> to set the environment variable RABBITMQ_SERVER_START_ARGS and set the >> value to "+P 1048576". That should do the trick. >> >> Topic exchanges are inefficient in our current implementation. It's not >> normally necessary to use them either - unless your domain of routing >> keys really is unbounded. Can you describe more about your use case and >> we should be able to advise you further. >> >> Matthew >> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > -- --- John Apps (49) 171 869 1813 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100513/b86d1402/attachment-0001.htm From Scott.Behrens at radiusit.com Thu May 13 16:08:08 2010 From: Scott.Behrens at radiusit.com (Scott Behrens) Date: Thu, 13 May 2010 10:08:08 -0500 Subject: [rabbitmq-discuss] init terminating in do_boot Message-ID: <09037F769A7E474A972B1A77B851155301C56017@radsvr01.radiusit.local> Hello, I have just freshly installed rabbitmq-server-1.7.2-1.fc12.x86_64 for my Fedora 12 box. I have 10 boxes running this fine, with the exception of 1 host. On that host I receive this error in the /var/log/rabbitmq/startup_log: node : rabbit at mdevmq03 app descriptor: /usr/lib64/rabbitmq/lib/rabbitmq_server-1.7.2/sbin/../ebin/rabbit.app home dir : /var/lib/rabbitmq cookie hash : t+/2QN4+dzb+4p2S6zfTOw== log : /var/log/rabbitmq/rabbit.log sasl log : /var/log/rabbitmq/rabbit-sasl.log database dir : /var/lib/rabbitmq/mnesia/rabbit {"init terminating in do_boot",{{nocatch,{error,{cannot_start_application,rabbit,{bad_return,{ {rabbit,start,[normal,[]]},{'EXIT',{undef,[{nteventlog,module_info,[attr ibutes]},{rabbit,'-boot_steps/0-fun-0-',1},{lists,flatmap,2},{lists,flat map,2},{rabbit,boot_steps,0},{rabbit,start,2},{application_master,start_ it_old,4}]}}}}}}},[{init,start_it,1},{init,start_em,1}]}}^M I have tried uninstalling/reinstalling the application, reloading the base OS, etc. Any help would be appreciated. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100513/eec59a0b/attachment.htm From brendan.doyle at epicadvertising.com Thu May 13 16:20:06 2010 From: brendan.doyle at epicadvertising.com (Brendan Doyle) Date: Thu, 13 May 2010 10:20:06 -0500 Subject: [rabbitmq-discuss] High-number of unack-ed messages In-Reply-To: <20100513134024.GD20620@mrnibble.lshift.net> References: <4BEBCE1C.7040808@zopyx.com> <20100513134024.GD20620@mrnibble.lshift.net> Message-ID: <019F0A76-E18A-4098-A491-CDFE31852B0F@epicadvertising.com> On 1.7.2 I often see unack count reported by rabbitmqctl much higher than my QoS x number of consumers I always wrote it off to high throughput and different priorities on handling new incoming messages vs. acks or another internal implementation detail Brendan On 2010-05-13, at 9:40 AM, Matthew Sackman wrote: > Hi Andreas, > > On Thu, May 13, 2010 at 12:02:04PM +0200, Andreas Jung wrote: >> I inserted some 500k messages with one produce into the queue. >> Then I attached one consumer to the queue feeding the messages into >> Solr. The consumer is implemented as callback using the Carrot bindings >> for Python. Every message is directly acknowledged. However "Alice" >> always shows me between 300 and 500 unacknowledged messages. Shouldn't >> that number be 0 or 1? > > Well. It should be low, but if there's no QoS being set by Alice then it > can get quite high. I would only trust it to be 0 or 1 if Alice was also > setting a QoS prefetch of 1, and even then, there are cases where the > unack count can be higher than that. > > After Alice had drained all 500k messages, was the unack count still > high, or had it dropped to 0 by then? > > Matthew > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From matthew at lshift.net Thu May 13 16:28:11 2010 From: matthew at lshift.net (Matthew Sackman) Date: Thu, 13 May 2010 16:28:11 +0100 Subject: [rabbitmq-discuss] High-number of unack-ed messages In-Reply-To: <019F0A76-E18A-4098-A491-CDFE31852B0F@epicadvertising.com> References: <4BEBCE1C.7040808@zopyx.com> <20100513134024.GD20620@mrnibble.lshift.net> <019F0A76-E18A-4098-A491-CDFE31852B0F@epicadvertising.com> Message-ID: <20100513152811.GI20620@mrnibble.lshift.net> On Thu, May 13, 2010 at 10:20:06AM -0500, Brendan Doyle wrote: > On 1.7.2 I often see unack count reported by rabbitmqctl much higher than my QoS x number of consumers > > I always wrote it off to high throughput and different priorities on handling new incoming messages vs. acks or another internal implementation detail Yeah, that's generally wise - in general the numbers reported by rabbitmqctl can't be trusted too much as they're accurate only for things that have *really* made it to the queue - there are plenty of places within rabbitmq where buffering can occur. Matthew From rtrlists at googlemail.com Thu May 13 17:03:20 2010 From: rtrlists at googlemail.com (Robert Raschke) Date: Thu, 13 May 2010 17:03:20 +0100 Subject: [rabbitmq-discuss] init terminating in do_boot In-Reply-To: <09037F769A7E474A972B1A77B851155301C56017@radsvr01.radiusit.local> References: <09037F769A7E474A972B1A77B851155301C56017@radsvr01.radiusit.local> Message-ID: On Thu, May 13, 2010 at 4:08 PM, Scott Behrens wrote: > Hello, > > > > I have just freshly installed rabbitmq-server-1.7.2-1.fc12.x86_64 for my > Fedora 12 box. I have 10 boxes running this fine, with the exception of 1 > host. On that host I receive this error in the > /var/log/rabbitmq/startup_log: > > > > > > node : rabbit at mdevmq03 > > app descriptor: > /usr/lib64/rabbitmq/lib/rabbitmq_server-1.7.2/sbin/../ebin/rabbit.app > > home dir : /var/lib/rabbitmq > > cookie hash : t+/2QN4+dzb+4p2S6zfTOw== > > log : /var/log/rabbitmq/rabbit.log > > sasl log : /var/log/rabbitmq/rabbit-sasl.log > > database dir : /var/lib/rabbitmq/mnesia/rabbit > > > > {"init terminating in > do_boot",{{nocatch,{error,{cannot_start_application,rabbit,{bad_return,{{rabbit,start,[normal,[]]},{'EXIT',{undef,[{nteventlog,module_info,[attributes]},{rabbit,'-boot_steps/0-fun-0-',1},{lists,flatmap,2},{lists,flatmap,2},{rabbit,boot_steps,0},{rabbit,start,2},{application_master,start_it_old,4}]}}}}}}},[{init,start_it,1},{init,start_em,1}]}}^M > > > > I have tried uninstalling/reinstalling the application, reloading the base > OS, etc. Any help would be appreciated. > > > > Scott > > For some reason it's trying to do something with the nteventlog module. As you're on Fedora, I don't think that can be right. Maybe the Erlang sys.config file is trying to set up nteventlog monitoring? Robby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100513/ef3ef9b7/attachment.htm From matthias at rabbitmq.com Thu May 13 18:40:47 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Thu, 13 May 2010 18:40:47 +0100 Subject: [rabbitmq-discuss] High-number of unack-ed messages In-Reply-To: <20100513152811.GI20620@mrnibble.lshift.net> References: <4BEBCE1C.7040808@zopyx.com> <20100513134024.GD20620@mrnibble.lshift.net> <019F0A76-E18A-4098-A491-CDFE31852B0F@epicadvertising.com> <20100513152811.GI20620@mrnibble.lshift.net> Message-ID: <4BEC399F.4030902@rabbitmq.com> Brendan, Matthew Sackman wrote: > On Thu, May 13, 2010 at 10:20:06AM -0500, Brendan Doyle wrote: >> On 1.7.2 I often see unack count reported by rabbitmqctl much >> higher than my QoS x number of consumers >> >> I always wrote it off to high throughput and different priorities >> on handling new incoming messages vs. acks or another internal >> implementation detail > > Yeah, that's generally wise - in general the numbers reported by > rabbitmqctl can't be trusted too much as they're accurate only for > things that have *really* made it to the queue - there are plenty of > places within rabbitmq where buffering can occur. What Matthew says is true, but the discrepancy you are seeing still strikes me as somewhat unusual. For the reported unacked message count to be much higher than the prefetch limit x number of consumers one of the following likely has happened: a) the prefetch limit was only set after the consumer have been created b) messages were consumed with basic.get rather than basic.consume Is that the case? If not, could you post the code to reproduce the results you are seeing? There may be a completely innocent explanation, but there could also be a bug lurking somewhere, so I'd like to understand what is happening here. Regards, Matthias. From alexis at rabbitmq.com Thu May 13 20:02:22 2010 From: alexis at rabbitmq.com (Alexis Richardson) Date: Thu, 13 May 2010 20:02:22 +0100 Subject: [rabbitmq-discuss] Fwd: Fwd: active/active In-Reply-To: References: <167204d21001171240j780c5f98oedace8539a884283@mail.gmail.com> <3b949f091001181707k15feadd5je82aae41dc60d0be@mail.gmail.com> Message-ID: Hi, I'd like to make a brief comment on this. Right now, we are starting to think properly about HA cases that require something more refined than the active/passive set-up described here: http://www.rabbitmq.com/pacemaker.html There are a lot of these, depending on how you mix durability, visibility, latency and domains of control. Some of the NoSQL folks, eg the Riak team, are working on related problems which we try to study when we can. We are actively working with customers who need any kind of HA Rabbit, mostly behind the firewall but also in the cloud. We are also working on some 'cloud services' as I stated here: http://skillsmatter.com/podcast/cloud-grid/use-cases-for-cloud-messaging My point is - this is a useful discussion and we really appreciate any and all feedback on this :-) alexis On Tue, May 11, 2010 at 7:59 PM, John Apps wrote: > Jason suggested I post my response to his note rather than a private reply > to him. Well, it just so happens that that is what I intended, but managed > to get the email addresses all mixed - again. > It is my belief that the world does need truly durable/persistent/reliable > messaging. It is also the case that there are many applications out there > which use it even when they had no need originally. DECmessageQ (Oracle > Message Queue these days) is an example in point. > ---------- Forwarded message ---------- > From: Jason J. W. Williams > Date: Tue, May 11, 2010 at 20:46 > Subject: Re: [rabbitmq-discuss] Fwd: active/active > To: John Apps > > > Hi John, > > It'd be great if you could share that with the list. Regarding > duplication, I think that's easily addressed. If you're in a situation > where the sender is going to re-send if they don't get confirmation it > was accepted/processed on the other side, then you don't need durable > messages. You're providing the durability. > > So the replay concept would only apply to durable messages and would > allow all involved to make the assumption the message will eventually > arrive and trust RabbitMQ to get it there...something that can't be > assumed at the moment with clustering. > > -J > > On Tue, May 11, 2010 at 1:25 AM, John Apps wrote: >> Option 1 below is neat and something that a product called Reliable >> Transaction Router (RTR) has offered for many years with considerable >> success. So, what, you might ask, has that to do with RabbitMQ? Well, >> quite >> simply, only to show that the concept is a viable one and has been used in >> practice for many years. >> One of the caveats with it is when the queues are feeding into two >> databases, one a copy of the other; no, not mirrored in the classic sense, >> rather, the messages are sent to both. The thing to take care of here is >> that when messages are being replayed, i.e., one server has been down and >> comes back up, whereupon the other server then plays the missed messages >> to >> it, is that the DB on the server processing the messages MUST not have >> been >> changed whilst the server was down. >> What would be 'nice to have' in this scenario is a flag stating that the >> messages are being re-played. This helps to avoid the problem of possible >> duplicate messages by making one aware of the fact that a re-play is in >> progress. >> With the purchase of GemStone, perhaps the folks at RabbitMQ can use some >> of >> the?distributed?messaging technology from that product suite? >> >> On Tue, May 11, 2010 at 00:43, Jason J. W. Williams >> wrote: >>> >>> It was suggested to me I relay a convo I had with Alexis earlier this >>> year making the case for better active/active fail-over in RabbitMQ. >>> Particularly, when working with durable messaging. >>> >>> >>> ---------- Forwarded message ---------- >>> From: Jason J. W. Williams >>> Date: Mon, Jan 18, 2010 at 7:07 PM >>> Subject: Re: active/active >>> To: Alexis Richardson >>> >>> >>> Hey Alexis, >>> >>> Currently, we have a single RMQ 1.5 pair that are setup >>> active/passive. That is to say, our apps publish to node A and if it >>> is unavailable publish to node B. Nodes A and B are standalone in that >>> they are not in a cluster together. This is because the messages being >>> published are durable, and in the event node A crashes any pending >>> durable messages would not be auto-resubmitted if node A were >>> clustered with node B (node B's queue essentially hides the pendings >>> that were in the queue on node A before the crash). >>> >>> This set up works OK for us, as the load is fairly light and >>> durability is more important for these tasks than availability. >>> >>> That being said we are designing a rework of our statistics logging >>> infrastructure around Rabbit. Our stats is very high volume and >>> availability is more important than durability (in fact none of the >>> messages will be durable). So our intention is to create a new Rabbit >>> cluster with three nodes and a load-balanced IP in front (since >>> auto-redirect based on load is no longer supported....nasty memo to >>> follow... ;) ). >>> >>> Our desire due to the fact that we're moving from a colo'd environment >>> to a cloud environment, is to collapse both Rabbit "clusters" >>> into a single cluster to maximize efficiency. It would also allow our >>> existing app to benefit from the performance of a load-sharing >>> environment. For that to happen however, Rabbit would have to do one >>> of two things when clustered regarding durable messages: >>> >>> 1.) When a crashed node is restarted, replay the pending/durable >>> messages into the queue on the node now responsible for the queue >>> after the crash. >>> 2.) Replicate all durable queues to more than one node, so that >>> durable queue contents continue after a node crash. >>> >>> Frankly, option 1 is just fine with us and would solve our issue. >>> >>> Does this help? Thank you for being concerned. >>> >>> -J >>> >>> _______________________________________________ >>> rabbitmq-discuss mailing list >>> rabbitmq-discuss at lists.rabbitmq.com >>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> >> >> >> -- >> --- >> John Apps >> (49) 171 869 1813 >> > > > > -- > --- > John Apps > (49) 171 869 1813 > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > From c at dgt.com.pl Thu May 13 22:42:37 2010 From: c at dgt.com.pl (Czaban) Date: Thu, 13 May 2010 14:42:37 -0700 (PDT) Subject: [rabbitmq-discuss] Using RabbitMQ like ICE or WCF duplex communication channel Message-ID: <28508178.post@talk.nabble.com> Hello, like in the subject - is it possible to use RabbitMQ to broadcasting events and messages without queuing them (do not keeping them in store) to only current clients connected to the server? The client not connected should not receive this messages. Best regards Piotr -- View this message in context: http://old.nabble.com/Using-RabbitMQ-like-ICE-or-WCF-duplex-communication-channel-tp28508178p28508178.html Sent from the RabbitMQ mailing list archive at Nabble.com. From sduncan at wetafx.co.nz Thu May 13 22:54:29 2010 From: sduncan at wetafx.co.nz (Samuel Duncan) Date: Fri, 14 May 2010 09:54:29 +1200 Subject: [rabbitmq-discuss] Using RabbitMQ like ICE or WCF duplex communication channel In-Reply-To: <28508178.post@talk.nabble.com> References: <28508178.post@talk.nabble.com> Message-ID: <4BEC7515.8000908@wetafx.co.nz> If I understand you correctly, this is what we do. There are no durable consumer queues because the volume of data would kill rabbit in a matter of minutes. When the consumers disconnect (or are not connected) the data is disappearing into the ether because there are no queues to receive it. When a consumer latches to the stream it generates a queue which starts to store data, but is only a problem if the consumer can't keep up. If your consumer can't keep up, kill it (and destroy the queue) or start new instances that share the inbound queue until you have enough to keep it clear. --SJD Czaban wrote: > Hello, like in the subject - is it possible to use RabbitMQ to broadcasting > events and messages without queuing them (do not keeping them in store) to > only current clients connected to the server? The client not connected > should not receive this messages. > > Best regards > Piotr > From c at dgt.com.pl Thu May 13 23:08:36 2010 From: c at dgt.com.pl (Czaban) Date: Thu, 13 May 2010 15:08:36 -0700 (PDT) Subject: [rabbitmq-discuss] Using RabbitMQ like ICE or WCF duplex communication channel In-Reply-To: <4BEC7515.8000908@wetafx.co.nz> References: <28508178.post@talk.nabble.com> <4BEC7515.8000908@wetafx.co.nz> Message-ID: <28553182.post@talk.nabble.com> We are using ActiveMQ now and this broker is responsible for events transportation by dynamic Topics and for keeping messages for applications used by users (Windows forms apps) connected to queues - but when the client is not connected the message is waiting for client 12 days (this is the SMS messages from the company GSM gateway). So the messages sent to Topics should be just transported without storing them and messages sent to queues should be kept. Best regards Piotr -- View this message in context: http://old.nabble.com/Using-RabbitMQ-like-ICE-or-WCF-duplex-communication-channel-tp28508178p28553182.html Sent from the RabbitMQ mailing list archive at Nabble.com. From alexis at rabbitmq.com Thu May 13 23:19:53 2010 From: alexis at rabbitmq.com (Alexis Richardson) Date: Thu, 13 May 2010 23:19:53 +0100 Subject: [rabbitmq-discuss] Using RabbitMQ like ICE or WCF duplex communication channel In-Reply-To: <28553182.post@talk.nabble.com> References: <28508178.post@talk.nabble.com> <4BEC7515.8000908@wetafx.co.nz> <28553182.post@talk.nabble.com> Message-ID: Piotr What you want is possible. Have a read of this: http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ alexis On Thu, May 13, 2010 at 11:08 PM, Czaban wrote: > > We are using ActiveMQ now and this broker is responsible for events > transportation by dynamic Topics ?and for keeping messages for applications > used by users (Windows forms apps) connected to queues - but when the client > is not connected the message is waiting for client 12 days (this is the SMS > messages from the company GSM gateway). So the messages sent to Topics > should be just transported without storing them and messages sent to queues > should be kept. > > Best regards > Piotr > > -- > View this message in context: http://old.nabble.com/Using-RabbitMQ-like-ICE-or-WCF-duplex-communication-channel-tp28508178p28553182.html > Sent from the RabbitMQ mailing list archive at Nabble.com. > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > From david at drmaciver.com Fri May 14 12:41:16 2010 From: david at drmaciver.com (David MacIver) Date: Fri, 14 May 2010 12:41:16 +0100 Subject: [rabbitmq-discuss] Bunny fork Message-ID: Hi everyone, This is just a heads up in case anyone finds themselves in a similar position to me: I've been using Bunny (Chris Duncan's Ruby AMQP client) on a work project, and it's largely been great, but I've run into a few issues, so I've created a fork which fixes them: http://github.com/DRMacIver/bunny Differences from the current released version: Improvements: * Flow control is supported (the released version will crash when rabbit sends flow control messages) * Somewhat better error diagnostics when things go wrong * Subscriptions are much more powerful - they're essentially fully supported - you can subscribe to multiple queues, mix subscriptions and other messages, etc. The API is quite rough at the moment and I'll probably be tinkering with it a reasonable amount, but it does work. * A few miscellaneous bug fixes (e.g. Bunny 0.6 will create malformed headers for some tables when the values are Bignums) Incompatibilities: * 0.9.1 support is totally ripped out * some of the old subscription behaviour is gone - max_message, unsubscribe automatically on exiting the loop, etc. This was largely because they interact poorly with the changes I made to support more general subscriptions. Basic operation is *largely* compatible, but there are a fair few differences. * a bunch of files have moved about so if you're relying on bunny internals your code will almost certainly break. One massive caveat: I'm not planning to maintain this in any official capacity. Chris has done a great job with Bunny, and is a much more responsible maintainer than I'm likely to be. These are really just the fixes I needed to get things done, and my long term goal is definitely to try to get all these improvements merged back into the Bunny mainline, but that's not straightforward at the moment due to the various features I bulldozed out of the way in my hurry to get this done. I'm simply letting people know that this exists in case you need some of these fixes now and are willing to risk running unreleased code to get them. Regards, David From jzaugg at gmail.com Fri May 14 12:44:43 2010 From: jzaugg at gmail.com (Jason Zaugg) Date: Fri, 14 May 2010 13:44:43 +0200 Subject: [rabbitmq-discuss] Unexplained shutdown of RabbitMQ Message-ID: =System Details:= Erlang .572 RabbitMQ 1.6.0 Windows Server 2003 64Bit 8 core machine. Lots of free disk space. =Application Details= The RabbitMQ Broker and the message consumers/publishers are running on the same machine. All the queues in this application are non-persistent. There are some other very low traffic applications with small persistent queues on the same broker. Five Java processes are running on this machine consuming and publishing messages through one VHost and one Exchange. There are desktop applications I've sent the architecture diagram separately to info at rabbitmq.com, but I can't share it with this list right now. I can send by private email if required. The applications and broker have been running smoothly in production for the last few weeks. =Symptoms= Today, a problem is occuring. After 5-60 minutes of uptime, the clients report that the broker is shutting down, then the Erlang process starts spinning on one CPU. I suspect it is writing the large error log during this time. We killed the erl.exe, and restarted. The shutdown produces this logging. For more context, see the attachment. =ERROR REPORT==== 14-May-2010::10:27:29 === ** Generic server <0.1962.0> terminating ** Last message in was {'EXIT',<0.1960.0>,{writer,send_failed,badarg}} ** When Server state == {ch,running,1,<0.1957.0>,<0.1960.0>,undefined,none, [snip reams of output with the queued messages] ** Reason for termination == ** {writer,send_failed,badarg} =Questions= 1. Can we configure RabbitMQ to suppress logging of the message queue when this error occurs. The log files are growing to 4GB+, and it's tricky to follow them. 2. What might "writer,send_failed,badarg" as the termination reason suggest as the root cause? 3. Prior the the shutdown, what is the meaning of: exception on TCP connection <0.2021.0> from 10.30.33.169:3251 {timeout,running} exception on TCP connection <0.1707.0> from 10.30.32.44:2692 connection_closed_abruptly 4. When I try to run rabbitmqctl, it fails with: C:\Documents and Settings\sophis_server>rabbitmqctl list_connections Listing connections ... Error: {badrpc,nodedown} and in the rabbit.log =ERROR REPORT==== 14-May-2010::10:36:28 === ** Connection attempt from disallowed node rabbitmqctl at CHGVASSOPP105 ** Let me know if I can provide more information, and thanks in advance for your help! Jason Zaugg -------------- next part -------------- A non-text attachment was scrubbed... Name: rabbit-restart-loop.log Type: application/octet-stream Size: 13531 bytes Desc: not available Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100514/79b55dfe/attachment.obj From matthew at lshift.net Fri May 14 13:04:31 2010 From: matthew at lshift.net (Matthew Sackman) Date: Fri, 14 May 2010 13:04:31 +0100 Subject: [rabbitmq-discuss] Unexplained shutdown of RabbitMQ In-Reply-To: References: Message-ID: <20100514120431.GJ20620@mrnibble.lshift.net> Hi Jason, Thanks for the report, and all the details. On Fri, May 14, 2010 at 01:44:43PM +0200, Jason Zaugg wrote: > =System Details:= > > Erlang .572 > RabbitMQ 1.6.0 > Windows Server 2003 64Bit > 8 core machine. > Lots of free disk space. > > =Questions= > > 1. Can we configure RabbitMQ to suppress logging of the message queue > when this error occurs. The log files are growing to 4GB+, and it's > tricky to follow them. Unfortunately not. We would like to fix that ourselves too and there's meant to be a hook to be able to control that but there've been reports that there've been bugs in Erlang itself regarding that particular hook. It might be something we will be able to fix eventually. > 2. What might "writer,send_failed,badarg" as the termination reason > suggest as the root cause? > 3. Prior the the shutdown, what is the meaning of: > > exception on TCP connection <0.2021.0> from 10.30.33.169:3251 > {timeout,running} > exception on TCP connection <0.1707.0> from 10.30.32.44:2692 > connection_closed_abruptly We think that you have heartbeats turned on. Heartbeats are quite unreliable under Windows, especially when the machine is loaded, because of schedular issues. Try turning heartbeats off (has to be done from each client). In later releases of Rabbit (and its clients), we disabled heartbeats by default. 1.6.0 is quite old - we'd recommend you upgrade to 1.7.2 if you can. Matthew From jzaugg at gmail.com Fri May 14 14:20:14 2010 From: jzaugg at gmail.com (Jason Zaugg) Date: Fri, 14 May 2010 15:20:14 +0200 Subject: [rabbitmq-discuss] Unexplained shutdown of RabbitMQ In-Reply-To: <20100514120431.GJ20620@mrnibble.lshift.net> References: <20100514120431.GJ20620@mrnibble.lshift.net> Message-ID: On Fri, May 14, 2010 at 2:04 PM, Matthew Sackman wrote: >> 1. Can we configure RabbitMQ to suppress logging of the message queue >> when this error occurs. > Unfortunately not. We would like to fix that ourselves too and there's > meant to be a hook to be able to control that but there've been reports > that there've been bugs in Erlang itself regarding that particular hook. > It might be something we will be able to fix eventually. No matter. Grep will do for now. >> 2. What might "writer,send_failed,badarg" as the termination reason >> suggest as the root cause? >> 3. Prior the the shutdown, what is the meaning of: >> >> ? exception on TCP connection <0.2021.0> from 10.30.33.169:3251 >> ? {timeout,running} >> ? exception on TCP connection <0.1707.0> from 10.30.32.44:2692 >> ? connection_closed_abruptly > > We think that you have heartbeats turned on. Heartbeats are quite > unreliable under Windows, especially when the machine is loaded, because > of schedular issues. Try turning heartbeats off (has to be done from > each client). In later releases of Rabbit (and its clients), we disabled > heartbeats by default. 1.6.0 is quite old - we'd recommend you upgrade > to 1.7.2 if you can. I looked at the apps a bit further, and they are using 1.5.4 of the Java client, and the heartbeat is left at the default of 3 seconds. Unfortuantely we need to rebuild the app to change the heartbeat, as we didn't expose it as a property. The trunk versions of the apps have been updated to 1.7.0, and we plan to upgrade the broker soon. The system is running smoothly again, so in the short term we'll: - monitor for the next few days - patch our apps to disable heartbeat if we hit problems again - upgrade the clients and broker if this still is unstable. Thanks for the help, Jason From majek04 at gmail.com Fri May 14 15:52:38 2010 From: majek04 at gmail.com (Marek Majkowski) Date: Fri, 14 May 2010 15:52:38 +0100 Subject: [rabbitmq-discuss] rabbitmq-memcached protocol adapter Message-ID: Hi, I just found rabbitmq-memcached project, by Flier Lu: http://code.google.com/p/rabbitmq-memcached/ This project is s simple RabbitMQ plugin, that opens port 11211 and exposes some AMQP commands over memcached protocol. The code is pretty simple and looks straightforward. >From what I can see, it currently supports only SET and GET operations. SET(key, value) sends a message to an exchange "key", with the payload of "value" GET(key) pops a message from a queue "key". The installation follows normal plugin installation guidelines (a recent erlang/otp might be required). Here's my python session, as a prerequisite I set up a queue "d", a fanout exchange "d+e" and a binding between them: >>> import memcache >>> mc = memcache.Client(["127.0.0.1:11211"]) >>> mc.set("d+e", "payload") True >>> mc.get("d") 'payload' Cheers, Marek From vivek at khera.org Fri May 14 16:14:07 2010 From: vivek at khera.org (Vick Khera) Date: Fri, 14 May 2010 11:14:07 -0400 Subject: [rabbitmq-discuss] Using RabbitMQ like ICE or WCF duplex communication channel In-Reply-To: References: <28508178.post@talk.nabble.com> <4BEC7515.8000908@wetafx.co.nz> <28553182.post@talk.nabble.com> Message-ID: On Thu, May 13, 2010 at 6:19 PM, Alexis Richardson wrote: > Have a read of this: http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ > This is a great intro article. It should probably be the top of the "overview" list on the getting started page rather than way down the list :-) From irrer at umich.edu Fri May 14 23:21:48 2010 From: irrer at umich.edu (Jim Irrer) Date: Fri, 14 May 2010 18:21:48 -0400 Subject: [rabbitmq-discuss] getting a list of exchanges with Java client api Message-ID: Hi - Given a queue, is there a method in the Java client API that gets all of the exchanges associated with that queue? Thanks, - Jim Jim Irrer irrer at umich.edu (734) 647-4409 University of Michigan Hospital Radiation Oncology 519 W. William St. Ann Arbor, MI 48103 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100514/f3bc79cb/attachment.htm From tonyg at lshift.net Fri May 14 23:52:55 2010 From: tonyg at lshift.net (Tony Garnock-Jones) Date: Sat, 15 May 2010 10:52:55 +1200 Subject: [rabbitmq-discuss] getting a list of exchanges with Java client api In-Reply-To: References: Message-ID: <4BEDD447.1080403@lshift.net> Hi Jim, I'm afraid there isn't. The AMQP spec doesn't provide any method for listing exchanges, queues, or bindings, and while RabbitMQ provides rabbitmqctl, we haven't (yet) exposed it over the normal AMQP wire protocol. One important reason is security: if attached clients can get a directory of server resources, the use of server-generated (or otherwise cryptographically unguessable) queue names as capabilities is compromised. So in our thinking about exposing such management-y features over the wire, we've mainly been concerned with appropriate ways of restricting the features to authorised connections only. Regards, Tony Jim Irrer wrote: > Hi - > > Given a queue, is there a method in the Java client API that > gets all of the exchanges associated with that queue? > > Thanks, > > - Jim > > Jim Irrer irrer at umich.edu (734) 647-4409 > University of Michigan Hospital Radiation Oncology > 519 W. William St. Ann Arbor, MI 48103 > > > ------------------------------------------------------------------------ > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From tonyg at lshift.net Sat May 15 00:21:30 2010 From: tonyg at lshift.net (Tony Garnock-Jones) Date: Sat, 15 May 2010 11:21:30 +1200 Subject: [rabbitmq-discuss] RabbitMQ on Fedora 12 with default Erlang packages Message-ID: <4BEDDAFA.2000501@lshift.net> Hi all, In an IRC discussion yesterday it came to light that Fedora's most recent Erlang packaging is a little buggy. The erlang-os_mon-R13B-04.10.fc12.x86_64 package includes an os_mon.app which refers to the nteventlog module (a standard Erlang module) in its {modules,[]} clause, but in a change from previous releases, does not include the module itself. This causes the following error when starting RabbitMQ: {"init terminating in do_boot",{{nocatch,{error,{cannot_start_application,rabbit,{bad_return,{{rabbit,start,[normal,[]]},{'EXIT',{undef,[{nteventlog,module_info,[attributes]},{rabbit,'-boot_steps/0-fun-0-',1},{lists,flatmap,2},{lists,flatmap,2},{rabbit,boot_steps,0},{rabbit,start,2},{application_master,start_it_old,4}]}}}}}}},[{init,start_it,1},{init,start_em,1}]}} Arguably, RabbitMQ should not be affected by such bugs in the hosting Erlang environment, so I'm going to change the code to ignore missing modules like that, but in the meantime, affected users will need to edit the file /usr/lib/erlang/lib/os_mon-2.2.5/ebin/os_mon.app or /usr/lib64/erlang/lib/os_mon-2.2.5/ebin/os_mon.app depending on whether your Fedora is 32- or 64-bit. Edit the clause {modules, [os_mon, os_mon_mib, os_sup, disksup, memsup, cpu_sup, os_mon_sysinfo, nteventlog]}, so that it reads {modules, [os_mon, os_mon_mib, os_sup, disksup, memsup, cpu_sup, os_mon_sysinfo]}, save it, and quit. After this change, RabbitMQ should start normally. Regards, Tony From celldee at gmail.com Sat May 15 08:50:01 2010 From: celldee at gmail.com (Chris Duncan) Date: Sat, 15 May 2010 08:50:01 +0100 Subject: [rabbitmq-discuss] Bunny fork In-Reply-To: References: Message-ID: Hi, David has done some fantastic work and has been keeping me up to date on his progress. With his help, I will endeavour to incorporate the most useful changes into the main branch. I'll be making announcements in the Google group (http:// groups.google.com/group/bunny-amqp), as well as on GitHub (http:// github.com/celldee/bunny). If you want to contribute to Bunny or comment on what you would like to see in the next release, please see the project page in GitHub for the appropriate links. Sorry if this discussion is not deemed pertinent to this mailing list. I have copied it the Bunny mailing list, so discussion can continue there if need be. Regards, Chris On 14 May 2010, at 12:41, David MacIver wrote: > Hi everyone, > > This is just a heads up in case anyone finds themselves in a similar > position to me: I've been using Bunny (Chris Duncan's Ruby AMQP > client) on a work project, and it's largely been great, but I've run > into a few issues, so I've created a fork which fixes them: > http://github.com/DRMacIver/bunny > > Differences from the current released version: > > Improvements: > > * Flow control is supported (the released version will crash when > rabbit sends flow control messages) > * Somewhat better error diagnostics when things go wrong > * Subscriptions are much more powerful - they're essentially fully > supported - you can subscribe to multiple queues, mix subscriptions > and other messages, etc. The API is quite rough at the moment and I'll > probably be tinkering with it a reasonable amount, but it does work. > * A few miscellaneous bug fixes (e.g. Bunny 0.6 will create malformed > headers for some tables when the values are Bignums) > > Incompatibilities: > > * 0.9.1 support is totally ripped out > * some of the old subscription behaviour is gone - max_message, > unsubscribe automatically on exiting the loop, etc. This was largely > because they interact poorly with the changes I made to support more > general subscriptions. Basic operation is *largely* compatible, but > there are a fair few differences. > * a bunch of files have moved about so if you're relying on bunny > internals your code will almost certainly break. > > One massive caveat: I'm not planning to maintain this in any official > capacity. Chris has done a great job with Bunny, and is a much more > responsible maintainer than I'm likely to be. These are really just > the fixes I needed to get things done, and my long term goal is > definitely to try to get all these improvements merged back into the > Bunny mainline, but that's not straightforward at the moment due to > the various features I bulldozed out of the way in my hurry to get > this done. I'm simply letting people know that this exists in case you > need some of these fixes now and are willing to risk running > unreleased code to get them. > > Regards, > David > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From celldee at gmail.com Sat May 15 09:28:35 2010 From: celldee at gmail.com (Chris Duncan) Date: Sat, 15 May 2010 09:28:35 +0100 Subject: [rabbitmq-discuss] RabbitMQ AMQP 0-9-1 spec branch Message-ID: Hi, Up until now I have tested against the AMQP 0-9-1 spec RabbitMQ branch as well as 0-8. What are the plans for the 0-9-1 branch? Is there going to be a RabbitMQ 0-9-1 stable release? I don't see much point in continuing to support something that is not going to be included in a stable release. Regards, Chris From lemenkov at gmail.com Sat May 15 15:45:45 2010 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sat, 15 May 2010 18:45:45 +0400 Subject: [rabbitmq-discuss] Regarding latest Fedora 12 & Fedora 13 Erlang R13B-04 packaging bug (nteventlog missing) Message-ID: Hello All! Sorry for this issue - that was completely my fault. I'll provide new packages very soon. As Tony already mentioned, until new fixed package will arrive, affected Fedora users may edit their %{_libdir}/erlang/lib/os_mon-2.2.5/ebin/os_mon.app file and remove mentioning of nteventlog from here. Again, sorry for this inconvenience. -- With best regards, Peter Lemenkov. From matthew at lshift.net Sat May 15 17:55:16 2010 From: matthew at lshift.net (Matthew Sackman) Date: Sat, 15 May 2010 17:55:16 +0100 Subject: [rabbitmq-discuss] RabbitMQ AMQP 0-9-1 spec branch In-Reply-To: References: Message-ID: <20100515165516.GA6485@wellquite.org> Hi Chris, On Sat, May 15, 2010 at 09:28:35AM +0100, Chris Duncan wrote: > Up until now I have tested against the AMQP 0-9-1 spec RabbitMQ > branch as well as 0-8. What are the plans for the 0-9-1 branch? Is > there going to be a RabbitMQ 0-9-1 stable release? I don't see much > point in continuing to support something that is not going to be > included in a stable release. Our current plans (and note, these can change, and there are not firm estimates attached to these) are that the next major release will be the new persister, and the following major release will be the 0-9-1 work. So yes, we are very much committed to the 0-9-1 branch which is receiving attention now. We are not quite sure just yet whether to attempt to do multi-protocol (i.e. support 0-8 and 0-9-1 in the same product) or just drop support for 0-8 all together. 0-9-1 is really a clarification of 0-8 and in nearly all cases where 0-8 is more ambiguous than 0-9-1, we implement the semantics of 0-9-1. Therefore, the impact to client libraries to move to 0-9-1 should not be a huge amount of work - obviously all our client libraries will be 0-9-1 ready, and it sounds like the Ruby client is as well (David - please do *not* drop support for 0-9-1!). There's also an arguement for saying that old, likely buggy, and unmaintained clients which are currently 0-8 only will either die or be rewritten to support 0-9-1 - that is a good outcome. On the other hand, if you, as users of Rabbit and client libraries, are dependent on a 0-8 client, and moving to 0-9-1 is going to be a massive issue for you, please let us know - we don't want to cause problems for people, and certainly don't want to alienate users or the many many members of this community who have contributed their time, effort and coding prowess. That said, there is an attraction to forcing some of the client libraries to receive some attention - for example a number of our users run into issues because the particular client library they're using still doesn't support channel.flow. It would definitely be a good thing if moving to 0-9-1 and dropping support for 0-8 would cause those libraries to be fixed up, by more than just a change to the version in the protocol negotiation. As always, your comments and thoughts are very valuable to us. Matthew From matthew at lshift.net Sat May 15 21:22:54 2010 From: matthew at lshift.net (Matthew Sackman) Date: Sat, 15 May 2010 21:22:54 +0100 Subject: [rabbitmq-discuss] New persister (bug21673) crashed In-Reply-To: <20100418162850.GA23773@wellquite.org> References: <20100418162850.GA23773@wellquite.org> Message-ID: <20100515202254.GB6485@wellquite.org> On Sun, Apr 18, 2010 at 05:28:51PM +0100, Matthew Sackman wrote: > On Sun, Apr 18, 2010 at 08:50:14AM -0700, Scott White wrote: > > I am running the new persister and after running fine for several > > weeks, it > > crashed last night. Please see crash low below. I'm not sure how to > > interpret this, any ideas what the problem might be? > > Yes, it recovered more off disk than it was expecting to. I have no idea > how that could happen...[snipped] I do now. During QA of the new persister this afternoon, Matthias spotted a simple accountancy error in the queue index module. See the commit comment for the gory details (3e0e01f3591e), but suffice to say, this would be able to cause the crash that you reported. The circumstances that would cause this are that Rabbit would have had to have died suddenly (either crashed or be killed) during flushing of the queue index journal (which is an internal operation which happens from time to time), on a durable queue with persistent messages. I have to say, I think this is excellent means of justification for the extensive QA process that's been going on of the new persister. Of the ~7000 new lines of code that make up the new persister, we're down to just two modules left to QA, with about 2500 lines in total to go. There is most certainly light at the end of the tunnel - I know many of you have been working off the new persister branch for a long time now and yet more of you just waiting for us to release it. Much progress has been made in the last month, and we really are getting there now. Hopefully not too much longer! Matthew From techabc at gmail.com Sun May 16 06:12:09 2010 From: techabc at gmail.com (techabc) Date: Sun, 16 May 2010 13:12:09 +0800 Subject: [rabbitmq-discuss] RabbitMQ AMQP 0-9-1 spec branch In-Reply-To: <20100515165516.GA6485@wellquite.org> References: <20100515165516.GA6485@wellquite.org> Message-ID: and what prepears on the amqp 1.0 PR3 or later? 2010/5/16 Matthew Sackman : > Hi Chris, > > On Sat, May 15, 2010 at 09:28:35AM +0100, Chris Duncan wrote: >> Up until now I have tested against the AMQP 0-9-1 spec RabbitMQ >> branch as well as 0-8. What are the plans for the 0-9-1 branch? Is >> there going to be a RabbitMQ 0-9-1 stable release? I don't see much >> point in continuing to support something that is not going to be >> included in a stable release. > > Our current plans (and note, these can change, and there are not > firm estimates attached to these) are that the next major release will > be the new persister, and the following major release will be the 0-9-1 > work. So yes, we are very much committed to the 0-9-1 branch which is > receiving attention now. We are not quite sure just yet whether to > attempt to do multi-protocol (i.e. support 0-8 and 0-9-1 in the same > product) or just drop support for 0-8 all together. > > 0-9-1 is really a clarification of 0-8 and in nearly all cases where 0-8 > is more ambiguous than 0-9-1, we implement the semantics of 0-9-1. > Therefore, the impact to client libraries to move to 0-9-1 should not be > a huge amount of work - obviously all our client libraries will be 0-9-1 > ready, and it sounds like the Ruby client is as well (David - please do > *not* drop support for 0-9-1!). There's also an arguement for saying > that old, likely buggy, and unmaintained clients which are currently 0-8 > only will either die or be rewritten to support 0-9-1 - that is a good > outcome. > > On the other hand, if you, as users of Rabbit and client libraries, are > dependent on a 0-8 client, and moving to 0-9-1 is going to be a massive > issue for you, please let us know - we don't want to cause problems for > people, and certainly don't want to alienate users or the many many > members of this community who have contributed their time, effort and > coding prowess. That said, there is an attraction to forcing some of the > client libraries to receive some attention - for example a number of our > users run into issues because the particular client library they're > using still doesn't support channel.flow. It would definitely be a good > thing if moving to 0-9-1 and dropping support for 0-8 would cause those > libraries to be fixed up, by more than just a change to the version in > the protocol negotiation. > > As always, your comments and thoughts are very valuable to us. > > Matthew > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > From david at rabbitmq.com Sun May 16 09:41:25 2010 From: david at rabbitmq.com (David Wragg) Date: Sun, 16 May 2010 09:41:25 +0100 Subject: [rabbitmq-discuss] Bound Queues In-Reply-To: (Vick Khera's message of "Thu\, 13 May 2010 10\:39\:55 -0400") References: <4BC3D9E4.8030804@lshift.net> <28538369.post@talk.nabble.com> <4BEADD3B.9040109@cloudeventprocessing.com> <28541854.post@talk.nabble.com> Message-ID: Hi Vick, Vick Khera writes: > Anyone know if Theo's Net::RabbitMQ perl module honors the > channel.flow? It appears to be built upon the C client. librabbitmq does nothing to handle channel.flow itself. I think it's theoretically possible for an application or library built on librabbitmq to handle channel.flow, but I'd be surprised if any did so. I took a quick look at Net::RabbitMQ, and it doesn't seem to. David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware From matthew at lshift.net Sun May 16 09:49:25 2010 From: matthew at lshift.net (Matthew Sackman) Date: Sun, 16 May 2010 09:49:25 +0100 Subject: [rabbitmq-discuss] RabbitMQ AMQP 0-9-1 spec branch In-Reply-To: References: <20100515165516.GA6485@wellquite.org> Message-ID: <20100516084925.GA10400@wellquite.org> On Sun, May 16, 2010 at 01:12:09PM +0800, techabc wrote: > and what prepears on the amqp 1.0 PR3 or later? There is still substantial ongoing discussion around the makeup, composition and semantics of the PR3 document, and it is yet to be ratified by the working group. As such, we are very much still in the earliest possible stages surronding any attempt to implement it. Matthew From celldee at gmail.com Sun May 16 16:07:25 2010 From: celldee at gmail.com (Chris Duncan) Date: Sun, 16 May 2010 16:07:25 +0100 Subject: [rabbitmq-discuss] RabbitMQ AMQP 0-9-1 spec branch In-Reply-To: <20100515165516.GA6485@wellquite.org> References: <20100515165516.GA6485@wellquite.org> Message-ID: Thanks Matthew. I'll proceed with 0-9-1 support intact. I'll wait to see how the 1-0 spec progresses before trying to get my head around that. Regards, Chris On 15 May 2010, at 17:55, Matthew Sackman wrote: > Hi Chris, > > On Sat, May 15, 2010 at 09:28:35AM +0100, Chris Duncan wrote: >> Up until now I have tested against the AMQP 0-9-1 spec RabbitMQ >> branch as well as 0-8. What are the plans for the 0-9-1 branch? Is >> there going to be a RabbitMQ 0-9-1 stable release? I don't see much >> point in continuing to support something that is not going to be >> included in a stable release. > > Our current plans (and note, these can change, and there are not > firm estimates attached to these) are that the next major release will > be the new persister, and the following major release will be the > 0-9-1 > work. So yes, we are very much committed to the 0-9-1 branch which is > receiving attention now. We are not quite sure just yet whether to > attempt to do multi-protocol (i.e. support 0-8 and 0-9-1 in the same > product) or just drop support for 0-8 all together. > > 0-9-1 is really a clarification of 0-8 and in nearly all cases > where 0-8 > is more ambiguous than 0-9-1, we implement the semantics of 0-9-1. > Therefore, the impact to client libraries to move to 0-9-1 should > not be > a huge amount of work - obviously all our client libraries will be > 0-9-1 > ready, and it sounds like the Ruby client is as well (David - > please do > *not* drop support for 0-9-1!). There's also an arguement for saying > that old, likely buggy, and unmaintained clients which are > currently 0-8 > only will either die or be rewritten to support 0-9-1 - that is a good > outcome. > > On the other hand, if you, as users of Rabbit and client libraries, > are > dependent on a 0-8 client, and moving to 0-9-1 is going to be a > massive > issue for you, please let us know - we don't want to cause problems > for > people, and certainly don't want to alienate users or the many many > members of this community who have contributed their time, effort and > coding prowess. That said, there is an attraction to forcing some > of the > client libraries to receive some attention - for example a number > of our > users run into issues because the particular client library they're > using still doesn't support channel.flow. It would definitely be a > good > thing if moving to 0-9-1 and dropping support for 0-8 would cause > those > libraries to be fixed up, by more than just a change to the version in > the protocol negotiation. > > As always, your comments and thoughts are very valuable to us. > > Matthew > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From RadhakrishnanD at ivycomptech.com Mon May 17 10:30:19 2010 From: RadhakrishnanD at ivycomptech.com (Radha Krishnan D) Date: Mon, 17 May 2010 15:00:19 +0530 Subject: [rabbitmq-discuss] RabbitMQ Clustering Message-ID: <49A7BA114AAC6A48B9C44CB06B7B987E0A341B1E@HYDSVWIN004X.ivycomptech.partygaming.local> Hi, Am trying to cluster two rabbitmq servers running on two independent nodes, Node 1 terminal -------------------- [root at morungole sbin]# rabbitmqctl status ./.. Status of node rabbit at morungole ... [{running_applications,[{rabbit,"RabbitMQ","1.7.2"}, {mnesia,"MNESIA CXC 138 12","4.4.7"}, {os_mon,"CPO CXC 138 46","2.1.8"}, {sasl,"SASL CXC 138 11","2.1.5.4"}, {stdlib,"ERTS CXC 138 10","1.15.5"}, {kernel,"ERTS CXC 138 10","2.12.5"}]}, {nodes,[rabbit at morungole]}, {running_nodes,[rabbit at morungole]}] ...done. Node 2 terminal -------------------------- [root at mocovir2 sbin]# rabbitmqctl -n MocovirRabbit at mocovir2 status Status of node 'MocovirRabbit at mocovir2' ... [{running_applications,[{rabbit,"RabbitMQ","1.7.2"}, {mnesia,"MNESIA CXC 138 12","4.4.12"}, {os_mon,"CPO CXC 138 46","2.2.4"}, {sasl,"SASL CXC 138 11","2.1.8"}, {stdlib,"ERTS CXC 138 10","1.16.4"}, {kernel,"ERTS CXC 138 10","2.13.4"}]}, {nodes,['MocovirRabbit at mocovir2']}, {running_nodes,['MocovirRabbit at mocovir2']}] ...done. [root at mocovir2 sbin]# rabbitmqctl -n MocovirRabbit at mocovir2 stop_app Stopping node 'MocovirRabbit at mocovir2' ... ...done. [root at mocovir2 sbin]# rabbitmqctl -n MocovirRabbit at mocovir2 reset Resetting node 'MocovirRabbit at mocovir2' ... ...done. [root at mocovir2 sbin]# rabbitmqctl -n MocovirRabbit at mocovir2 cluster rabbit at morungole Clustering node 'MocovirRabbit at mocovir2' with [rabbit at morungole] ... ...done. [root at mocovir2 sbin]# rabbitmqctl -n MocovirRabbit at mocovir2 start_app Starting node 'MocovirRabbit at mocovir2' ... ...done. [root at mocovir2 sbin]# rabbitmqctl -n MocovirRabbit at mocovir2 status Status of node 'MocovirRabbit at mocovir2' ... [{running_applications,[{rabbit,"RabbitMQ","1.7.2"}, {mnesia,"MNESIA CXC 138 12","4.4.12"}, {os_mon,"CPO CXC 138 46","2.2.4"}, {sasl,"SASL CXC 138 11","2.1.8"}, {stdlib,"ERTS CXC 138 10","1.16.4"}, {kernel,"ERTS CXC 138 10","2.13.4"}]}, {nodes,['MocovirRabbit at mocovir2']}, {running_nodes,['MocovirRabbit at mocovir2']}] ...done. Even though it is telling Clustering is done. Both the rabbitmq nodes are not able to recognize each other. Can you please tell me where am going wrong ?\ The .erlang.cookie in $HOME was not same at the beginning . Then i copied the .erlang.cookie content from Node 1 (rabbit at morungole) to Node 2 ( MocovirRabbit at mocovir2 ) Thanks and Regards, D.Radhakrishnan Trainee Engineer-Architecture IVY Comptech Private Limited Cyber Spazio,Road No 2, Banjara Hills, Hyderabad-500034, Andhra Pradesh. Phone + 91 (40) 66721000 - 4638 Mobile + 91 (0) 9030842104 This email and any attachments are confidential, legally privileged and protected by copyright. If you are not the intended recipient, dissemination or copying this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorized. Any actions taken on the basis of this email are at recipient's own risk. This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy Comptech Private Limited is a limited liability company. This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract on behalf of Ivy Comptech Private Limited unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. Registered office: Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, Hyderabad 500 033, Andhra Pradesh, India. Registered number: 37994. Registered in India. A list of members' names is available for inspection at the registered office. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100517/67973722/attachment-0001.htm From lists at zopyx.com Mon May 17 19:36:41 2010 From: lists at zopyx.com (Andreas Jung) Date: Mon, 17 May 2010 20:36:41 +0200 Subject: [rabbitmq-discuss] High-number of unack-ed messages In-Reply-To: <20100513134024.GD20620@mrnibble.lshift.net> References: <4BEBCE1C.7040808@zopyx.com> <20100513134024.GD20620@mrnibble.lshift.net> Message-ID: <4BF18CB9.10809@zopyx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Sackman wrote: > Hi Andreas, > > On Thu, May 13, 2010 at 12:02:04PM +0200, Andreas Jung wrote: >> I inserted some 500k messages with one produce into the queue. >> Then I attached one consumer to the queue feeding the messages into >> Solr. The consumer is implemented as callback using the Carrot bindings >> for Python. Every message is directly acknowledged. However "Alice" >> always shows me between 300 and 500 unacknowledged messages. Shouldn't >> that number be 0 or 1? > > Well. It should be low, but if there's no QoS being set by Alice then it > can get quite high. I would only trust it to be 0 or 1 if Alice was also > setting a QoS prefetch of 1, and even then, there are cases where the > unack count can be higher than that. > > After Alice had drained all 500k messages, was the unack count still > high, or had it dropped to 0 by then? > Since I am not very happy with Alice+Wonderland I would like bring the discussion back the point: what is the easiest way for getting hold of the queue names, the number of messages in each queue and the number of unacknowledged messages? rabbitctl seems to expose only queue names and the number of messages but not the number of unack-ed messages. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvxjLkACgkQCJIWIbr9KYxioQCeMLYYSrsTTmXsG5i1sa/wi/mp T7YAoL25EuCObjZ5rbj/oIb5JkEP6K1m =+mNG -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: lists.vcf Type: text/x-vcard Size: 316 bytes Desc: not available Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100517/c7f79b57/attachment.vcf From matthew at lshift.net Mon May 17 19:56:48 2010 From: matthew at lshift.net (Matthew Sackman) Date: Mon, 17 May 2010 19:56:48 +0100 Subject: [rabbitmq-discuss] High-number of unack-ed messages In-Reply-To: <4BF18CB9.10809@zopyx.com> References: <4BEBCE1C.7040808@zopyx.com> <20100513134024.GD20620@mrnibble.lshift.net> <4BF18CB9.10809@zopyx.com> Message-ID: <20100517185648.GA25918@wellquite.org> On Mon, May 17, 2010 at 08:36:41PM +0200, Andreas Jung wrote: > Since I am not very happy with Alice+Wonderland I would like bring > the discussion back the point: what is the easiest way for getting hold > of the queue names, the number of messages in each queue and the number > of unacknowledged messages? rabbitctl seems to expose only queue names > and the number of messages but not the number of unack-ed messages. Please read the manual. rabbitmqctl: list_queues [-p ] [ ...] must be a member of the list [name, durable, auto_delete, arguments, pid, owner_pid, exclusive_consumer_pid, exclusive_consumer_tag, messages_ready, messages_unacknowledged, messages, consumers, memory]. messages_unacknowledged is what you're after. You probably want in total: rabbitmqctl list_queues name messages_ready messages_unacknowledged as "messages" on its own is messages_ready + messages_unacknowledged. Matthew From pathsny at gmail.com Tue May 18 11:42:47 2010 From: pathsny at gmail.com (vishnu) Date: Tue, 18 May 2010 16:12:47 +0530 Subject: [rabbitmq-discuss] publishing inside a transaction before acking Message-ID: we have scenarios where we pick up a message at a time, perform a bunch of operations, publish a new message and then ack the message we just picked up. Recently we have started to publish the new message inside a transaction since this guarantees that the message is persisted (it's a persistent message), since we want to minimize the odds of message loss. However, we have started to notice that the original message we pick up is marked as unacknowledged after we complete our process. Is there something fundamentally wrong in what we're doing, or is our approach correct? thanks Vishnu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100518/011b2c08/attachment.htm From mikeb at rabbitmq.com Tue May 18 12:04:15 2010 From: mikeb at rabbitmq.com (Michael Bridgen) Date: Tue, 18 May 2010 12:04:15 +0100 Subject: [rabbitmq-discuss] publishing inside a transaction before acking In-Reply-To: References: Message-ID: <4BF2742F.1050604@rabbitmq.com> vishnu wrote: > we have scenarios where we pick up a message at a time, perform a bunch > of operations, publish a new message and then ack the message we just > picked up. Recently we have started to publish the new message inside a > transaction since this guarantees that the message is persisted (it's a > persistent message), since we want to minimize the odds of message loss. > However, we have started to notice that the original message we pick up > is marked as unacknowledged after we complete our process. Is there > something fundamentally wrong in what we're doing, or is our approach > correct? The approach is correct. What order are you doing things in? Transactions are implicitly started immediately after a commit or rollback, and acknowledgements are transactional, so if you're committing after the publish but before the ack -- basic.publish(new_message) tx.commit() basic.ack(old_message) the state at this point is a published message, and an uncommitted transaction with the ack. If you do this: basic.publish(new_message) basic.ack(old_message) tx.commit() then you'll have atomically acked the old message and published the new one; which is, I believe, what you want. Michael. From matthias at rabbitmq.com Tue May 18 12:09:08 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Tue, 18 May 2010 12:09:08 +0100 Subject: [rabbitmq-discuss] Bound Queues In-Reply-To: References: <4BC3D9E4.8030804@lshift.net> <28538369.post@talk.nabble.com> <4BEADD3B.9040109@cloudeventprocessing.com> <28541854.post@talk.nabble.com> Message-ID: <4BF27554.7030402@rabbitmq.com> Vick, Vick Khera wrote: > What if my producers used the "mandatory" flag to detect if the queue > is full, and then just pause for a while if it is? I think you mean the "immediate" flag. Yes, that would sort of work but if all producers do the same, all the time, then rabbit would never queue any messages at all. I'm guessing that is probably not what you want. > If I use a large-RAM box for my queue server, will rabbitmq use more > of it? Yes. As long as you are on a 64-bit Unix with a recent version of Erlang. Matthias. From matthias at rabbitmq.com Tue May 18 12:14:10 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Tue, 18 May 2010 12:14:10 +0100 Subject: [rabbitmq-discuss] init terminating in do_boot In-Reply-To: References: <09037F769A7E474A972B1A77B851155301C56017@radsvr01.radiusit.local> Message-ID: <4BF27682.4000207@rabbitmq.com> Scott, Robert Raschke wrote: > > wrote: > I have just freshly installed rabbitmq-server-1.7.2-1.fc12.x86_64 > for my Fedora 12 box. > [...] > {"init terminating in > do_boot",{{nocatch,{error,{cannot_start_application,rabbit,{bad_return,{{rabbit,start,[normal,[]]},{'EXIT',{undef,[{nteventlog,module_info,[attributes]},{rabbit,'-boot_steps/0-fun-0-',1},{lists,flatmap,2},{lists,flatmap,2},{rabbit,boot_steps,0},{rabbit,start,2},{application_master,start_it_old,4}]}}}}}}},[{init,start_it,1},{init,start_em,1}]}}^M > [...] > For some reason it's trying to do something with the nteventlog module. > As you're on Fedora, I don't think that can be right. See http://old.nabble.com/RabbitMQ-on-Fedora-12-with-default-Erlang-packages-td28565195.html and http://old.nabble.com/Regarding-latest-Fedora-12---Fedora-13-Erlang-R13B-04-packaging-bug-%28nteventlog-missing%29-td28568861.html We have since taught rabbit to ignore the above error, so if you install rabbit from source it should work fine. Or, as Peter suggests, edit the installed os_mon.app file. Regards, Matthias. From mutazmq at gmail.com Tue May 18 12:29:13 2010 From: mutazmq at gmail.com (Mutaz Qasem) Date: Tue, 18 May 2010 15:29:13 +0400 Subject: [rabbitmq-discuss] RabbitMQ on Mac Message-ID: Hi I'm trying to install rabbitmq_server-1.7.2 on Mac 1.6.3 (Snow Leopard). I've tried both "Mac ports" and "homebrew" and every time I get the same error. I tried to edit my /etc/hosts but nothing could help! Thank you Mutaz This is the error output I get in the terminal when I do sudo rabbitmq-server: {error_logger,{{2010,5,18},{ 15,23,48}},"Protocol: ~p: register error: ~p~n",["inet_tcp",{{badmatch,{error,duplicate_name}},[{inet_tcp_dist,listen,1},{net_kernel,start_protos,4},{net_kernel,start_protos,3},{net_kernel,init_node,2},{net_kernel,init,1},{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}]} {error_logger,{{2010,5,18},{15,23,48}},supervisor_report,[{supervisor,{local,net_sup}},{errorContext,start_error},{reason,{'EXIT',nodistribution}},{offender,[{pid,undefined},{name,net_kernel},{mfa,{net_kernel,start_link,[[rabbit,shortnames]]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]}]} {error_logger,{{2010,5,18},{15,23,48}},crash_report,[[{initial_call,{net_kernel,init,['Argument__1']}},{pid,<0.21.0>},{registered_name,[]},{error_info,{exit,{error,badarg},[{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}},{ancestors,[net_sup,kernel_sup,<0.10.0>]},{messages,[]},{links,[#Port<0.147>,<0.18.0>]},{dictionary,[{longnames,false}]},{trap_exit,true},{status,running},{heap_size,377},{stack_size,24},{reductions,509}],[]]} {error_logger,{{2010,5,18},{15,23,48}},supervisor_report,[{supervisor,{local,kernel_sup}},{errorContext,start_error},{reason,shutdown},{offender,[{pid,undefined},{name,net_sup},{mfa,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]}]} {error_logger,{{2010,5,18},{15,23,48}},std_info,[{application,kernel},{exited,{shutdown,{kernel,start,[normal,[]]}}},{type,permanent}]} {"Kernel pid terminated",application_controller,"{application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}"} Crash dump was written to: erl_crash.dump Kernel pid terminated (application_controller) ({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100518/1251b29b/attachment.htm From david at drmaciver.com Tue May 18 12:43:21 2010 From: david at drmaciver.com (David MacIver) Date: Tue, 18 May 2010 12:43:21 +0100 Subject: [rabbitmq-discuss] RabbitMQ AMQP 0-9-1 spec branch In-Reply-To: <20100515165516.GA6485@wellquite.org> References: <20100515165516.GA6485@wellquite.org> Message-ID: On 15 May 2010 17:55, Matthew Sackman wrote: > 0-9-1 is really a clarification of 0-8 and in nearly all cases where 0-8 > is more ambiguous than 0-9-1, we implement the semantics of 0-9-1. > Therefore, the impact to client libraries to move to 0-9-1 should not be > a huge amount of work - obviously all our client libraries will be 0-9-1 > ready, and it sounds like the Ruby client is as well (David - please do > *not* drop support for 0-9-1!). There's also an arguement for saying If I'm the David being referred to here, I should clarify why I ripped out the 0-9-1 support in my fork of bunny. In particular it's very much not because I think it's a bad medium to long term goal. The issue from my point of view was that multiprotocol support was complicating the client implementation significantly (perhaps this doesn't inherently have to be the case, but I thought it was here), and that I felt that maintaining a separate branch with the 0.9.1 support was a better way to go. Given that there was currently no production ready version of 0-9-1 I didn't think it was worth the effort to set up that branch now, but as it gets closer to release time for it I'll do everything I can to make sure that there is a 0-9-1 capable version of Bunny with my changes in place. It should be noted that there's also a great deal of expediency issues to be considered in my bunny fork. A lot of the changes are very much aaaahhhhineedthistoworkrightnow stuff we're discovering as we start to rely on bunny and rabbitmq more heavily, so they don't always reflect the long term best behaviour. From david at drmaciver.com Tue May 18 12:46:35 2010 From: david at drmaciver.com (David MacIver) Date: Tue, 18 May 2010 12:46:35 +0100 Subject: [rabbitmq-discuss] RabbitMQ AMQP 0-9-1 spec branch In-Reply-To: References: <20100515165516.GA6485@wellquite.org> Message-ID: I should also say that if Chris is still convinced that multiprotocol support in the same client library is the way to go I'll do my best to support that as well, despite my disagreement on the subject. :-) From keith.davies at trafigura.com Tue May 18 13:18:47 2010 From: keith.davies at trafigura.com (Keith Davies) Date: Tue, 18 May 2010 13:18:47 +0100 Subject: [rabbitmq-discuss] Cloning RHEL VM's with pre-installed Rabbit. Message-ID: <635E976302C55647BE5A8369ACBB5122011D02AE1079@TTRAFLONVS01.global.trafigura.com> Hi Rabbit users and gurus, I've not posted a question on this mailing list before so apologies if I'm not following the correct procedure!!. Anyway I am on a new development project and we are using Rabbit. I have encountered a slight issue and would be grateful for any advice on the mater, or some pointers in the right direction. We have a number of development and qa environments. We have created a VMWare image with Rabbit pre-installed. In order to create a new environment we have been cloning this image. What we are finding is that all the clones seem to be finding each other and joining together to create a cluster. Although we will most likely want this behaviour when we go to production we would like our development and qa environments to be completely stand alone. Ideally we would also like to change the VMWare image so that all clones get this behaviour by default without any manual intervention. Our clustering behaviour may be due to the fact that all our clones are have the same ".erlang.cookie". My question to you guys is. Is there a preferred approach to being able to deal with Rabbit and VMWare images. Alternatively is there a way to ensure clustering is turned off in our VMWare image. Apologies if this is a really simple question but I am relatively new to the clustering side of Rabbit. Thanks very much in advance. Keith ________________________________ This email and any attachments are confidential and access to this email or attachment by anyone other than the addressee is unauthorised. If you are not the intended recipient please notify the sender and delete the email including any attachments. You must not disclose or distribute any of the contents to any other person. Personal views or opinions are solely those of the author and not of Trafigura. Trafigura does not guarantee that the integrity of this communication has been maintained nor that the communication is free of viruses, interceptions or interference. By communicating with anyone at Trafigura by email, you consent to the monitoring or interception of such email by Trafigura in accordance with its internal policies. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100518/463f3a16/attachment-0001.htm From david at rabbitmq.com Tue May 18 13:24:11 2010 From: david at rabbitmq.com (David Wragg) Date: Tue, 18 May 2010 13:24:11 +0100 Subject: [rabbitmq-discuss] RabbitMQ on Mac In-Reply-To: (Mutaz Qasem's message of "Tue\, 18 May 2010 15\:29\:13 +0400") References: Message-ID: Hi Mutaz, Mutaz Qasem writes: > This is the error output I get in the terminal when I do sudo > rabbitmq-server: > > {error_logger,{{2010,5,18},{ > 15,23,48}},"Protocol: ~p: register error: > ~p~n",["inet_tcp",{{badmatch,{error,duplicate_name}},[{inet_tcp_dist,listen,1},{net_kernel,start_protos,4},{net_kernel,start_protos,3},{net_kernel,init_node,2},{net_kernel,init,1},{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}]} This error means that another Erlang node with the same name is already running. Which probably means that rabbitmq-server is already running. Stop the existing rabbit process (probably by just killing it, if its origin is a mystery), and it should resolve this error. David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware From vivek at khera.org Tue May 18 19:49:21 2010 From: vivek at khera.org (Vick Khera) Date: Tue, 18 May 2010 14:49:21 -0400 Subject: [rabbitmq-discuss] Bound Queues In-Reply-To: <4BF27554.7030402@rabbitmq.com> References: <4BC3D9E4.8030804@lshift.net> <28538369.post@talk.nabble.com> <4BEADD3B.9040109@cloudeventprocessing.com> <28541854.post@talk.nabble.com> <4BF27554.7030402@rabbitmq.com> Message-ID: On Tue, May 18, 2010 at 7:09 AM, Matthias Radestock wrote: > Vick Khera wrote: >> >> What if my producers used the "mandatory" flag to detect if the queue >> ?is full, and then just pause for a while if it is? > > I think you mean the "immediate" flag. Yes, that would sort of work but if > all producers do the same, all the time, then rabbit would never queue any > messages at all. I'm guessing that is probably not what you want. > I would hope that my consumer would eventually clear up the queue enough that the producers can start up again. I'd have the producers sleep some random amount of time to eliminate the thundering herd. >> If I use a large-RAM box for my queue server, will rabbitmq use more >> of it? > > Yes. As long as you are on a 64-bit Unix with a recent version of Erlang. > Excellent. Thanks for the info. From tyler at echonest.com Tue May 18 19:58:45 2010 From: tyler at echonest.com (tyler at echonest.com) Date: Tue, 18 May 2010 14:58:45 -0400 (EDT) Subject: [rabbitmq-discuss] Erlang has closed? Message-ID: Hello, I'm running the latest stable version of rabbitmq (1.7.2) and the latest erlang (R13B04) on a ubuntu server machine (2.6.31-14-server x86_64). I'm having a problem where if I load rabbitmq heavily, it will die with the console message: "Erlang has closed." I still see beam.smp running, but I can't connect to rabbit at all, and there is nothing in rabbit.log or rabbit-sasl.log. Is there a good way to debug this? Can I somehow put rabbitmq in debug mode, or do i need to recompile erlang for debugging...? Any help is appreciated! Thanks From vivek at khera.org Tue May 18 20:07:02 2010 From: vivek at khera.org (Vick Khera) Date: Tue, 18 May 2010 15:07:02 -0400 Subject: [rabbitmq-discuss] Erlang has closed? In-Reply-To: References: Message-ID: On Tue, May 18, 2010 at 2:58 PM, tyler at echonest.com wrote: > > I'm having a problem where if I load rabbitmq heavily, it will die with > the console message: "Erlang has closed." I still see beam.smp running, > but I can't connect to rabbit at all, and there is nothing in rabbit.log > or rabbit-sasl.log. I'm sure others have seen this, but Reddit is complaining that rabbitmq is crashing under their loads as well: http://blog.reddit.com/2010/05/reddits-may-2010-state-of-servers.html (scroll down to the heading "she must have been pregnant"). From matthias at rabbitmq.com Tue May 18 20:20:40 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Tue, 18 May 2010 20:20:40 +0100 Subject: [rabbitmq-discuss] Bound Queues In-Reply-To: References: <4BC3D9E4.8030804@lshift.net> <28538369.post@talk.nabble.com> <4BEADD3B.9040109@cloudeventprocessing.com> <28541854.post@talk.nabble.com> <4BF27554.7030402@rabbitmq.com> Message-ID: <4BF2E888.5060708@rabbitmq.com> Vick, Vick Khera wrote: > On Tue, May 18, 2010 at 7:09 AM, Matthias Radestock > wrote: >> Vick Khera wrote: >>> What if my producers used the "mandatory" flag to detect if the queue >>> is full, and then just pause for a while if it is? >> I think you mean the "immediate" flag. Yes, that would sort of work but if >> all producers do the same, all the time, then rabbit would never queue any >> messages at all. I'm guessing that is probably not what you want. >> > I would hope that my consumer would eventually clear up the queue > enough that the producers can start up again. That wasn't my point. If all producers publish messages with the immediate flag set all the time then rabbit will return - rather than enqueue - the published messages if they cannot be delivered to a consumer straight away. Nothing would get queued, ever. ...except rabbit has to hold on to delivered but unacknowledged messages, which actually uncovers another issue with this scheme: there is no bound to the volume of messages that may have been sent out to consumers but remain unacknowledged. You could set a prefetch window with basic.qos though, or use auto-ack. Anyway, if you are concerned about overloading the broker, then handling channel.flow is by far the best available option. Regards, Matthias. From matthias at rabbitmq.com Tue May 18 20:26:40 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Tue, 18 May 2010 20:26:40 +0100 Subject: [rabbitmq-discuss] Erlang has closed? In-Reply-To: References: Message-ID: <4BF2E9F0.6050809@rabbitmq.com> tyler at echonest.com wrote: > I'm running the latest stable version of rabbitmq (1.7.2) and the latest > erlang (R13B04) on a ubuntu server machine (2.6.31-14-server x86_64). > > I'm having a problem where if I load rabbitmq heavily, it will die with > the console message: "Erlang has closed." I still see beam.smp running, > but I can't connect to rabbit at all, and there is nothing in rabbit.log > or rabbit-sasl.log. Is there really *nothing* in these logs? If there is, please upload the contents somewhere we can see it. Also, what client library are you using? Regards, Matthias. From tyler at echonest.com Tue May 18 20:44:08 2010 From: tyler at echonest.com (tyler at echonest.com) Date: Tue, 18 May 2010 15:44:08 -0400 (EDT) Subject: [rabbitmq-discuss] Erlang has closed? In-Reply-To: <4BF2E9F0.6050809@rabbitmq.com> References: <4BF2E9F0.6050809@rabbitmq.com> Message-ID: On Tue, 18 May 2010, Matthias Radestock wrote: > tyler at echonest.com wrote: >> I'm running the latest stable version of rabbitmq (1.7.2) and the latest >> erlang (R13B04) on a ubuntu server machine (2.6.31-14-server x86_64). >> >> I'm having a problem where if I load rabbitmq heavily, it will die with the >> console message: "Erlang has closed." I still see beam.smp running, but I >> can't connect to rabbit at all, and there is nothing in rabbit.log or >> rabbit-sasl.log. > > Is there really *nothing* in these logs? If there is, please upload the > contents somewhere we can see it. > > Also, what client library are you using? > > Regards, > > Matthias. > rabbit-sasl.log is completely empty. rabbit.log has a few of the following: =ERROR REPORT==== 18-May-2010::14:22:52 === exception on TCP connection <0.2078.0> from 192.168.1.138:63015 {handshake_timeout,handshake} =INFO REPORT==== 18-May-2010::14:22:53 === closing TCP connection <0.2078.0> from 192.168.1.138:63015 I've posted the last 1000 lines here: http://pastebin.com/bPChQrgN For a client library, I'm using py-amqplib (.5). Thanks, Tyler From matthias at rabbitmq.com Tue May 18 20:54:42 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Tue, 18 May 2010 20:54:42 +0100 Subject: [rabbitmq-discuss] Erlang has closed? In-Reply-To: References: <4BF2E9F0.6050809@rabbitmq.com> Message-ID: <4BF2F082.1070602@rabbitmq.com> tyler at echonest.com wrote: > rabbit-sasl.log is completely empty. rabbit.log has a few of the following: > > =ERROR REPORT==== 18-May-2010::14:22:52 === > exception on TCP connection <0.2078.0> from 192.168.1.138:63015 > {handshake_timeout,handshake} > > =INFO REPORT==== 18-May-2010::14:22:53 === > closing TCP connection <0.2078.0> from 192.168.1.138:63015 > > I've posted the last 1000 lines here: http://pastebin.com/bPChQrgN It looks like you are establishing quite a lot of connections concurrently and either the clients or the server is getting too busy to complete the connection establishment handshake in the allocated time. Is the server process busy? And how much memory is it using? And if you stop connecting - make sure there are no more connection messages appearing in the log - does the server eventually recover? Regards, Matthias. From vivek at khera.org Tue May 18 23:11:26 2010 From: vivek at khera.org (Vick Khera) Date: Tue, 18 May 2010 18:11:26 -0400 Subject: [rabbitmq-discuss] Bound Queues In-Reply-To: <4BF2E888.5060708@rabbitmq.com> References: <4BC3D9E4.8030804@lshift.net> <28538369.post@talk.nabble.com> <4BEADD3B.9040109@cloudeventprocessing.com> <28541854.post@talk.nabble.com> <4BF27554.7030402@rabbitmq.com> <4BF2E888.5060708@rabbitmq.com> Message-ID: On Tue, May 18, 2010 at 3:20 PM, Matthias Radestock wrote: > That wasn't my point. If all producers publish messages with the immediate > flag set all the time then rabbit will return - rather than enqueue - the > published messages if they cannot be delivered to a consumer straight away. > Nothing would get queued, ever. > Ah. I get it now. That plan was flawed... :-( I will figure out how to handle channel.flow in perl client. From aquino.gustavo at gmail.com Wed May 19 02:51:47 2010 From: aquino.gustavo at gmail.com (Gustavo Aquino) Date: Tue, 18 May 2010 22:51:47 -0300 Subject: [rabbitmq-discuss] Consumer stop to receive messages but continue listening queue problem. In-Reply-To: <7fd310d11003261315m39a8d63eo11e36e72e9308e62@mail.gmail.com> References: <5ef296b31003111900r577611f7vf1a2bdf1b4752db1@mail.gmail.com> <20100312122432.GA25615@mrnibble.lshift.net> <5ef296b31003120621m13c87cbdy677adc7425be4eb1@mail.gmail.com> <5ef296b31003130445o2775b12eyf16547c6e2c52682@mail.gmail.com> <5ef296b31003221225u77bf25a8g13a1e7340d06eff0@mail.gmail.com> <4BAC95B7.70203@lshift.net> <7fd310d11003260633q1e9a163fse3c4df928598e57a@mail.gmail.com> <20100326181130.GA2622@wellquite.org> <7fd310d11003261315m39a8d63eo11e36e72e9308e62@mail.gmail.com> Message-ID: Hi, I come back here about this assumption, it's a big concern today for us. Let's explain the facts. We have 1 exchange e 1 persistent queue binding for routing key = book.APPL We have a publisher putting messages from exchange, each message have ~213 bytes and each routing key identify the goup of message like book.APPL, book.PETR4 and etc. We are publishing about ~3000 m/s We have one consumer listening queue. The problem. We put test to run for 1 hour, and monitoring queue size with rabbitmqctl list_queues, all the time list have 0 size, so consumer are getting all on the fly, and now we stop publisher and here is the BIG PROBLEM, consumer continue to consume messages from queue... and it's remain for 20 minutes after stop publisher...... If we stop consumer we can see the queue growing for long time..., therefore looking for it's we can conclude that our consumer are 20 minutes late behind publisher and it's a f... problem last message from publisher will be received by consumer just 20 minutes after. About environments. We are using a P550 Machine with 4 PPC64 processors 5.4Ghz, and 100Gb of ram, during our tests it's have just 20% of processor busy, and 2Gb of memory allocated. We are using Red Hat 5 for ppc in our tests. We replicate this scenario using Intel x86_64 with Red Hat linux for 64bits, and Real Time Kernel, this machine have 8 cores and 32Gb of ram, and during the tests it consume just 25% of CPU and 2Gb of ram. So can anyone help me ? Its's a common problem in Rabbit ? anybody here have this same problem ? We have talked about a possible exchange buffer cause and etc in this way, but to be sincerely in my thoughts ~3000 m/s is a bit easy to be processed for one message server. Gustavo. On Fri, Mar 26, 2010 at 5:15 PM, Bryan Murphy wrote: > Make sense, although we don't care about the order so it doesn't affect us > so much. > > Bryan > > > On Fri, Mar 26, 2010 at 1:11 PM, Matthew Sackman wrote: > >> Hi, >> >> On Fri, Mar 26, 2010 at 08:33:19AM -0500, Bryan Murphy wrote: >> > Another technique we use: >> > >> > Start one consumer. >> > >> > Start your other consumers. >> > >> > Restart the first consumer. >> > >> > This let's you keep the high prefetch settings while still getting the >> > messages to distribute more evenly. >> >> I would not recommend that at all - you're likely to get messages in >> different orders with this scheme. QoS is much better idea, or, use >> channel.flow from the client (may only work in newer-than-1.7.2 - can't >> remember when it appeared) to prevent any messages being sent out >> *before* issuing the basic.consume. >> >> You could then have either a delay or some signal through some other >> exchange and queues (and channel) to get the clients to drop the >> channel.flow and start consuming. >> >> Matthew >> > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100518/e9420aaa/attachment-0001.htm From matthias at rabbitmq.com Wed May 19 05:20:10 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Wed, 19 May 2010 05:20:10 +0100 Subject: [rabbitmq-discuss] Consumer stop to receive messages but continue listening queue problem. In-Reply-To: References: <5ef296b31003111900r577611f7vf1a2bdf1b4752db1@mail.gmail.com> <20100312122432.GA25615@mrnibble.lshift.net> <5ef296b31003120621m13c87cbdy677adc7425be4eb1@mail.gmail.com> <5ef296b31003130445o2775b12eyf16547c6e2c52682@mail.gmail.com> <5ef296b31003221225u77bf25a8g13a1e7340d06eff0@mail.gmail.com> <4BAC95B7.70203@lshift.net> <7fd310d11003260633q1e9a163fse3c4df928598e57a@mail.gmail.com> <20100326181130.GA2622@wellquite.org> <7fd310d11003261315m39a8d63eo11e36e72e9308e62@mail.gmail.com> Message-ID: <4BF366FA.5000602@rabbitmq.com> Gustavo, Gustavo Aquino wrote: > We put test to run for 1 hour, and monitoring queue size with > rabbitmqctl list_queues, all the time list have 0 size, so consumer are > getting all on the fly, and now we stop publisher and here is the BIG > PROBLEM, consumer continue to consume messages from queue... and it's > remain for 20 minutes after stop publisher...... > > If we stop consumer we can see the queue growing for long time..., > therefore looking for it's we can conclude that our consumer are 20 > minutes late behind publisher and it's a f... problem last message from > publisher will be received by consumer just 20 minutes after. How are the messages being consumed? Using basic.consume? If so then the above observation is consistent with messages getting buffered in the network and/or consumers. How are you monitoring the queue lengths? The default output of 'rabbitmqctl list_queues' will give a figure that is the sum of ready, unacknowledged and uncommitted messages. You can get a more detailed breakdown with s.t. like 'rabbitmqctl list_queues name messages_ready messages_unacknowledged messages_uncommitted' - see http://www.rabbitmq.com/admin-guide.html#list_queues. If my above analysis is correct then for the total to be zero the clients would have to be consuming messages in no-ack mode, since otherwise the messages_unacknowledged count would go up. Are they? > So can anyone help me ? Its's a common problem in Rabbit ? anybody here > have this same problem ? We have talked about a possible exchange buffer > cause and etc in this way, but to be sincerely in my thoughts ~3000 m/s > is a bit easy to be processed for one message server. It looks like rabbit is handling the load just fine, but the consumers are struggling to keep up and are just buffering the messages. This can happen easily if the consumer code is employing s.t. like the QueueingConsumer in our Java client library - http://www.rabbitmq.com/releases/rabbitmq-java-client/v1.7.2/rabbitmq-java-client-javadoc-1.7.2/com/rabbitmq/client/QueueingConsumer.html But it can also happen just through buffering in the network layers. To avoid a large backlog building up, probably the easiest solution is to set a prefetch limit with basic.qos. But for that to be effective the consumers must be consuming in ack mode. Regards, Matthias. From pathsny at gmail.com Wed May 19 07:00:51 2010 From: pathsny at gmail.com (vishnu) Date: Wed, 19 May 2010 11:30:51 +0530 Subject: [rabbitmq-discuss] publishing inside a transaction before acking In-Reply-To: References: <4BF2742F.1050604@rabbitmq.com> Message-ID: resending this to the list :) On Tue, May 18, 2010 at 7:59 PM, vishnu wrote: > well actually we're doing > basic.consume > > some stuff > tx.select > basic.publish > tx.commit > > some stuff > basic.ack > > currently, we're trying to make sure the publish is inside a transaction. > > On Tue, May 18, 2010 at 4:34 PM, Michael Bridgen wrote: > >> vishnu wrote: >> > we have scenarios where we pick up a message at a time, perform a bunch >> > of operations, publish a new message and then ack the message we just >> > picked up. Recently we have started to publish the new message inside a >> > transaction since this guarantees that the message is persisted (it's a >> > persistent message), since we want to minimize the odds of message loss. >> > However, we have started to notice that the original message we pick up >> > is marked as unacknowledged after we complete our process. Is there >> > something fundamentally wrong in what we're doing, or is our approach >> > correct? >> >> The approach is correct. What order are you doing things in? >> Transactions are implicitly started immediately after a commit or >> rollback, and acknowledgements are transactional, so if you're >> committing after the publish but before the ack -- >> >> basic.publish(new_message) >> tx.commit() >> basic.ack(old_message) >> >> the state at this point is a published message, and an uncommitted >> transaction with the ack. If you do this: >> >> basic.publish(new_message) >> basic.ack(old_message) >> tx.commit() >> >> then you'll have atomically acked the old message and published the new >> one; which is, I believe, what you want. >> >> >> Michael. >> >> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100519/8017f715/attachment.htm From matthias at rabbitmq.com Wed May 19 07:22:57 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Wed, 19 May 2010 07:22:57 +0100 Subject: [rabbitmq-discuss] publishing inside a transaction before acking In-Reply-To: References: <4BF2742F.1050604@rabbitmq.com> Message-ID: <4BF383C1.6060205@rabbitmq.com> vishnu wrote: > well actually we're doing > basic.consume > > some stuff > tx.select > basic.publish > tx.commit > > some stuff > basic.ack > > currently, we're trying to make sure the publish is inside a > transaction. As Michael pointed out ... Transactions are implicitly started immediately after a commit or rollback, and acknowledgements are transactional, so if you're committing after the publish but before the ack [which is exactly what you are doing] then the state at this point is a published message, and an uncommitted transaction with the ack. Unless the code does a subsequent commit the ack will be lost. You either need to a) issue a second commit, after the ack, b) move the ack to before the first commit, or c) use two channels - one for consuming and acking non-transactionally, and the other for publishing transactionally. Regards, Matthias. From mikeb at rabbitmq.com Wed May 19 10:20:32 2010 From: mikeb at rabbitmq.com (Michael Bridgen) Date: Wed, 19 May 2010 10:20:32 +0100 Subject: [rabbitmq-discuss] publishing inside a transaction before acking In-Reply-To: References: <4BF2742F.1050604@rabbitmq.com> Message-ID: <4BF3AD60.1040406@rabbitmq.com> > On Tue, May 18, 2010 at 7:59 PM, vishnu > wrote: > > well actually we're doing > basic.consume > > some stuff > tx.select > basic.publish > tx.commit > > some stuff > basic.ack > > currently, we're trying to make sure the publish is inside a > transaction. Right, that fits the first pattern. You will want to move the ack inside the transaction. Then the ack of the old incoming message will happen atomically with publishing the outgoing message, and you won't see a published outgoing message along with an unacked incoming message. basic.consume some stuff tx.select basic.publish some stuff basic.ack tx.commit Michael. > On Tue, May 18, 2010 at 4:34 PM, Michael Bridgen > wrote: > > vishnu wrote: > > we have scenarios where we pick up a message at a time, > perform a bunch > > of operations, publish a new message and then ack the message > we just > > picked up. Recently we have started to publish the new > message inside a > > transaction since this guarantees that the message is > persisted (it's a > > persistent message), since we want to minimize the odds of > message loss. > > However, we have started to notice that the original message > we pick up > > is marked as unacknowledged after we complete our process. Is > there > > something fundamentally wrong in what we're doing, or is our > approach > > correct? > > The approach is correct. What order are you doing things in? > Transactions are implicitly started immediately after a commit or > rollback, and acknowledgements are transactional, so if you're > committing after the publish but before the ack -- > > basic.publish(new_message) > tx.commit() > basic.ack(old_message) > > the state at this point is a published message, and an uncommitted > transaction with the ack. If you do this: > > basic.publish(new_message) > basic.ack(old_message) > tx.commit() > > then you'll have atomically acked the old message and published > the new > one; which is, I believe, what you want. > > > Michael. > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From mutazmq at gmail.com Wed May 19 10:37:19 2010 From: mutazmq at gmail.com (Mutaz Qasem) Date: Wed, 19 May 2010 13:37:19 +0400 Subject: [rabbitmq-discuss] RabbitMQ on Mac In-Reply-To: References: Message-ID: Hi David Thanks a lot for the quick reply! Yeah you are right, it was fine when I killed the process. I'm very new to RabbitMQ, but wouldn't be better if the message was clearly pointing that out? Thanks a gain Mutaz On Tue, May 18, 2010 at 4:24 PM, David Wragg wrote: > Hi Mutaz, > > Mutaz Qasem writes: > > This is the error output I get in the terminal when I do sudo > > rabbitmq-server: > > > > {error_logger,{{2010,5,18},{ > > 15,23,48}},"Protocol: ~p: register error: > > > ~p~n",["inet_tcp",{{badmatch,{error,duplicate_name}},[{inet_tcp_dist,listen,1},{net_kernel,start_protos,4},{net_kernel,start_protos,3},{net_kernel,init_node,2},{net_kernel,init,1},{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}]} > > This error means that another Erlang node with the same name is > already running. Which probably means that rabbitmq-server is already > running. Stop the existing rabbit process (probably by just killing > it, if its origin is a mystery), and it should resolve this error. > > David > > -- > David Wragg > Staff Engineer, RabbitMQ > SpringSource, a division of VMware > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100519/86b267cf/attachment.htm From mikeb at rabbitmq.com Wed May 19 10:48:11 2010 From: mikeb at rabbitmq.com (Michael Bridgen) Date: Wed, 19 May 2010 10:48:11 +0100 Subject: [rabbitmq-discuss] [Alice] Proper configuration? In-Reply-To: <4BEA3B62.3040005@zopyx.com> References: <4BEA3B62.3040005@zopyx.com> Message-ID: <4BF3B3DB.6090703@rabbitmq.com> Hi Andreas, > trying to get Alice > running with RabbitMQ. > > Starting Alice fails: > [...] > *WARNING* alice: Source code not found: alice_app.erl > *WARNING* alice: Source code not found: alice_log.erl > *WARNING* alice: Source code not found: rest_app.erl I'm not sure about the above, but this: > {error_logger,{{2010,5,12},{7,23,7}},"Protocol: ~p: register error: > ~p~n",["inet_tcp",{{badmatch,{error,duplicate_name}},[{inet_tcp_dist,listen,1},{net_kernel,start_protos,4},{net_kernel,start_protos,3},{net_kernel,init_node,2},{net_kernel,init,1},{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}]} suggests there's already a running Alice node. Is there a stop.sh? You may need to kill it. > {error_logger,{{2010,5,12},{7,23,7}},crash_report,[[{initial_call,{net_kernel,init,['Argument__1']}},{pid,<0.21.0>},{registered_name,[]},{error_info,{exit,{error,badarg},[{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}},{ancestors,[net_sup,kernel_sup,<0.8.0>]},{messages,[]},{links,[#Port<0.120>,<0.18.0>]},{dictionary,[{longnames,true}]},{trap_exit,true},{status,running},{heap_size,610},{stack_size,24},{reductions,459}],[]]} > {error_logger,{{2010,5,12},{7,23,7}},supervisor_report,[{supervisor,{local,net_sup}},{errorContext,start_error},{reason,{'EXIT',nodistribution}},{offender,[{pid,undefined},{name,net_kernel},{mfa,{net_kernel,start_link,[[alice,longnames]]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]}]} > {error_logger,{{2010,5,12},{7,23,7}},supervisor_report,[{supervisor,{local,kernel_sup}},{errorContext,start_error},{reason,shutdown},{offender,[{pid,undefined},{name,net_sup},{mfa,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]}]} > {error_logger,{{2010,5,12},{7,23,7}},std_info,[{application,kernel},{exited,{shutdown,{kernel,start,[normal,[]]}}},{type,permanent}]} > {"Kernel pid > terminated",application_controller,"{application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}"} > > Crash dump was written to: erl_crash.dump > Kernel pid terminated (application_controller) > ({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}) > > Anything I am missing? > > Andreas > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkvqO2IACgkQCJIWIbr9KYyw9ACfWZf1E0pnCeoyLl7VCqhKIAQX > +2gAn2ZNEeR7H8XGMFOymyM41VsFnTVL > =OC0A > -----END PGP SIGNATURE----- > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From pathsny at gmail.com Wed May 19 11:30:54 2010 From: pathsny at gmail.com (vishnu) Date: Wed, 19 May 2010 16:00:54 +0530 Subject: [rabbitmq-discuss] publishing inside a transaction before acking In-Reply-To: <4BF3AD60.1040406@rabbitmq.com> References: <4BF2742F.1050604@rabbitmq.com> <4BF3AD60.1040406@rabbitmq.com> Message-ID: aha thanks. I sorta get it now why does rabbitmq implicitly start a transaction after a commit. Does this mean after a commit every single operation now has to be transactional? thanks On Wed, May 19, 2010 at 2:50 PM, Michael Bridgen wrote: > On Tue, May 18, 2010 at 7:59 PM, vishnu > pathsny at gmail.com>> wrote: >> >> well actually we're doing >> basic.consume >> >> some stuff >> tx.select >> basic.publish >> tx.commit >> >> some stuff >> basic.ack >> >> currently, we're trying to make sure the publish is inside a >> transaction. >> > > Right, that fits the first pattern. You will want to move the ack inside > the transaction. Then the ack of the old incoming message will happen > atomically with publishing the outgoing message, and you won't see a > published outgoing message along with an unacked incoming message. > > > basic.consume > > some stuff > tx.select > basic.publish > > some stuff > basic.ack > tx.commit > > > Michael. > > On Tue, May 18, 2010 at 4:34 PM, Michael Bridgen > > wrote: >> >> vishnu wrote: >> > we have scenarios where we pick up a message at a time, >> perform a bunch >> > of operations, publish a new message and then ack the message >> we just >> > picked up. Recently we have started to publish the new >> message inside a >> > transaction since this guarantees that the message is >> persisted (it's a >> > persistent message), since we want to minimize the odds of >> message loss. >> > However, we have started to notice that the original message >> we pick up >> > is marked as unacknowledged after we complete our process. Is >> there >> > something fundamentally wrong in what we're doing, or is our >> approach >> > correct? >> >> The approach is correct. What order are you doing things in? >> Transactions are implicitly started immediately after a commit or >> rollback, and acknowledgements are transactional, so if you're >> committing after the publish but before the ack -- >> >> basic.publish(new_message) >> tx.commit() >> basic.ack(old_message) >> >> the state at this point is a published message, and an uncommitted >> transaction with the ack. If you do this: >> >> basic.publish(new_message) >> basic.ack(old_message) >> tx.commit() >> >> then you'll have atomically acked the old message and published >> the new >> one; which is, I believe, what you want. >> >> >> Michael. >> >> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> >> >> >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> rabbitmq-discuss mailing list >> rabbitmq-discuss at lists.rabbitmq.com >> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100519/612554cb/attachment.htm From matthew at lshift.net Wed May 19 11:33:26 2010 From: matthew at lshift.net (Matthew Sackman) Date: Wed, 19 May 2010 11:33:26 +0100 Subject: [rabbitmq-discuss] publishing inside a transaction before acking In-Reply-To: References: <4BF2742F.1050604@rabbitmq.com> <4BF3AD60.1040406@rabbitmq.com> Message-ID: <20100519103326.GI5583@mrnibble.lshift.net> On Wed, May 19, 2010 at 04:00:54PM +0530, vishnu wrote: > why does rabbitmq implicitly start a transaction after a commit. Does this > mean after a commit every single operation now has to be transactional? Yup. Once a channel has had a tx.select, it is transactional until it is closed. Feel free to use several channels. Matthew From matthias at rabbitmq.com Wed May 19 11:39:13 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Wed, 19 May 2010 11:39:13 +0100 Subject: [rabbitmq-discuss] publishing inside a transaction before acking In-Reply-To: <20100519103326.GI5583@mrnibble.lshift.net> References: <4BF2742F.1050604@rabbitmq.com> <4BF3AD60.1040406@rabbitmq.com> <20100519103326.GI5583@mrnibble.lshift.net> Message-ID: <4BF3BFD1.80207@rabbitmq.com> Matthew Sackman wrote: > On Wed, May 19, 2010 at 04:00:54PM +0530, vishnu wrote: >> why does rabbitmq implicitly start a transaction after a commit. Does this >> mean after a commit every single operation now has to be transactional? > > Yup. Once a channel has had a tx.select, it is transactional until it is > closed. ...and this behaviour is mandated by the AMQP spec, so rabbit has no choice in the matter. Matthias. From emile at rabbitmq.com Wed May 19 13:07:02 2010 From: emile at rabbitmq.com (Emile Joubert) Date: Wed, 19 May 2010 13:07:02 +0100 Subject: [rabbitmq-discuss] RabbitMQ Clustering In-Reply-To: <49A7BA114AAC6A48B9C44CB06B7B987E0A341B1E@HYDSVWIN004X.ivycomptech.partygaming.local> References: <49A7BA114AAC6A48B9C44CB06B7B987E0A341B1E@HYDSVWIN004X.ivycomptech.partygaming.local> Message-ID: <4BF3D466.2080909@rabbitmq.com> Hi Radha, It looks like the version of erlang running on the two hosts are different - can you confirm what version of erlang you are using, and whether the problem occurs if the versions match? Does the logfile contain any relevant information around the time when you execute these commands? -Emile Radha Krishnan D wrote: > > > Hi, > > Am trying to cluster two rabbitmq servers running on two independent nodes, > > > > Node 1 terminal > > -------------------- > > > > [root at morungole sbin]# rabbitmqctl status > > ./.. > > Status of node rabbit at morungole ... > > [{running_applications,[{rabbit,"RabbitMQ","1.7.2"}, > > {mnesia,"MNESIA CXC 138 12","4.4.7"}, > > {os_mon,"CPO CXC 138 46","2.1.8"}, > > {sasl,"SASL CXC 138 11","2.1.5.4"}, > > {stdlib,"ERTS CXC 138 10","1.15.5"}, > > {kernel,"ERTS CXC 138 10","2.12.5"}]}, > > {nodes,[rabbit at morungole]}, > > {running_nodes,[rabbit at morungole]}] > > ...done. > > > > > > Node 2 terminal > > -------------------------- > > > > [root at mocovir2 sbin]# rabbitmqctl -n MocovirRabbit at mocovir2 status > > Status of node 'MocovirRabbit at mocovir2' ... > > [{running_applications,[{rabbit,"RabbitMQ","1.7.2"}, > > {mnesia,"MNESIA CXC 138 12","4.4.12"}, > > {os_mon,"CPO CXC 138 46","2.2.4"}, > > {sasl,"SASL CXC 138 11","2.1.8"}, > > {stdlib,"ERTS CXC 138 10","1.16.4"}, > > {kernel,"ERTS CXC 138 10","2.13.4"}]}, > > {nodes,['MocovirRabbit at mocovir2']}, > > {running_nodes,['MocovirRabbit at mocovir2']}] > > ...done. > > > > [root at mocovir2 sbin]# rabbitmqctl -n MocovirRabbit at mocovir2 > stop_app Stopping node 'MocovirRabbit at mocovir2' ... > > ...done. > > > > [root at mocovir2 sbin]# rabbitmqctl -n MocovirRabbit at mocovir2 > reset Resetting node 'MocovirRabbit at mocovir2' ... > > ...done. > > > > [root at mocovir2 sbin]# rabbitmqctl -n MocovirRabbit at mocovir2 cluster > rabbit at morungole > > Clustering node 'MocovirRabbit at mocovir2' with [rabbit at morungole] ... > > ...done. > > > > [root at mocovir2 sbin]# rabbitmqctl -n MocovirRabbit at mocovir2 start_app > > Starting node 'MocovirRabbit at mocovir2' ... > > ...done. > > > > [root at mocovir2 sbin]# rabbitmqctl -n MocovirRabbit at mocovir2 status > > Status of node 'MocovirRabbit at mocovir2' ... > > [{running_applications,[{rabbit,"RabbitMQ","1.7.2"}, > > {mnesia,"MNESIA CXC 138 12","4.4.12"}, > > {os_mon,"CPO CXC 138 46","2.2.4"}, > > {sasl,"SASL CXC 138 11","2.1.8"}, > > {stdlib,"ERTS CXC 138 10","1.16.4"}, > > {kernel,"ERTS CXC 138 10","2.13.4"}]}, > > {nodes,['MocovirRabbit at mocovir2']}, > > {running_nodes,['MocovirRabbit at mocovir2']}] > > ...done. > > > > > > Even though it is telling Clustering is done. Both the rabbitmq nodes > are not able to recognize each other. > > Can you please tell me where am going wrong ?\ > > The .erlang.cookie in $HOME was not same at the beginning . Then i > copied the .erlang.cookie content from Node 1 (rabbit at morungole) to Node > 2 ( MocovirRabbit at mocovir2 ) > > > > **Thanks and Regards,** > > **D.Radhakrishnan** > Trainee Engineer-Architecture > > *IVY Comptech Private Limited* > Cyber Spazio,Road No 2, Banjara Hills, > Hyderabad-500034, Andhra Pradesh. > > Phone + 91 (40) 66721000 ? 4638 > Mobile + 91 (0) 9030842104 > > This email and any attachments are confidential, legally privileged and > protected by copyright. If you are not the intended recipient, > dissemination or copying this email is prohibited. If you have received > this in error, please notify the sender by replying by email and then > delete the email completely from your system. > > Any views or opinions are solely those of the sender. This > communication is not intended to form a binding contract unless > expressly indicated to the contrary and properly authorized. Any actions > taken on the basis of this email are at recipient?s own risk. > > > > ------------------------------------------------------------------------ > > This email is sent for and on behalf of Ivy Comptech Private Limited. > Ivy Comptech Private Limited is a limited liability company. > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended > recipient dissemination or copying of this email is prohibited. If you > have received this in error, please notify the sender by replying by > email and then delete the email completely from your system. Any views > or opinions are solely those of the sender. This communication is not > intended to form a binding contract on behalf of Ivy Comptech Private > Limited unless expressly indicated to the contrary and properly > authorised. Any actions taken on the basis of this email are at the > recipient's own risk. > > Registered Office: > > Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, > Hyderabad 500 033, Andhra Pradesh, India. > > Registered number: 37994. Registered in India. A list of members' names > is available for inspection at the registered office. > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From tyler at echonest.com Wed May 19 15:45:19 2010 From: tyler at echonest.com (tyler at echonest.com) Date: Wed, 19 May 2010 10:45:19 -0400 (EDT) Subject: [rabbitmq-discuss] Erlang has closed? In-Reply-To: <4BF2F082.1070602@rabbitmq.com> References: <4BF2E9F0.6050809@rabbitmq.com> <4BF2F082.1070602@rabbitmq.com> Message-ID: On Tue, 18 May 2010, Matthias Radestock wrote: > tyler at echonest.com wrote: >> rabbit-sasl.log is completely empty. rabbit.log has a few of the following: >> >> =ERROR REPORT==== 18-May-2010::14:22:52 === >> exception on TCP connection <0.2078.0> from 192.168.1.138:63015 >> {handshake_timeout,handshake} >> >> =INFO REPORT==== 18-May-2010::14:22:53 === >> closing TCP connection <0.2078.0> from 192.168.1.138:63015 >> >> I've posted the last 1000 lines here: http://pastebin.com/bPChQrgN > > It looks like you are establishing quite a lot of connections concurrently > and either the clients or the server is getting too busy to complete the > connection establishment handshake in the allocated time. > > Is the server process busy? And how much memory is it using? > > And if you stop connecting - make sure there are no more connection messages > appearing in the log - does the server eventually recover? > > > Regards, > > Matthias. > The server process does get busy, up to about 80% of the available cpu. It uses all of the available memory, and crashes shortly after. (Shouldn't it be pinning the queues to disk automatically, or do i need to use 21444 for that...?) The server never recovers, even if I kill all producers and most consumers, although the beam.smp process hangs on to all the memory. I'm playing with 21444 now to see if i can replicate this. From matthew at lshift.net Wed May 19 15:55:13 2010 From: matthew at lshift.net (Matthew Sackman) Date: Wed, 19 May 2010 15:55:13 +0100 Subject: [rabbitmq-discuss] Erlang has closed? In-Reply-To: References: <4BF2E9F0.6050809@rabbitmq.com> <4BF2F082.1070602@rabbitmq.com> Message-ID: <20100519145513.GA1896@mrnibble.lshift.net> On Wed, May 19, 2010 at 10:45:19AM -0400, tyler at echonest.com wrote: > The server process does get busy, up to about 80% of the available cpu. > It uses all of the available memory, and crashes shortly after. (Shouldn't > it be pinning the queues to disk automatically, or do i need to use 21444 > for that...?) The new persister will gently push messages to disk when memory gets tight. That is not the behaviour of default branch or any released version of Rabbit. > The server never recovers, even if I kill all producers and most > consumers, although the beam.smp process hangs on to all > the memory. I'm playing with 21444 now to see if i can replicate this. 21444 is ancient and should not be used. If you want to use the new persister, the correct branch is bug21673. Matthew From colin at cloudeventprocessing.com Wed May 19 16:01:35 2010 From: colin at cloudeventprocessing.com (Colin Clark) Date: Wed, 19 May 2010 10:01:35 -0500 Subject: [rabbitmq-discuss] Erlang has closed? In-Reply-To: <20100519145513.GA1896@mrnibble.lshift.net> References: <4BF2E9F0.6050809@rabbitmq.com> <4BF2F082.1070602@rabbitmq.com> <20100519145513.GA1896@mrnibble.lshift.net> Message-ID: <4BF3FD4F.1060003@cloudeventprocessing.com> Matthew - do you have any idea of when the new persister will go 'mainstream?' On 5/19/2010 9:55 AM, Matthew Sackman wrote: > On Wed, May 19, 2010 at 10:45:19AM -0400, tyler at echonest.com wrote: > >> The server process does get busy, up to about 80% of the available cpu. >> It uses all of the available memory, and crashes shortly after. (Shouldn't >> it be pinning the queues to disk automatically, or do i need to use 21444 >> for that...?) >> > The new persister will gently push messages to disk when memory gets > tight. That is not the behaviour of default branch or any released > version of Rabbit. > > >> The server never recovers, even if I kill all producers and most >> consumers, although the beam.smp process hangs on to all >> the memory. I'm playing with 21444 now to see if i can replicate this. >> > 21444 is ancient and should not be used. If you want to use the new > persister, the correct branch is bug21673. > > Matthew > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100519/435b4eb4/attachment.htm From matthew at lshift.net Wed May 19 16:06:27 2010 From: matthew at lshift.net (Matthew Sackman) Date: Wed, 19 May 2010 16:06:27 +0100 Subject: [rabbitmq-discuss] Erlang has closed? In-Reply-To: <4BF3FD4F.1060003@cloudeventprocessing.com> References: <4BF2E9F0.6050809@rabbitmq.com> <4BF2F082.1070602@rabbitmq.com> <20100519145513.GA1896@mrnibble.lshift.net> <4BF3FD4F.1060003@cloudeventprocessing.com> Message-ID: <20100519150626.GB1896@mrnibble.lshift.net> On Wed, May 19, 2010 at 10:01:35AM -0500, Colin Clark wrote: > Matthew - do you have any idea of when the new persister will go > 'mainstream?' Yes. But I've estimated this before and been wildly wrong. Given the progress with the QA of the new persister, and the fact we're basically now down to a little over one module left to go, I'd hope that "under two months" is a sensible estimate. However, it is still an *estimate*. Matthew From tyler at echonest.com Wed May 19 16:06:23 2010 From: tyler at echonest.com (Tyler Williams) Date: Wed, 19 May 2010 11:06:23 -0400 Subject: [rabbitmq-discuss] Erlang has closed? In-Reply-To: <20100519145513.GA1896@mrnibble.lshift.net> References: <4BF2E9F0.6050809@rabbitmq.com> <4BF2F082.1070602@rabbitmq.com> <20100519145513.GA1896@mrnibble.lshift.net> Message-ID: On Wed, May 19, 2010 at 10:55 AM, Matthew Sackman wrote: > On Wed, May 19, 2010 at 10:45:19AM -0400, tyler at echonest.com wrote: >> The server process does get busy, up to about 80% of the available cpu. >> It uses all of the available memory, and crashes shortly after. (Shouldn't >> it be pinning the queues to disk automatically, or do i need to use 21444 >> for that...?) > > The new persister will gently push messages to disk when memory gets > tight. That is not the behaviour of default branch or any released > version of Rabbit. > >> The server never recovers, even if I kill all producers and most >> consumers, ?although the beam.smp process hangs on to all >> the memory. I'm playing with 21444 now to see if i can replicate this. > > 21444 is ancient and should not be used. If you want to use the new > persister, the correct branch is bug21673. > > Matthew > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > Ah ok, good to know. Based on this: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-October/005041.html I thought 21444 might still be the best option for automatically pinning large queues to disk, but I'll give 21673 a try today. Looking closer at the logs for our production rabbit server, which *is* still running 21444, i see that it died with the following messages: =INFO REPORT==== 17-May-2010::14:24:30 === application: rabbit exited: {{timeout_waiting_for_tables,[rabbit_disk_queue]}, {rabbit,start,[normal,[]]}} type: temporary =ERROR REPORT==== 17-May-2010::14:24:30 === Error in process <0.100.0> on node 'rabbit at echonest03' with exit value: {badarg,[{ets,insert,[rabbit_disk_queue,[{dq_msg_loc,{{resource,<<1 byte>>,queue,<<9 bytes>>},553567},false,true,<<16 bytes>>},{dq_msg_loc,{{resource,<<1 byte>>,queue,<<18 bytes>>},563611},false,true,<<16 bytes>>},{dq_msg_loc,{{resource,<<1 byte>>,queue,<<18 bytes>>},80964},false,true,<<16 bytes>>},{dq_msg_loc,{{resource,<<1 byte>>,queue... =INFO REPORT==== 17-May-2010::14:24:33 === application: mnesia exited: stopped type: temporary =INFO REPORT==== 17-May-2010::14:24:33 === application: os_mon exited: stopped type: temporary Can you shed any light on this error? thanks again, --tyler From matthew at lshift.net Wed May 19 16:15:08 2010 From: matthew at lshift.net (Matthew Sackman) Date: Wed, 19 May 2010 16:15:08 +0100 Subject: [rabbitmq-discuss] Erlang has closed? In-Reply-To: References: <4BF2E9F0.6050809@rabbitmq.com> <4BF2F082.1070602@rabbitmq.com> <20100519145513.GA1896@mrnibble.lshift.net> Message-ID: <20100519151508.GC1896@mrnibble.lshift.net> On Wed, May 19, 2010 at 11:06:23AM -0400, Tyler Williams wrote: > =INFO REPORT==== 17-May-2010::14:24:30 === > application: rabbit > exited: {{timeout_waiting_for_tables,[rabbit_disk_queue]}, > {rabbit,start,[normal,[]]}} > type: temporary > > =ERROR REPORT==== 17-May-2010::14:24:30 === > Error in process <0.100.0> on node 'rabbit at echonest03' with exit > value: {badarg,[{ets,insert,[rabbit_disk_queue,[{dq_msg_loc,{{resource,<<1 > byte>>,queue,<<9 bytes>>},553567},false,true,<<16 > bytes>>},{dq_msg_loc,{{resource,<<1 byte>>,queue,<<18 > bytes>>},563611},false,true,<<16 bytes>>},{dq_msg_loc,{{resource,<<1 > byte>>,queue,<<18 bytes>>},80964},false,true,<<16 > bytes>>},{dq_msg_loc,{{resource,<<1 byte>>,queue... > > > =INFO REPORT==== 17-May-2010::14:24:33 === > application: mnesia > exited: stopped > type: temporary > > =INFO REPORT==== 17-May-2010::14:24:33 === > application: os_mon > exited: stopped > type: temporary > > Can you shed any light on this error? I might have been able to last October when I was writing that code. So much has changed since then that I really can't remember too much about what was going on back then. Also, pyamqplib does not support channel.flow. Even with the new persister, there are times where rabbit gets overwhelmed (disks just aren't fast enough most of the time) and so needs to temporarily stop publishers. It does this by using channel.flow. Given that pyamqplib doesn't support channel.flow, you are very likely to run into problems. There's a highly experimental patch by Tony (search the mailing list for it) which adds support for channel.flow, but you might also try looking at the other python clients such as txamqp and pika. Matthew From aquino.gustavo at gmail.com Wed May 19 16:44:52 2010 From: aquino.gustavo at gmail.com (Gustavo Aquino) Date: Wed, 19 May 2010 12:44:52 -0300 Subject: [rabbitmq-discuss] Consumer stop to receive messages but continue listening queue problem. In-Reply-To: <4BF366FA.5000602@rabbitmq.com> References: <5ef296b31003111900r577611f7vf1a2bdf1b4752db1@mail.gmail.com> <5ef296b31003130445o2775b12eyf16547c6e2c52682@mail.gmail.com> <5ef296b31003221225u77bf25a8g13a1e7340d06eff0@mail.gmail.com> <4BAC95B7.70203@lshift.net> <7fd310d11003260633q1e9a163fse3c4df928598e57a@mail.gmail.com> <20100326181130.GA2622@wellquite.org> <7fd310d11003261315m39a8d63eo11e36e72e9308e62@mail.gmail.com> <4BF366FA.5000602@rabbitmq.com> Message-ID: Mathias, On Wed, May 19, 2010 at 1:20 AM, Matthias Radestock wrote: > Gustavo, > > > Gustavo Aquino wrote: > >> We put test to run for 1 hour, and monitoring queue size with rabbitmqctl >> list_queues, all the time list have 0 size, so consumer are getting all on >> the fly, and now we stop publisher and here is the BIG PROBLEM, consumer >> continue to consume messages from queue... and it's remain for 20 minutes >> after stop publisher...... >> >> If we stop consumer we can see the queue growing for long time..., >> therefore looking for it's we can conclude that our consumer are 20 minutes >> late behind publisher and it's a f... problem last message from publisher >> will be received by consumer just 20 minutes after. >> > > How are the messages being consumed? Using basic.consume? If so then the > above observation is consistent with messages getting buffered in the > network and/or consumers. > > Yes, basic consumer have other best way ? If I drop consumer queue continue to grow my friend, withour any consumers or publisher queue size continue to grow for 20 minutes after stop in this scenario. > How are you monitoring the queue lengths? The default output of > 'rabbitmqctl list_queues' will give a figure that is the sum of ready, > unacknowledged and uncommitted messages. You can get a more detailed > breakdown with s.t. like 'rabbitmqctl list_queues name messages_ready > messages_unacknowledged messages_uncommitted' - see > http://www.rabbitmq.com/admin-guide.html#list_queues. > Thanks, I know this extra commands in rabbitmqctl list_queue, now we are using a lot of them. > > If my above analysis is correct then for the total to be zero the clients > would have to be consuming messages in no-ack mode, since otherwise the > messages_unacknowledged count would go up. Are they? > > Rabbitmqctl just show message_ready size, other parameters like messages_unacknowledge and etc all the time are 0. > > So can anyone help me ? Its's a common problem in Rabbit ? anybody here >> have this same problem ? We have talked about a possible exchange buffer >> cause and etc in this way, but to be sincerely in my thoughts ~3000 m/s is a >> bit easy to be processed for one message server. >> > > It looks like rabbit is handling the load just fine, but the consumers are > struggling to keep up and are just buffering the messages. This can happen > easily if the consumer code is employing s.t. like the QueueingConsumer in > our Java client library - > http://www.rabbitmq.com/releases/rabbitmq-java-client/v1.7.2/rabbitmq-java-client-javadoc-1.7.2/com/rabbitmq/client/QueueingConsumer.html > > But it can also happen just through buffering in the network layers. > It?s happened with consumers and without consumer... I don?t think that it as network problem. > > To avoid a large backlog building up, probably the easiest solution is to > set a prefetch limit with basic.qos. But for that to be effective the > consumers must be consuming in ack mode. > > Thanks. > > Regards, > > Matthias. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100519/0392ef79/attachment.htm From colin at cloudeventprocessing.com Wed May 19 18:11:58 2010 From: colin at cloudeventprocessing.com (Colin Clark) Date: Wed, 19 May 2010 12:11:58 -0500 Subject: [rabbitmq-discuss] RabbitMQ won't start on boot Message-ID: <4BF41BDE.5060506@cloudeventprocessing.com> I can't get rabbitmq to start on boot - here's the log file unbuntu 10.04 - rackspace cloud image I installed it fresh after installing erlang =ERROR REPORT==== 19-May-2010::17:07:33 === File operation error: eacces. Target: /etc/hosts. Function: get_file. Process: inet_db. Starting all nodes... Starting node rabbit at telescope-01... {error_logger,{{2010,5,19},{17,7,33}},std_error,"File operation error: eacces. Target: /etc/hosts. Function: get_file. Process: inet_db."} {error_logger,{{2010,5,19},{17,7,33}},"Protocol: ~p: register error: ~p~n",["inet_tcp",{{badmatch,{error,duplicate_name}},[{inet_tcp_dist,listen,1},{net_kernel,start_protos,4},{net_kernel,start_protos,3},{net_kernel,init_node,2},{net_kernel,init,1},{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}]} {error_logger,{{2010,5,19},{17,7,33}},crash_report,[[{initial_call,{net_kernel,init,['Argument__1']}},{pid,<0.22.0>},{registered_name,[]},{error_info,{exit,{error,badarg},[{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}},{ancestors,[net_sup,kernel_sup,<0.10.0>]},{messages,[]},{links,[#Port<0.116>,<0.19.0>]},{dictionary,[{longnames,false}]},{trap_exit,true},{status,running},{heap_size,610},{stack_size,24},{reductions,479}],[]]} {error_logger,{{2010,5,19},{17,7,33}},supervisor_report,[{supervisor,{local,net_sup}},{errorContext,start_error},{reason,{'EXIT',nodistribution}},{offender,[{pid,undefined},{name,net_kernel},{mfa,{net_kernel,start_link,[[rabbit,shortnames]]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]}]} {error_logger,{{2010,5,19},{17,7,33}},supervisor_report,[{supervisor,{local,kernel_sup}},{errorContext,start_error},{reason,shutdown},{offender,[{pid,undefined},{name,net_sup},{mfa,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]}]} {error_logger,{{2010,5,19},{17,7,33}},std_info,[{application,kernel},{exited,{shutdown,{kernel,start,[normal,[]]}}},{type,permanent}]} {"Kernel pid terminated",application_controller,"{application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}"} root at telescope-01:/var/log/rabbitmq# -- Colin +1 701 659 0115 cell +1 701 212 4314 office http://blog.cloudeventprocessing.com http://twitter.com/EventCloudPro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100519/c1402062/attachment.htm From matthias at rabbitmq.com Wed May 19 19:20:43 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Wed, 19 May 2010 19:20:43 +0100 Subject: [rabbitmq-discuss] Consumer stop to receive messages but continue listening queue problem. In-Reply-To: References: <5ef296b31003111900r577611f7vf1a2bdf1b4752db1@mail.gmail.com> <5ef296b31003130445o2775b12eyf16547c6e2c52682@mail.gmail.com> <5ef296b31003221225u77bf25a8g13a1e7340d06eff0@mail.gmail.com> <4BAC95B7.70203@lshift.net> <7fd310d11003260633q1e9a163fse3c4df928598e57a@mail.gmail.com> <20100326181130.GA2622@wellquite.org> <7fd310d11003261315m39a8d63eo11e36e72e9308e62@mail.gmail.com> <4BF366FA.5000602@rabbitmq.com> Message-ID: <4BF42BFB.6010601@rabbitmq.com> Gustavo, Gustavo Aquino wrote: > Yes, basic consumer have other best way ? If I drop consumer queue > continue to grow my friend, withour any consumers or publisher queue > size continue to grow for 20 minutes after stop in this scenario. > [...] > Rabbitmqctl just show message_ready size, other parameters like > messages_unacknowledge and etc all the time are 0. I see. So when you disconnect both the producers and consumers, the messages_ready counts keeps growing for ~20 minutes? You mentioned that the *queue* is "transient". Do you mean non-durable? And what about the messages? Are you publishing them in persistent mode (delivery_mode = 2)? If so, try transient mode (delivery_mode = 1). Also, to help us analyse the problem it would be good if you connected the producers and consumers via the tracer (http://www.rabbitmq.com/examples.html#tracer). There will be a lot of output, but the most interesting parts are the initial moments when the producers and consumers are connecting. Please post that somewhere we can see it. > It?s happened with consumers and without consumer... I don?t think that > it as network problem. Agreed. It looks more like buffering inside rabbit. But there really shouldn't be much of that at a rate as low as your quoted 3kHz. So something isn't right somewhere. Regards, Matthias. From aquino.gustavo at gmail.com Wed May 19 19:30:21 2010 From: aquino.gustavo at gmail.com (Gustavo Aquino) Date: Wed, 19 May 2010 15:30:21 -0300 Subject: [rabbitmq-discuss] Consumer stop to receive messages but continue listening queue problem. In-Reply-To: <4BF42BFB.6010601@rabbitmq.com> References: <5ef296b31003111900r577611f7vf1a2bdf1b4752db1@mail.gmail.com> <5ef296b31003221225u77bf25a8g13a1e7340d06eff0@mail.gmail.com> <4BAC95B7.70203@lshift.net> <7fd310d11003260633q1e9a163fse3c4df928598e57a@mail.gmail.com> <20100326181130.GA2622@wellquite.org> <7fd310d11003261315m39a8d63eo11e36e72e9308e62@mail.gmail.com> <4BF366FA.5000602@rabbitmq.com> <4BF42BFB.6010601@rabbitmq.com> Message-ID: Matthias, On Wed, May 19, 2010 at 3:20 PM, Matthias Radestock wrote: > Gustavo, > > Gustavo Aquino wrote: > >> Yes, basic consumer have other best way ? If I drop consumer queue >> continue to grow my friend, withour any consumers or publisher queue size >> continue to grow for 20 minutes after stop in this scenario. >> [...] Rabbitmqctl just show message_ready size, other parameters like >> messages_unacknowledge and etc all the time are 0. >> > > I see. So when you disconnect both the producers and consumers, the > messages_ready counts keeps growing for ~20 minutes? > Yes. > > You mentioned that the *queue* is "transient". Do you mean non-durable? > Yes. > > And what about the messages? Are you publishing them in persistent mode > (delivery_mode = 2)? If so, try transient mode (delivery_mode = 1). > Transient mode. > > Also, to help us analyse the problem it would be good if you connected the > producers and consumers via the tracer ( > http://www.rabbitmq.com/examples.html#tracer). There will be a lot of > output, but the most interesting parts are the initial moments when the > producers and consumers are connecting. Please post that somewhere we can > see it. > Ok I will do it, and post here. > > It? happened with consumers and without consumer... I don? think that it >> as network problem. >> > > Agreed. It looks more like buffering inside rabbit. But there really > shouldn't be much of that at a rate as low as your quoted 3kHz. So something > isn't right somewhere. > Regards, Gustavo > > Regards, > > Matthias. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100519/b3729bc0/attachment.htm From matthias at rabbitmq.com Wed May 19 19:39:44 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Wed, 19 May 2010 19:39:44 +0100 Subject: [rabbitmq-discuss] Consumer stop to receive messages but continue listening queue problem. In-Reply-To: References: <5ef296b31003111900r577611f7vf1a2bdf1b4752db1@mail.gmail.com> <5ef296b31003221225u77bf25a8g13a1e7340d06eff0@mail.gmail.com> <4BAC95B7.70203@lshift.net> <7fd310d11003260633q1e9a163fse3c4df928598e57a@mail.gmail.com> <20100326181130.GA2622@wellquite.org> <7fd310d11003261315m39a8d63eo11e36e72e9308e62@mail.gmail.com> <4BF366FA.5000602@rabbitmq.com> <4BF42BFB.6010601@rabbitmq.com> Message-ID: <4BF43070.7080801@rabbitmq.com> Gustavo, Gustavo Aquino wrote: > On Wed, May 19, 2010 at 3:20 PM, Matthias Radestock > > wrote: > Also, to help us analyse the problem it would be good if you > connected the producers and consumers via the tracer > (http://www.rabbitmq.com/examples.html#tracer). There will be a lot > of output, but the most interesting parts are the initial moments > when the producers and consumers are connecting. Please post that > somewhere we can see it. > > > Ok I will do it, and post here. The output may be quite large, so I suggest you upload it on the web somewhere and send a link to the list. Matthias. From jon.brisbin at npcinternational.com Wed May 19 20:12:30 2010 From: jon.brisbin at npcinternational.com (Jon Brisbin) Date: Wed, 19 May 2010 14:12:30 -0500 Subject: [rabbitmq-discuss] AMQP 0-9 and C++ support Message-ID: <59D9338A-7C09-4DF7-911E-7F6AC74E4B38@npcinternational.com> Our C++ programmers were wondering when they might be able to catch up to the Java side of things and start using RabbitMQ? :) I'm using it with my vcloud session manager (which works great, BTW! ;) to do non-sticky tcServer sessions and we're also basing our AS/400 trigger program workers on RabbitMQ. The C++ guys want to integrate directly with the server but they're running VisualStudio 2003 and boost/C++, not .NET. They've tried various AMQP clients that have C++ bindings, but almost all of them are 0-9 clients and won't connect to our 1.7.2 RabbitMQ server. I'm going to install the STOMP plugin so they can try that. Is there some kind of timeframe I can give that would offer some assurances that they won't have to just give up on using RabbitMQ and find some awkward workaround? Or is there some production-capable C++ binding I'm not aware of that they could just incorporate right away? Keep in mind they've never done this kind of programming before so the paradigm shift is going to be enough to wrestle with. I'd rather not inflict partially-implemented solutions on them that might give them a bad rash and cause them to swear at me. :) Jon Brisbin Portal Webmaster NPC International, Inc. From vivek at khera.org Wed May 19 20:23:46 2010 From: vivek at khera.org (Vick Khera) Date: Wed, 19 May 2010 15:23:46 -0400 Subject: [rabbitmq-discuss] RabbitMQ won't start on boot In-Reply-To: <4BF41BDE.5060506@cloudeventprocessing.com> References: <4BF41BDE.5060506@cloudeventprocessing.com> Message-ID: is your /etc/hosts file readable by the erlang/rabbitmq process? On Wed, May 19, 2010 at 1:11 PM, Colin Clark wrote: > File operation error: eacces. Target: /etc/hosts. Function: get_file. > Process: inet_db. > From akalend at mail.ru Wed May 19 21:31:33 2010 From: akalend at mail.ru (Alexandre Kalendarev) Date: Thu, 20 May 2010 00:31:33 +0400 Subject: [rabbitmq-discuss] =?windows-1251?q?AMQP_0-9_and_C++_support?= In-Reply-To: <59D9338A-7C09-4DF7-911E-7F6AC74E4B38@npcinternational.com> References: <59D9338A-7C09-4DF7-911E-7F6AC74E4B38@npcinternational.com> Message-ID: Jon, The experimental C++ poject, based on librabbitmq http://code.google.com/p/rabbitcpp/ The example for use is http://code.google.com/p/amqp-rest/. It good work, but no prodaction. If You have any question, send messages. Alexandre > Our C++ programmers were wondering when they might be able to catch up to the Java side of things and start using RabbitMQ? :) > > I'm using it with my vcloud session manager (which works great, BTW! ;) to do non-sticky tcServer sessions and we're also basing our AS/400 trigger program workers on RabbitMQ. The C++ guys want to integrate directly with the server but they're running VisualStudio 2003 and boost/C++, not .NET. They've tried various AMQP clients that have C++ bindings, but almost all of them are 0-9 clients and won't connect to our 1.7.2 RabbitMQ server. I'm going to install the STOMP plugin so they can try that. > > Is there some kind of timeframe I can give that would offer some assurances that they won't have to just give up on using RabbitMQ and find some awkward workaround? Or is there some production-capable C++ binding I'm not aware of that they could just incorporate right away? Keep in mind they've never done this kind of programming before so the paradigm shift is going to be enough to wrestle with. I'd rather not inflict partially-implemented solutions on them that might give them a bad rash and cause them to swear at me. :) > > Jon Brisbin > Portal Webmaster > NPC International, Inc. > > > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss ????????? ?????????? www.eDocs.al.ru From emile at rabbitmq.com Thu May 20 11:47:48 2010 From: emile at rabbitmq.com (Emile Joubert) Date: Thu, 20 May 2010 11:47:48 +0100 Subject: [rabbitmq-discuss] Cloning RHEL VM's with pre-installed Rabbit. In-Reply-To: <635E976302C55647BE5A8369ACBB5122011D02AE1079@TTRAFLONVS01.global.trafigura.com> References: <635E976302C55647BE5A8369ACBB5122011D02AE1079@TTRAFLONVS01.global.trafigura.com> Message-ID: <4BF51354.7060203@rabbitmq.com> Hi Keith, Keith Davies wrote: > We have a number of development and qa environments. We have created a > VMWare image with Rabbit pre-installed. In order to create a new > environment we have been cloning this image. What we are finding is > that all the clones seem to be finding each other and joining together > to create a cluster. Although we will most likely want this behaviour > when we go to production we would like our development and qa > environments to be completely stand alone. Ideally we would also like > to change the VMWare image so that all clones get this behaviour by > default without any manual intervention. Nodes should not cluster automatically without explicit configuration. Can you confirm that the "nodes" and "running_nodes" output from "rabbitmqctl status" contain all the nodes you expect? And what was in the cluster_nodes.config file of the image that got cloned? Are all the hostnames of the cloned images different? > Our clustering behaviour may be due to the fact that all our clones are > have the same ?.erlang.cookie?. Having the same erlang cookie file is necessary, but not sufficient for rabbit clustering. > My question to you guys is. Is there a preferred approach to being able > to deal with Rabbit and VMWare images. Alternatively is there a way to > ensure clustering is turned off in our VMWare image. Apologies if this > is a really simple question but I am relatively new to the clustering > side of Rabbit. Ensuring that hosts have different erlang cookies will prevent clustering. Firewalling the port used by the erlang port mapper (4369 by default) should do the same. But none of that should be necessary if no clustering was set up to start with. Please let us know the outcome or if you have any further questions. Regards Emile From keith.davies at trafigura.com Thu May 20 15:31:41 2010 From: keith.davies at trafigura.com (Keith Davies) Date: Thu, 20 May 2010 15:31:41 +0100 Subject: [rabbitmq-discuss] Cloning RHEL VM's with pre-installed Rabbit. Message-ID: <635E976302C55647BE5A8369ACBB5122011D02D65E41@TTRAFLONVS01.global.trafigura.com> Hi Emile Thanks very much for the reply. Just to let you know we are using rabbit 1.7.1. Anyway in response to your questions if I run the following command on one of our VM's:- ./rabbitmqctl status I get the response:- Status of node rabbit at ttraflonrh320 ... [{running_applications,[{rabbitmq_bql,"RabbitMQ Broker Query Language","0.01"}, {amqp_client,"RabbitMQ AMQP Client","0.0.0"}, {rabbit,"RabbitMQ","1.7.1"}, {os_mon,"CPO CXC 138 46","2.1.8"}, {sasl,"SASL CXC 138 11","2.1.5.4"}, {rfc4627_jsonrpc,"JSON RPC Service","0.01"}, {mnesia,"MNESIA CXC 138 12","4.4.7"}, {stdlib,"ERTS CXC 138 10","1.15.5"}, {kernel,"ERTS CXC 138 10","2.12.5"}]}, {nodes,[rabbit at ttraflonrh320]}, {running_nodes,[rabbit at ttraflonrhtest,rabbit at ttraflonrh324, rabbit at ttraflonrh334,rabbit at ttraflonrh326, rabbit at ttraflonrh331,rabbit at ttraflonrh320]}] Which strikes me a slightly weird as the running nodes do not match up with the nodes. Unfortunately I have not been able to determine from the documentation what this means. In answer to your other question as to the contents of our cluster_nodes.config file. I have searched the entire machine and we do not have this file. Ben Hood from LShift suggested that the behaviour we are seeing may be slightly strange and to post the initial question on the mailing list. Any extra help would be greatly appreciated. We were thinking that it would be ok to ensure the cookie is different on all the machines, but now we are slightly concerned about how we got in this situation in the first place and are worried that there is something wrong with our template installation. What started this investigation off for us in the first place was that we were noticing that when running these environments in parallel our clients which receive messages off rabbit queues were receiving them from different hosts. Thanks again. Keith ________________________________ This email and any attachments are confidential and access to this email or attachment by anyone other than the addressee is unauthorised. If you are not the intended recipient please notify the sender and delete the email including any attachments. You must not disclose or distribute any of the contents to any other person. Personal views or opinions are solely those of the author and not of Trafigura. Trafigura does not guarantee that the integrity of this communication has been maintained nor that the communication is free of viruses, interceptions or interference. By communicating with anyone at Trafigura by email, you consent to the monitoring or interception of such email by Trafigura in accordance with its internal policies. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100520/5eb1a0b6/attachment.htm From emile at rabbitmq.com Thu May 20 17:28:56 2010 From: emile at rabbitmq.com (Emile Joubert) Date: Thu, 20 May 2010 17:28:56 +0100 Subject: [rabbitmq-discuss] Cloning RHEL VM's with pre-installed Rabbit. In-Reply-To: <635E976302C55647BE5A8369ACBB5122011D02D65E41@TTRAFLONVS01.global.trafigura.com> References: <635E976302C55647BE5A8369ACBB5122011D02D65E41@TTRAFLONVS01.global.trafigura.com> Message-ID: <4BF56348.20404@rabbitmq.com> Hi Keith, Keith Davies wrote: > Hi Emile > > Thanks very much for the reply. Just to let you know we are using > rabbit 1.7.1. Anyway in response to your questions if I run the > following command on one of our VM's:- > > ./rabbitmqctl status > > I get the response:- > > Status of node rabbit at ttraflonrh320 ... > [{running_applications,[{rabbitmq_bql,"RabbitMQ Broker Query > Language","0.01"}, > {amqp_client,"RabbitMQ AMQP Client","0.0.0"}, > {rabbit,"RabbitMQ","1.7.1"}, > {os_mon,"CPO CXC 138 46","2.1.8"}, > {sasl,"SASL CXC 138 11","2.1.5.4"}, > {rfc4627_jsonrpc,"JSON RPC Service","0.01"}, > {mnesia,"MNESIA CXC 138 12","4.4.7"}, > {stdlib,"ERTS CXC 138 10","1.15.5"}, > {kernel,"ERTS CXC 138 10","2.12.5"}]}, > {nodes,[rabbit at ttraflonrh320]}, > {running_nodes,[rabbit at ttraflonrhtest,rabbit at ttraflonrh324, > rabbit at ttraflonrh334,rabbit at ttraflonrh326, > rabbit at ttraflonrh331,rabbit at ttraflonrh320]}] > > Which strikes me a slightly weird as the running nodes do not match up > with the nodes. Unfortunately I have not been able to determine from > the documentation what this means. This should never happen. The running nodes should always be a subset of the nodes. We have never seen the state you reported. Is it possible that the original machine was in a clustered configuration prior to being cloned? When did the running_nodes come into existence? A suggested recovery option is to run "rabbitmqctl stop_app; rabbitmqctl reset; rabbitmqctl start_app" for each of the running nodes. This should leave you with a set of standalone rabbit brokers and both "nodes" and "running_nodes" should contain a single entry. The original template machine that the clones are created from should have a blank mnesia database or preferably have no mnesia directory at all. -Emile From elij.mx at gmail.com Thu May 20 23:12:45 2010 From: elij.mx at gmail.com (elij) Date: Thu, 20 May 2010 15:12:45 -0700 Subject: [rabbitmq-discuss] bql causing crash on startup Message-ID: I am having, what appears to be, the same issue as this: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2010-April/006924.html log messages (startup messages that all look normal, then): broker running Erlang has closed {"Kernel pid terminated",application_controller,"{application_start_failure,rabbitmq_bql,{shutdown,{rabbitmq_bql,start,[normal,[]]}}}"} Kernel pid terminated (application_controller) ({application_start_failure,rabbitmq_bql,{shutdown,{rabbitmq_bql,start,[normal,[]]}}}) in rabbit.log: =INFO REPORT==== started TCP Listener on 0.0.0.0:5672 =INFO REPORT==== application: rabbitmq_bql exited: {shutdown,{rabbitmq_bql,start,[normal,[]]}} type: permanent rabbit-sasl has quite a bit of log info. =CRASH REPORT==== crasher: initial call: amqp_direct_connection:init/1 pid: <0.179.0> registered_name: [] exception exit: {undef,[{rabbit_reader,server_properties,[]}, {amqp_direct_connection,init,1}, {gen_server,init_it,6}, {proc_lib,init_p_do_apply,3}]} in function gen_server:init_it/6 ancestors: [<0.178.0>,rabbitmq_bql_sup,<0.175.0>] messages: [] links: [] dictionary: [] trap_exit: true status: running heap_size: 1597 stack_size: 24 reductions: 289 neighbours: =CRASH REPORT==== crasher: initial call: bql_amqp_rpc_server:init/1 pid: <0.178.0> registered_name: [] exception exit: {{badmatch, {error, {undef, [{rabbit_reader,server_properties,[]}, {amqp_direct_connection,init,1}, {gen_server,init_it,6}, {proc_lib,init_p_do_apply,3}]}}}, [{amqp_connection,start_direct_internal,2}, {bql_amqp_rpc_server,init,1}, {gen_server,init_it,6}, {proc_lib,init_p_do_apply,3}]} in function gen_server:init_it/6 ancestors: [rabbitmq_bql_sup,<0.175.0>] messages: [] links: [<0.176.0>] dictionary: [] trap_exit: false status: running heap_size: 233 stack_size: 24 reductions: 132 neighbours: =SUPERVISOR REPORT==== Supervisor: {local,rabbitmq_bql_sup} Context: start_error Reason: {{badmatch, {error, {undef, [{rabbit_reader,server_properties,[]}, {amqp_direct_connection,init,1}, {gen_server,init_it,6}, {proc_lib,init_p_do_apply,3}]}}}, [{amqp_connection,start_direct_internal,2}, {bql_amqp_rpc_server,init,1}, {gen_server,init_it,6}, {proc_lib,init_p_do_apply,3}]} Offender: [{pid,undefined}, {name,bql_amqp_rpc_server}, {mfa,{bql_amqp_rpc_server,start_link,[]}}, {restart_type,permanent}, {shutdown,10000}, {child_type,worker}] Note that if I remove just the rabbitmq-bql.ez plugin (leaving the amqp_client.ez and rfc4627_jsonrpc.ez plugins) rabbitmq starts up just fine. Only when I add the rabbitmq-bql.ez plugin does it crash on startup. From matthew at rabbitmq.com Thu May 20 23:40:11 2010 From: matthew at rabbitmq.com (Matthew Sackman) Date: Thu, 20 May 2010 23:40:11 +0100 Subject: [rabbitmq-discuss] bql causing crash on startup In-Reply-To: References: Message-ID: <20100520224011.GB7749@wellquite.org> On Thu, May 20, 2010 at 03:12:45PM -0700, elij wrote: > exception exit: {undef,[{rabbit_reader,server_properties,[]}, I think you're using the latest version of the erlang client, but on a 1.7.2 server. You'll need to compile and run the server from source. Matthew From elij.mx at gmail.com Fri May 21 00:20:44 2010 From: elij.mx at gmail.com (elij) Date: Thu, 20 May 2010 16:20:44 -0700 Subject: [rabbitmq-discuss] bql causing crash on startup In-Reply-To: <20100520224011.GB7749@wellquite.org> References: <20100520224011.GB7749@wellquite.org> Message-ID: Is there a particular version/revision of the plugin-umbrella (or just bql) source that will work with the release version of the rabbitmq-server (which is 1.7.2 according to the site)? On Thu, May 20, 2010 at 3:40 PM, Matthew Sackman wrote: > On Thu, May 20, 2010 at 03:12:45PM -0700, elij wrote: >> ? ? exception exit: {undef,[{rabbit_reader,server_properties,[]}, > > I think you're using the latest version of the erlang client, but on a > 1.7.2 server. You'll need to compile and run the server from source. > > Matthew > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > From zirpubolci at gmail.com Fri May 21 01:32:33 2010 From: zirpubolci at gmail.com (allan bailey) Date: Thu, 20 May 2010 17:32:33 -0700 Subject: [rabbitmq-discuss] Pika and Channel.Flow Message-ID: Tony, I just tried this patch in py-amqplib 0.6.2 and it doesn't seem to work, or raise an exception. It might be rabbitmq isn't sending the channel.flow. I tested with rabbitmq 1.7.2 on OSX 10.6.2. I'll test on a real OS when I can. I definately need the flow control to stop producers from overwhelming the server. -allan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100520/f6783ade/attachment.htm From so at facebook.com Fri May 21 07:52:23 2010 From: so at facebook.com (Sam Odio) Date: Thu, 20 May 2010 23:52:23 -0700 Subject: [rabbitmq-discuss] Startup errors redux Message-ID: I installed the rpm on Centos 5.2 (note the warning): # rpm -i ./rabbitmq-server-1.7.2-1.i386.rpm warning: ./rabbitmq-server-1.7.2-1.i386.rpm: Header V4 DSA signature: NOKEY, key ID 056e8e56 I then started rabbitmq-server: # /etc/init.d/rabbitmq-server start Starting rabbitmq-server: FAILED - check /var/log/rabbitmq/startup_log, _err rabbitmq-server. startup_log contents: {"init terminating in do_boot",{{nocatch,{error,{cannot_start_application,rabbit,{bad_return,{{rabbit,start,[normal,[]]},{'EXIT',{undef,[{base64,encode_to_string,[<<16 bytes>>]},{rabbit,print_banner,0},{rabbit,start,2},{application_master,start_it_old,4}]}}}}}}},[{init,start_it,1},{init,start_em,1}]}} startup_err contents: Error: {node_start_failed,normal} ^M Crash dump was written to: erl_crash.dump^M init terminating in do_boot ()^M it appears epmd is running: # ps aux | grep rabbit rabbitmq 11007 0.0 0.0 10568 384 ? S 23:21 0:00 /usr/lib64/erlang/erts-5.5.2/bin/epmd -daemon Yet... # /usr/sbin/rabbitmqctl status Status of node rabbit at facerecwebi064 ... Error: unable to connect to node rabbit at facerecwebi064: nodedown diagnostics: - nodes and their ports on facerecwebi064: [{rabbitmqctl17860,60369}] - current node: rabbitmqctl17860 at facerecwebi064 - current node home dir: /var/lib/rabbitmq {"init terminating in do_boot",{undef,[{base64,encode_to_string,[<<16 bytes>>]},{rabbit_control,print_badrpc_diagnostics,1},{rabbit_control,start,0},{init,start_it,1},{init,start_em,1}]}} Crash dump was written to: erl_crash.dump init terminating in do_boot () I'd include erl_crash.dump but it's 17,185 lines. I did take Matthias' suggestion and captured epmd's logs: epmd: Thu May 20 22:38:47 2010: epmd running - daemon = 0 epmd: Thu May 20 22:39:01 2010: ** got ALIVE2_REQ epmd: Thu May 20 22:39:01 2010: registering 'rabbitmq_multi29522:2', port 40086 epmd: Thu May 20 22:39:01 2010: type 77 proto 0 highvsn 5 lowvsn 5 epmd: Thu May 20 22:39:01 2010: ** sent ALIVE2_RESP for "rabbitmq_multi29522" epmd: Thu May 20 22:39:01 2010: ** got PORT2_REQ epmd: Thu May 20 22:39:01 2010: ** sent PORT2_RESP (error) for "rabbit" epmd: Thu May 20 22:39:01 2010: ** got PORT2_REQ epmd: Thu May 20 22:39:01 2010: ** sent PORT2_RESP (error) for "rabbit" epmd: Thu May 20 22:39:01 2010: ** got ALIVE2_REQ epmd: Thu May 20 22:39:01 2010: registering 'rabbit:2', port 60848 epmd: Thu May 20 22:39:01 2010: type 77 proto 0 highvsn 5 lowvsn 5 epmd: Thu May 20 22:39:01 2010: ** sent ALIVE2_RESP for "rabbit" epmd: Thu May 20 22:39:01 2010: unregistering 'rabbit:2', port 60848 epmd: Thu May 20 22:39:01 2010: unregistering 'rabbitmq_multi29522:2', port 40086 epmd: Thu May 20 22:39:09 2010: ** got ALIVE2_REQ epmd: Thu May 20 22:39:09 2010: registering 'rabbitmqctl29640:1', port 45937 epmd: Thu May 20 22:39:09 2010: type 77 proto 0 highvsn 5 lowvsn 5 epmd: Thu May 20 22:39:09 2010: ** sent ALIVE2_RESP for "rabbitmqctl29640" epmd: Thu May 20 22:39:09 2010: ** got PORT2_REQ epmd: Thu May 20 22:39:09 2010: ** sent PORT2_RESP (error) for "rabbit" epmd: Thu May 20 22:39:09 2010: ** got NAMES_REQ epmd: Thu May 20 22:39:09 2010: ** sent NAMES_RESP epmd: Thu May 20 22:39:09 2010: unregistering 'rabbitmqctl29640:1', port 45937 epmd: Thu May 20 22:42:17 2010: ** got ALIVE2_REQ epmd: Thu May 20 22:42:17 2010: registering 'rabbitmqctl30412:3', port 56622 epmd: Thu May 20 22:42:17 2010: type 77 proto 0 highvsn 5 lowvsn 5 epmd: Thu May 20 22:42:17 2010: ** sent ALIVE2_RESP for "rabbitmqctl30412" epmd: Thu May 20 22:42:17 2010: ** got PORT2_REQ epmd: Thu May 20 22:42:17 2010: ** sent PORT2_RESP (error) for "rabbit" epmd: Thu May 20 22:42:17 2010: ** got NAMES_REQ epmd: Thu May 20 22:42:17 2010: ** sent NAMES_RESP epmd: Thu May 20 22:42:17 2010: unregistering 'rabbitmqctl30412:3', port 56622 epmd: Thu May 20 22:42:41 2010: ** got ALIVE2_REQ epmd: Thu May 20 22:42:41 2010: registering 'rabbitmq_multi30554:3', port 63390 epmd: Thu May 20 22:42:41 2010: type 77 proto 0 highvsn 5 lowvsn 5 epmd: Thu May 20 22:42:41 2010: ** sent ALIVE2_RESP for "rabbitmq_multi30554" epmd: Thu May 20 22:42:41 2010: ** got PORT2_REQ epmd: Thu May 20 22:42:41 2010: ** sent PORT2_RESP (error) for "rabbit" epmd: Thu May 20 22:42:41 2010: ** got PORT2_REQ epmd: Thu May 20 22:42:41 2010: ** sent PORT2_RESP (error) for "rabbit" epmd: Thu May 20 22:42:41 2010: ** got ALIVE2_REQ epmd: Thu May 20 22:42:41 2010: reusing slot with same name 'rabbit' epmd: Thu May 20 22:42:41 2010: registering 'rabbit:3', port 50197 epmd: Thu May 20 22:42:41 2010: type 77 proto 0 highvsn 5 lowvsn 5 epmd: Thu May 20 22:42:41 2010: ** sent ALIVE2_RESP for "rabbit" epmd: Thu May 20 22:42:41 2010: unregistering 'rabbit:3', port 50197 Where should I go from here? Google is of no help... -s -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100520/8ae7dd39/attachment-0001.htm From david at rabbitmq.com Fri May 21 08:18:55 2010 From: david at rabbitmq.com (David Wragg) Date: Fri, 21 May 2010 08:18:55 +0100 Subject: [rabbitmq-discuss] Startup errors redux In-Reply-To: (Sam Odio's message of "Thu\, 20 May 2010 23\:52\:23 -0700") References: Message-ID: Hi Sam, Sam Odio writes: > I installed the rpm on Centos 5.2 (note the warning): > # rpm -i ./rabbitmq-server-1.7.2-1.i386.rpm > warning: ./rabbitmq-server-1.7.2-1.i386.rpm: Header V4 DSA signature: NOKEY, key ID 056e8e56 > > I then started rabbitmq-server: > # /etc/init.d/rabbitmq-server start > Starting rabbitmq-server: FAILED - check /var/log/rabbitmq/startup_log, _err > rabbitmq-server. > > startup_log contents: > {"init terminating in do_boot",{{nocatch,{error,{cannot_start_application,rabbit,{bad_return,{{rabbit,start,[normal,[]]},{'EXIT',{undef,[{base64,encode_to_string,[<<16 bytes>>]},{rabbit,print_banner,0},{rabbit,start,2},{application_master,start_it_old,4}]}}}}}}},[{init,start_it,1},{init,start_em,1}]}} This suggests you have an old version of erlang (prior to R11B5, which is the earliest 1.7.2 supports). How did you install erlang, and which version is it? Could you try with erlang installed from EPEL? David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware From keith.davies at trafigura.com Fri May 21 09:09:29 2010 From: keith.davies at trafigura.com (Keith Davies) Date: Fri, 21 May 2010 09:09:29 +0100 Subject: [rabbitmq-discuss] Cloning RHEL VM's with pre-installed Rabbit. In-Reply-To: <4BF56348.20404@rabbitmq.com> References: <635E976302C55647BE5A8369ACBB5122011D02D65E41@TTRAFLONVS01.global.trafigura.com> <4BF56348.20404@rabbitmq.com> Message-ID: <635E976302C55647BE5A8369ACBB5122011D02D66084@TTRAFLONVS01.global.trafigura.com> Thanks very much Emile, I'm not sure how it got in that state. I think the best thing to do would be for us to try creating the template again. -----Original Message----- From: Emile Joubert [mailto:emile at rabbitmq.com] Sent: 20 May 2010 17:29 To: Keith Davies Cc: rabbitmq-discuss at lists.rabbitmq.com Subject: Re: [rabbitmq-discuss] Cloning RHEL VM's with pre-installed Rabbit. Hi Keith, Keith Davies wrote: > Hi Emile > > Thanks very much for the reply. Just to let you know we are using > rabbit 1.7.1. Anyway in response to your questions if I run the > following command on one of our VM's:- > > ./rabbitmqctl status > > I get the response:- > > Status of node rabbit at ttraflonrh320 ... > [{running_applications,[{rabbitmq_bql,"RabbitMQ Broker Query > Language","0.01"}, > {amqp_client,"RabbitMQ AMQP Client","0.0.0"}, > {rabbit,"RabbitMQ","1.7.1"}, > {os_mon,"CPO CXC 138 46","2.1.8"}, > {sasl,"SASL CXC 138 11","2.1.5.4"}, > {rfc4627_jsonrpc,"JSON RPC Service","0.01"}, > {mnesia,"MNESIA CXC 138 12","4.4.7"}, > {stdlib,"ERTS CXC 138 10","1.15.5"}, > {kernel,"ERTS CXC 138 10","2.12.5"}]}, > {nodes,[rabbit at ttraflonrh320]}, > {running_nodes,[rabbit at ttraflonrhtest,rabbit at ttraflonrh324, > rabbit at ttraflonrh334,rabbit at ttraflonrh326, > rabbit at ttraflonrh331,rabbit at ttraflonrh320]}] > > Which strikes me a slightly weird as the running nodes do not match up > with the nodes. Unfortunately I have not been able to determine from > the documentation what this means. This should never happen. The running nodes should always be a subset of the nodes. We have never seen the state you reported. Is it possible that the original machine was in a clustered configuration prior to being cloned? When did the running_nodes come into existence? A suggested recovery option is to run "rabbitmqctl stop_app; rabbitmqctl reset; rabbitmqctl start_app" for each of the running nodes. This should leave you with a set of standalone rabbit brokers and both "nodes" and "running_nodes" should contain a single entry. The original template machine that the clones are created from should have a blank mnesia database or preferably have no mnesia directory at all. -Emile This email and any attachments are confidential and access to this email or attachment by anyone other than the addressee is unauthorised. If you are not the intended recipient please notify the sender and delete the email including any attachments. You must not disclose or distribute any of the contents to any other person. Personal views or opinions are solely those of the author and not of Trafigura. Trafigura does not guarantee that the integrity of this communication has been maintained nor that the communication is free of viruses, interceptions or interference. By communicating with anyone at Trafigura by email, you consent to the monitoring or interception of such email by Trafigura in accordance with its internal policies. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. From so at facebook.com Fri May 21 09:12:59 2010 From: so at facebook.com (Sam Odio) Date: Fri, 21 May 2010 01:12:59 -0700 Subject: [rabbitmq-discuss] Startup errors redux In-Reply-To: References: Message-ID: <80976133-D991-41EA-9798-A160F2156A50@facebook.com> I have erlang vR11B-2.3.el5 This is how I installed it: # su -c 'rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm' # yum install erlang It appears it was installed from EPEL. # yum info erlang Available Packages Name : erlang Arch : x86_64 Version: R11B Release: 2.3.el5 Size : 37 M Repo : epel Summary: General-purpose programming language and runtime environment Description: Erlang is a general-purpose programming language and runtime environment. Erlang has built-in support for concurrency, distribution and fault tolerance. Erlang is used in several large telecommunication systems from Ericsson. On May 21, 2010, at 12:18 AM, David Wragg wrote: Hi Sam, Sam Odio > writes: I installed the rpm on Centos 5.2 (note the warning): # rpm -i ./rabbitmq-server-1.7.2-1.i386.rpm warning: ./rabbitmq-server-1.7.2-1.i386.rpm: Header V4 DSA signature: NOKEY, key ID 056e8e56 I then started rabbitmq-server: # /etc/init.d/rabbitmq-server start Starting rabbitmq-server: FAILED - check /var/log/rabbitmq/startup_log, _err rabbitmq-server. startup_log contents: {"init terminating in do_boot",{{nocatch,{error,{cannot_start_application,rabbit,{bad_return,{{rabbit,start,[normal,[]]},{'EXIT',{undef,[{base64,encode_to_string,[<<16 bytes>>]},{rabbit,print_banner,0},{rabbit,start,2},{application_master,start_it_old,4}]}}}}}}},[{init,start_it,1},{init,start_em,1}]}} This suggests you have an old version of erlang (prior to R11B5, which is the earliest 1.7.2 supports). How did you install erlang, and which version is it? Could you try with erlang installed from EPEL? David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100521/e07c3f23/attachment.htm From matthew at rabbitmq.com Fri May 21 09:41:31 2010 From: matthew at rabbitmq.com (Matthew Sackman) Date: Fri, 21 May 2010 09:41:31 +0100 Subject: [rabbitmq-discuss] bql causing crash on startup In-Reply-To: References: <20100520224011.GB7749@wellquite.org> Message-ID: <20100521084131.GA22916@mrnibble.lshift.net> On Thu, May 20, 2010 at 04:20:44PM -0700, elij wrote: > Is there a particular version/revision of the plugin-umbrella (or just > bql) source that will work with the release version of the > rabbitmq-server (which is 1.7.2 according to the site)? Yes, but we don't know what they are. Are plugins are, to date (though this will change in the future), all "unreleased" - we do not make binary packages of them available and they are not in any distros. The only thing we try to ensure is that the latest revisions on all the default branches work together. Sorry. As I say, we have plans to sort this out and make versioned releases of plugins - you're not the only person suffering from this deficiency of ours. Matthew From matthew at rabbitmq.com Fri May 21 09:46:21 2010 From: matthew at rabbitmq.com (Matthew Sackman) Date: Fri, 21 May 2010 09:46:21 +0100 Subject: [rabbitmq-discuss] Startup errors redux In-Reply-To: References: Message-ID: <20100521084621.GB22916@mrnibble.lshift.net> On Fri, May 21, 2010 at 08:18:55AM +0100, David Wragg wrote: > This suggests you have an old version of erlang (prior to R11B5, which > is the earliest 1.7.2 supports). How did you install erlang, and > which version is it? http://erlang.org/documentation.html says 5.5.2 is R11B2 which is ancient. As David says, 1.7.2 will not run on anything older than R11B5, and future releases demand at least R12B3 (this is already the case if you're compiling from source). Matthew From so at facebook.com Fri May 21 10:08:49 2010 From: so at facebook.com (Sam Odio) Date: Fri, 21 May 2010 02:08:49 -0700 Subject: [rabbitmq-discuss] Startup errors redux In-Reply-To: <20100521084621.GB22916@mrnibble.lshift.net> References: <20100521084621.GB22916@mrnibble.lshift.net> Message-ID: <2544CADE-97CD-4D3E-9501-F814C530717A@facebook.com> On May 21, 2010, at 1:46 AM, Matthew Sackman wrote: > On Fri, May 21, 2010 at 08:18:55AM +0100, David Wragg wrote: >> This suggests you have an old version of erlang (prior to R11B5, which >> is the earliest 1.7.2 supports). How did you install erlang, and >> which version is it? > > http://erlang.org/documentation.html says 5.5.2 is R11B2 which is > ancient. As David says, 1.7.2 will not run on anything older than R11B5, > and future releases demand at least R12B3 (this is already the case if > you're compiling from source). Thanks. Got it to work by compiling the latest erlang from source. -s From RadhakrishnanD at ivycomptech.com Fri May 21 14:25:57 2010 From: RadhakrishnanD at ivycomptech.com (Radha Krishnan D) Date: Fri, 21 May 2010 18:55:57 +0530 Subject: [rabbitmq-discuss] RabbitMQ failover and message loss Message-ID: <49A7BA114AAC6A48B9C44CB06B7B987E0A4AC1D4@HYDSVWIN004X.ivycomptech.partygaming.local> Hi, I have 2 brokers clustered with each other. They are load balanced by having a HA proxy before them. Let us call the brokers as B1 and B2. The HAproxy is in the same machine as B1. The producer P1 and consumer C1 are on different machines. The model we are using is amq.direct and all the messages are non persistent. All our messages are mandatory=true and immediate=false. Initially we start the broker B1 alone. The broker B2 is down. We start P1 and C1. They are now connected to the broker B1. We start C1 and then P1. after 3-4 seconds, we start B2. After B2 starts, We immediately crash B1. Now both P1 and C1 get connected to B2 and the test continues till we stop all three. Now, during the failover time we find message losses. Is it expected or can we make sure that no message gets lost. Also, when will be channel.setReturnListener called ? Will it be called when the message does not reach the queue from the exchange or when the message does reach the consumer from the queue ? In the clustered mode, exchanges are global across rabbitmq nodes .. are the queues also global ? Please clear us. We are confused about the global nature of queues !! Thanks and Regards, D.Radhakrishnan Trainee Engineer-Architecture IVY Comptech Private Limited Cyber Spazio,Road No 2, Banjara Hills, Hyderabad-500034, Andhra Pradesh. Phone + 91 (40) 66721000 - 4638 Mobile + 91 (0) 9030842104 This email and any attachments are confidential, legally privileged and protected by copyright. If you are not the intended recipient, dissemination or copying this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorized. Any actions taken on the basis of this email are at recipient's own risk. This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy Comptech Private Limited is a limited liability company. This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract on behalf of Ivy Comptech Private Limited unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. Registered office: Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, Hyderabad 500 033, Andhra Pradesh, India. Registered number: 37994. Registered in India. A list of members' names is available for inspection at the registered office. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100521/e9843123/attachment.htm From matthew at rabbitmq.com Fri May 21 15:50:26 2010 From: matthew at rabbitmq.com (Matthew Sackman) Date: Fri, 21 May 2010 15:50:26 +0100 Subject: [rabbitmq-discuss] RabbitMQ failover and message loss In-Reply-To: <49A7BA114AAC6A48B9C44CB06B7B987E0A4AC1D4@HYDSVWIN004X.ivycomptech.partygaming.local> References: <49A7BA114AAC6A48B9C44CB06B7B987E0A4AC1D4@HYDSVWIN004X.ivycomptech.partygaming.local> Message-ID: <20100521145026.GA26867@mrnibble.lshift.net> On Fri, May 21, 2010 at 06:55:57PM +0530, Radha Krishnan D wrote: > I have 2 brokers clustered with each other. They are load balanced by > having a HA proxy before them. Ok, that's not a usual setup. If you actually have the two rabbit nodes clustered together then you should have no need for the load balancer - all clients can connect to either node and still reach every resource in the broker. > Now both P1 and C1 get connected to B2 and the test continues till we > stop all three. > > Now, during the failover time we find message losses. > > Is it expected or can we make sure that no message gets lost. That is expected. Queues are located on the node of the connection which created the queue. When the node goes down, you'll lose that queue. When your clients (re)connect to the broker and reach the other node, they are recreating the queues and other resources, but are creating fresh, empty queues at that point. If you need to be able to withstand node failures then currently your best bet is to use the Pacemaker Active/Passive guide at: http://www.rabbitmq.com/pacemaker.html You will need to publish all messages persistent to durable queues. You should not need the load balancer and pacemaker will correctly ensure that the two nodes are not both up at the same time. > Also, when will be channel.setReturnListener called ? Well, you set it yourself. The ReturnListener is invoked as soon as any Basic.Return method is read off the socket. > Will it be called when the message does not reach the queue from the > exchange or when the message does reach the consumer from the queue ? This is the difference between immediate and mandatory. Mandatory says "blow up if the msg doesn't make it to a queue". Immediate says "blow up if the msg doesn't make it through a queue to a consumer". > In the clustered mode, exchanges are global across rabbitmq nodes .. are > the queues also global ? They are visible globally within the cluster, but they are located in a node. Matthew From jasonjwwilliams at gmail.com Fri May 21 17:52:59 2010 From: jasonjwwilliams at gmail.com (Jason J. W. Williams) Date: Fri, 21 May 2010 10:52:59 -0600 Subject: [rabbitmq-discuss] RabbitMQ failover and message loss In-Reply-To: <20100521145026.GA26867@mrnibble.lshift.net> References: <49A7BA114AAC6A48B9C44CB06B7B987E0A4AC1D4@HYDSVWIN004X.ivycomptech.partygaming.local> <20100521145026.GA26867@mrnibble.lshift.net> Message-ID: Great use case for an auto-replay option when dead nodes return. ;) -J On Fri, May 21, 2010 at 8:50 AM, Matthew Sackman wrote: > On Fri, May 21, 2010 at 06:55:57PM +0530, Radha Krishnan D wrote: >> I have 2 brokers clustered with each other. ?They are load balanced by >> having a HA proxy before them. > > Ok, that's not a usual setup. If you actually have the two rabbit nodes > clustered together then you should have no need for the load balancer - > all clients can connect to either node and still reach every resource in > the broker. > >> Now both P1 and C1 get connected to B2 and the test continues till we >> stop all three. >> >> Now, during the failover time we find message losses. >> >> Is it expected ?or can we make sure that no message gets lost. > > That is expected. Queues are located on the node of the connection which > created the queue. When the node goes down, you'll lose that queue. When > your clients (re)connect to the broker and reach the other node, they > are recreating the queues and other resources, but are creating fresh, > empty queues at that point. > > If you need to be able to withstand node failures then currently your > best bet is to use the Pacemaker Active/Passive guide at: > http://www.rabbitmq.com/pacemaker.html > You will need to publish all messages persistent to durable queues. You > should not need the load balancer and pacemaker will correctly ensure > that the two nodes are not both up at the same time. > >> Also, when will be ?channel.setReturnListener ?called ? > > Well, you set it yourself. The ReturnListener is invoked as soon as any > Basic.Return method is read off the socket. > >> Will it be called when the message does not reach the queue from the >> exchange or when the message does reach the consumer from the queue ? > > This is the difference between immediate and mandatory. Mandatory says > "blow up if the msg doesn't make it to a queue". Immediate says "blow up > if the msg doesn't make it through a queue to a consumer". > >> In the clustered mode, exchanges are global across rabbitmq nodes .. are >> the queues also global ? > > They are visible globally within the cluster, but they are located in a > node. > > Matthew > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > From aaron at agoragames.com Fri May 21 20:57:57 2010 From: aaron at agoragames.com (Aaron Westendorf) Date: Fri, 21 May 2010 15:57:57 -0400 Subject: [rabbitmq-discuss] lost message due to binding delay Message-ID: We tracked down an interesting bug today in a 1.7.2 cluster. Our setup is as follows: cluster: 4 hosts, 1 node each ("rabbit1", "rabbit2", "rabbit3", "rabbit4") clients: 2 services, "serviceA" and "serviceB"; 1 or more processes each In this situation both services are connected to rabbit1. Both services have a standard queue and binding setup that is built into our application stack so that they can receive messages from our HTTP bridge, and also receive messages that we send between services. The queues, bindings and consumers are all declared when the services start, and the queues are by service name to distribute messages between all instances of each service. The bug occurs when we use the part of our stack that allows serviceA to query serviceB and receive a response. To be sure that the response ends up with the right process, each process sets up a queue that resolves to its host and pid. The queue and its bindings are not allocated at startup but instead on-demand when services interact. Our python driver is a fork of py-amqplib which uses libevent for all IO and scheduling. The driver has been in use for awhile now, though it needs a lot of documentation before it is ready to be released into the wild (we promise, we're working on it). What this means is that if we have multiple AMQP messages sent during the same event loop cycle, the bytes reside locally in a buffer until the current cycle completes. When a write event is processed, we push as many bytes into the socket buffer as possible, and in this case, likely all of the bytes would be able to fit into the socket buffer. So, when we perform inter-service communication, the first time it occurs in that process, the bytes for setting up our subscription are immediately followed by the message sent to the second service. For example: serviceA: exchange_declare('response', 'topic') # already exists serviceA: queue_declare('serviceA.response.host.pid') serviceA: queue_bind('serviceA.response.host.pid', 'response', routing_key='serviceA.response.host.pid') serviceA: basic_consume( 'serviceA.response.host.pid' ) serviceA: tx_select() serviceA: basic_publish( ) serviceA: tx_commit() serviceB: on receipt, do a DB query and send response back to serviceA Using our passive listener application, we can confirm that serviceB writes a response with the correct routing keys, but serviceA never receives it. Subsequent messages skip everything before basic_publish() and work as expected. We are unable to reproduce this bug if we're running a single Rabbit node. The reason I suspect that it's a problem with the exchange-queue binding is that all of the messages are flowing, which means that Rabbit is handling the queue_* and tx_* methods in the order in which we expect them to be processed. Because we're running this in a cluster, it is necessary for all nodes to register the binding of the exchange to the queue. I suspect that this is an asynchronous operation, and that "rabbit1" has not confirmed that the binding is in place by the time serviceB writes its response. We don't have exact timings, but the round-trip time for the request and response is between 1 and 5ms. For now, we're going to change our services so that they setup their response queues and bindings when they start. This will greatly increase the number of queues that we have live, as our services are all distributed and multi-process, but very few of them use inter-service messaging. -Aaron -- Aaron Westendorf Senior Software Engineer Agora Games 359 Broadway Troy, NY 12180 Phone: 518.268.1000 aaron at agoragames.com www.agoragames.com From gocanal at yahoo.com Sat May 22 04:09:32 2010 From: gocanal at yahoo.com (go canal) Date: Fri, 21 May 2010 20:09:32 -0700 (PDT) Subject: [rabbitmq-discuss] help: simple web application integration and testing Message-ID: <931675.73803.qm@web45304.mail.sp1.yahoo.com> Hello, I am new to RabbitMQ, wanted to setup a quick testing web page. This is what I did so far, but I am not able to get anything: * Jetty 7.0.2, Spring 3.0.2, running inside Eclipse 3.5.1 * Using RabbitMQ 1.7.2, amqp-js. RabbitMQ running on localhost. Here is my web page (using the part of the sample application in amqp-js): When clicking the button, I do not see anything. any help is very much appreciated! rgds, canal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100521/4587b055/attachment.htm From RadhakrishnanD at ivycomptech.com Sat May 22 06:07:18 2010 From: RadhakrishnanD at ivycomptech.com (Radha Krishnan D) Date: Sat, 22 May 2010 10:37:18 +0530 Subject: [rabbitmq-discuss] rabbitmq-discuss Digest, Vol 36, Issue 56 In-Reply-To: References: Message-ID: <49A7BA114AAC6A48B9C44CB06B7B987E0A4AC2C8@HYDSVWIN004X.ivycomptech.partygaming.local> Hi Matthew, > Ok, that's not a usual setup. If you actually have the two rabbit nodes > clustered together then you should have no need for the load balancer - > all clients can connect to either node and still reach every resource in > the broker. We want to do graceful failover from one rabbitmq broker to another rabbitmq broker. So only we used HA proxy. Even though we used HA proxy, the two brokers B1 and B2 are in a cluster only. I achieved that using rabbitmqctl command. I have another doubt matthew , The queue is lost when the node is crashed. So all the messages in the queue at that point are lost. Will those messages be returned to the producer by using channel.setReturnListener ? I mean, will that listener be called. Thanks and Regards, D.Radhakrishnan Trainee Engineer-Architecture IVY Comptech Private Limited Cyber Spazio,Road No 2, Banjara Hills, Hyderabad-500034, Andhra Pradesh. Phone + 91 (40) 66721000 - 4638 Mobile + 91 (0) 9030842104 This email and any attachments are confidential, legally privileged and protected by copyright. If you are not the intended recipient, dissemination or copying this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorized. Any actions taken on the basis of this email are at recipient's own risk. Message: 1 Date: Fri, 21 May 2010 18:55:57 +0530 From: "Radha Krishnan D" Subject: [rabbitmq-discuss] RabbitMQ failover and message loss To: "RabbitMQ Discuss" Message-ID: <49A7BA114AAC6A48B9C44CB06B7B987E0A4AC1D4 at HYDSVWIN004X.ivycomptech.party gaming.local> Content-Type: text/plain; charset="us-ascii" Hi, I have 2 brokers clustered with each other. They are load balanced by having a HA proxy before them. Let us call the brokers as B1 and B2. The HAproxy is in the same machine as B1. The producer P1 and consumer C1 are on different machines. The model we are using is amq.direct and all the messages are non persistent. All our messages are mandatory=true and immediate=false. Initially we start the broker B1 alone. The broker B2 is down. We start P1 and C1. They are now connected to the broker B1. We start C1 and then P1. after 3-4 seconds, we start B2. After B2 starts, We immediately crash B1. Now both P1 and C1 get connected to B2 and the test continues till we stop all three. Now, during the failover time we find message losses. Is it expected or can we make sure that no message gets lost. Also, when will be channel.setReturnListener called ? Will it be called when the message does not reach the queue from the exchange or when the message does reach the consumer from the queue ? In the clustered mode, exchanges are global across rabbitmq nodes .. are the queues also global ? Please clear us. We are confused about the global nature of queues !! Thanks and Regards, D.Radhakrishnan Trainee Engineer-Architecture IVY Comptech Private Limited Cyber Spazio,Road No 2, Banjara Hills, Hyderabad-500034, Andhra Pradesh. Phone + 91 (40) 66721000 - 4638 Mobile + 91 (0) 9030842104 This email and any attachments are confidential, legally privileged and protected by copyright. If you are not the intended recipient, dissemination or copying this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorized. Any actions taken on the basis of this email are at recipient's own risk. Message: 2 Date: Fri, 21 May 2010 15:50:26 +0100 From: Matthew Sackman Subject: Re: [rabbitmq-discuss] RabbitMQ failover and message loss To: rabbitmq-discuss at lists.rabbitmq.com Message-ID: <20100521145026.GA26867 at mrnibble.lshift.net> Content-Type: text/plain; charset=us-ascii On Fri, May 21, 2010 at 06:55:57PM +0530, Radha Krishnan D wrote: > I have 2 brokers clustered with each other. They are load balanced by > having a HA proxy before them. Ok, that's not a usual setup. If you actually have the two rabbit nodes clustered together then you should have no need for the load balancer - all clients can connect to either node and still reach every resource in the broker. > Now both P1 and C1 get connected to B2 and the test continues till we > stop all three. > > Now, during the failover time we find message losses. > > Is it expected or can we make sure that no message gets lost. That is expected. Queues are located on the node of the connection which created the queue. When the node goes down, you'll lose that queue. When your clients (re)connect to the broker and reach the other node, they are recreating the queues and other resources, but are creating fresh, empty queues at that point. If you need to be able to withstand node failures then currently your best bet is to use the Pacemaker Active/Passive guide at: http://www.rabbitmq.com/pacemaker.html You will need to publish all messages persistent to durable queues. You should not need the load balancer and pacemaker will correctly ensure that the two nodes are not both up at the same time. > Also, when will be channel.setReturnListener called ? Well, you set it yourself. The ReturnListener is invoked as soon as any Basic.Return method is read off the socket. > Will it be called when the message does not reach the queue from the > exchange or when the message does reach the consumer from the queue ? This is the difference between immediate and mandatory. Mandatory says "blow up if the msg doesn't make it to a queue". Immediate says "blow up if the msg doesn't make it through a queue to a consumer". > In the clustered mode, exchanges are global across rabbitmq nodes .. are > the queues also global ? They are visible globally within the cluster, but they are located in a node. Matthew ------------------------------ Message: 3 Date: Fri, 21 May 2010 10:52:59 -0600 From: "Jason J. W. Williams" Subject: Re: [rabbitmq-discuss] RabbitMQ failover and message loss To: rabbitmq-discuss at lists.rabbitmq.com Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Great use case for an auto-replay option when dead nodes return. ;) -J On Fri, May 21, 2010 at 8:50 AM, Matthew Sackman wrote: > On Fri, May 21, 2010 at 06:55:57PM +0530, Radha Krishnan D wrote: >> I have 2 brokers clustered with each other. ?They are load balanced by >> having a HA proxy before them. > > Ok, that's not a usual setup. If you actually have the two rabbit nodes > clustered together then you should have no need for the load balancer - > all clients can connect to either node and still reach every resource in > the broker. > >> Now both P1 and C1 get connected to B2 and the test continues till we >> stop all three. >> >> Now, during the failover time we find message losses. >> >> Is it expected ?or can we make sure that no message gets lost. > > That is expected. Queues are located on the node of the connection which > created the queue. When the node goes down, you'll lose that queue. When > your clients (re)connect to the broker and reach the other node, they > are recreating the queues and other resources, but are creating fresh, > empty queues at that point. > > If you need to be able to withstand node failures then currently your > best bet is to use the Pacemaker Active/Passive guide at: > http://www.rabbitmq.com/pacemaker.html > You will need to publish all messages persistent to durable queues. You > should not need the load balancer and pacemaker will correctly ensure > that the two nodes are not both up at the same time. > >> Also, when will be ?channel.setReturnListener ?called ? > > Well, you set it yourself. The ReturnListener is invoked as soon as any > Basic.Return method is read off the socket. > >> Will it be called when the message does not reach the queue from the >> exchange or when the message does reach the consumer from the queue ? > > This is the difference between immediate and mandatory. Mandatory says > "blow up if the msg doesn't make it to a queue". Immediate says "blow up > if the msg doesn't make it through a queue to a consumer". > >> In the clustered mode, exchanges are global across rabbitmq nodes .. are >> the queues also global ? > > They are visible globally within the cluster, but they are located in a > node. > > Matthew > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy Comptech Private Limited is a limited liability company. This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract on behalf of Ivy Comptech Private Limited unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. Registered office: Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, Hyderabad 500 033, Andhra Pradesh, India. Registered number: 37994. Registered in India. A list of members' names is available for inspection at the registered office. From matthew at rabbitmq.com Sat May 22 11:17:26 2010 From: matthew at rabbitmq.com (Matthew Sackman) Date: Sat, 22 May 2010 11:17:26 +0100 Subject: [rabbitmq-discuss] RabbitMQ failover and message loss In-Reply-To: <49A7BA114AAC6A48B9C44CB06B7B987E0A4AC2C8@HYDSVWIN004X.ivycomptech.partygaming.local> References: <49A7BA114AAC6A48B9C44CB06B7B987E0A4AC2C8@HYDSVWIN004X.ivycomptech.partygaming.local> Message-ID: <20100522101726.GB31608@wellquite.org> On Sat, May 22, 2010 at 10:37:18AM +0530, Radha Krishnan D wrote: > > Ok, that's not a usual setup. If you actually have the two rabbit > nodes > > clustered together then you should have no need for the load balancer > - > > all clients can connect to either node and still reach every resource > in > > the broker. > > We want to do graceful failover from one rabbitmq broker to another > rabbitmq broker. So only we used HA proxy. Yes, but you're using clustering. Clustering exists for *scalability*, not HA. If you want HA then use the pacemaker guide I linked to. There, yes, using a proxy on the front is one way to present the service at a common end point, but there are other solutions to the same problem. > The queue is lost when the node is crashed. So all the messages in the > queue at that point are lost. Will those messages be returned to the > producer by using channel.setReturnListener ? I mean, will that listener > be called. No, the messages are lost. They will not be returned. Matthew From tyler at echonest.com Sat May 22 14:21:32 2010 From: tyler at echonest.com (Tyler Williams) Date: Sat, 22 May 2010 09:21:32 -0400 Subject: [rabbitmq-discuss] rabbitmq recovery, channelflow, and clients Message-ID: <8B49B6A4-FB50-4250-9820-D198C6A68662@echonest.com> Hello, I've been playing with the 21673 branch of rabbitmq, and I have a few questions. How does rabbitmq handle bumping up against ulimit -n? After overwhelming rabbitmq with what I think is a misbehaving client, and then restarting it, rabbitmq recovers some of my queues, and none of the messages that were in them. Is this the expected behavior? I see messages like this in rabbit.log for the unrecovered queues: =ERROR REPORT==== 21-May-2010::20:11:07 === ** Generic server <0.981.0> terminating ** Last message in was {init,true} ** When Server state == {q,{amqqueue,{resource,<<"/">>,queue,<<"queue-23">>}, true,false,[],<0.981.0>}, none,none,false,rabbit_variable_queue,undefined, {[],[]}, {[],[]}, undefined,undefined} ** Reason for termination == ** {{badmatch,{error,emfile}}, [{filename,absname,1}, {file_handle_cache,open,3}, {rabbit_queue_index,get_segment_handle,1}, {rabbit_queue_index,load_segment,2}, {rabbit_queue_index,recover_segment,3}, {rabbit_queue_index,'-init_dirty/3-fun-0-',5}, {lists,foldl,3}, {rabbit_queue_index,init_dirty,3}]} With respect to ChannelFlow, when rabbit gets a high mem watermark event and sends out the channelflow command to producers, will it disconnect producers who don't honor this? I've been playing with both pika and amqplib clients. With pika, I see the watermark get set, the flow exception thrown in my producer, and then eventually the watermark gets cleared. With amqplib I see the watermark set but never cleared. I see what looks like some support for flow in amqplib, but I can't tell how it's being used. Any help you can give me is appreciated! Thanks, --tyler From david at rabbitmq.com Sat May 22 17:52:32 2010 From: david at rabbitmq.com (David Wragg) Date: Sat, 22 May 2010 17:52:32 +0100 Subject: [rabbitmq-discuss] help: simple web application integration and testing In-Reply-To: <931675.73803.qm@web45304.mail.sp1.yahoo.com> (go canal's message of "Fri, 21 May 2010 20:09:32 -0700 (PDT)") References: <931675.73803.qm@web45304.mail.sp1.yahoo.com> Message-ID: Hi, go canal writes: > I am new to RabbitMQ, wanted to setup a quick testing web page. This is what I did so far, but I am not able to get anything: > > * Jetty 7.0.2, Spring 3.0.2, running inside Eclipse 3.5.1 > * Using RabbitMQ 1.7.2, amqp-js. RabbitMQ running on localhost. > > [...] > > When clicking the button, I do not see anything. It's difficult to know whether this might be due to a problem in your RabbitMQ installation, or in your amqp-js setup. I'm not sure anyone on the RabbitMQ team has experience with amqp-js, though perhaps other readers of rabbitmq-discuss do. I see that there is a Google group for amqp-js at . Maybe they can give you better advice for pinning down the source of your problem? David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware From matthew at rabbitmq.com Sun May 23 09:32:45 2010 From: matthew at rabbitmq.com (Matthew Sackman) Date: Sun, 23 May 2010 09:32:45 +0100 Subject: [rabbitmq-discuss] rabbitmq recovery, channelflow, and clients In-Reply-To: <8B49B6A4-FB50-4250-9820-D198C6A68662@echonest.com> References: <8B49B6A4-FB50-4250-9820-D198C6A68662@echonest.com> Message-ID: <20100523083245.GA11935@wellquite.org> Hi Tyler, On Sat, May 22, 2010 at 09:21:32AM -0400, Tyler Williams wrote: > I've been playing with the 21673 branch of rabbitmq, and I have a few questions. > > How does rabbitmq handle bumping up against ulimit -n? The long answer is read my blog post about it here: http://www.lshift.net/blog/2010/03/23/the-fine-art-of-holding-a-file-descriptor The short answer is "it copes magically and seemlessly". At least probabilistically. > After overwhelming rabbitmq with what I think is a misbehaving client, and then restarting it, rabbitmq recovers some of my queues, and none of the messages that were in them. Is this the expected behavior? I see messages like this in rabbit.log for the unrecovered queues: Durable queues will survive a broker crash/restart. Persistent messages inside durable queues will too. However, due to buffering in various places you may lose some of the persistent messages inside durable queues, unless you happen to be using transactions. > ** Reason for termination == > ** {{badmatch,{error,emfile}}, Hmm, you really have run out of file descriptors. This is not meant to happen! On Thursday and Friday we added a few fixes to try and prevent some mis-behaving clients from overwhelming Rabbit from the connection point of view (rapidly opening new sockets etc). I've just merged all that into bug21673 so if you pull and try again, I'd be interested to see if things have improved there. But in general, what kinds of things were your misbehaving clients doing to cause this to happen? > With respect to ChannelFlow, when rabbit gets a high mem watermark event and sends out the channelflow command to producers, will it disconnect producers who don't honor this? Not yet, but soon, yes. This is likely to be implemented next week. > I've been playing with both pika and amqplib clients. With pika, I see the watermark get set, the flow exception thrown in my producer, and then eventually the watermark gets cleared. With amqplib I see the watermark set but never cleared. I see what looks like some support for flow in amqplib, but I can't tell how it's being used. There is no support for flow in amqplib. Tony has produced an experimental patch for it (search this list), but I've no idea how fully tested it is. The watermark will eventually get cleared - the goal of the bug21673 branch is to ensure that eventually, Rabbit will always be able to accept another message. Now hard disks aren't as fast as RAM, so from time to time, when we run out of space in RAM, we have no choice but to use flow to stop clients from publishing so as to give ourselves some breathing room to flush out to disk. But the high watermark should always drop, eventually. Best wishes, Matthew From matthias at rabbitmq.com Sun May 23 18:51:34 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Sun, 23 May 2010 18:51:34 +0100 Subject: [rabbitmq-discuss] bql causing crash on startup In-Reply-To: <20100521084131.GA22916@mrnibble.lshift.net> References: <20100520224011.GB7749@wellquite.org> <20100521084131.GA22916@mrnibble.lshift.net> Message-ID: <4BF96B26.9080701@rabbitmq.com> Matthew Sackman wrote: > On Thu, May 20, 2010 at 04:20:44PM -0700, elij wrote: >> Is there a particular version/revision of the plugin-umbrella (or just >> bql) source that will work with the release version of the >> rabbitmq-server (which is 1.7.2 according to the site)? > > Yes, but we don't know what they are. Are plugins are, to date (though > this will change in the future), all "unreleased" - we do not make > binary packages of them available and they are not in any distros. The > only thing we try to ensure is that the latest revisions on all the > default branches work together. Actually, we also try to ensure that *tagged* versions work together. See http://www.rabbitmq.com/mercurial.html#tags Matthias. From matthias at rabbitmq.com Sun May 23 18:56:02 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Sun, 23 May 2010 18:56:02 +0100 Subject: [rabbitmq-discuss] Pika and Channel.Flow In-Reply-To: References: Message-ID: <4BF96C32.4020802@rabbitmq.com> Allan, allan bailey wrote: > I just tried this patch in py-amqplib 0.6.2 and it doesn't seem to work, > or raise an exception. It might be > rabbitmq isn't sending the channel.flow. Check the rabbit.log for memory alarms; that will tell you whether channel.flow is working. > I tested with rabbitmq 1.7.2 on OSX 10.6.2. I'll test on a real OS when > I can. I definately need the flow control > to stop producers from overwhelming the server. If the patch doesn't work, perhaps you could develop one that does and release it, or a forked repo, to the community? Regards, Matthias. From jasonjwwilliams at gmail.com Sun May 23 19:42:45 2010 From: jasonjwwilliams at gmail.com (Jason J. W. Williams) Date: Sun, 23 May 2010 12:42:45 -0600 Subject: [rabbitmq-discuss] Pika and Channel.Flow In-Reply-To: <4BF96C32.4020802@rabbitmq.com> References: <4BF96C32.4020802@rabbitmq.com> Message-ID: What's the dev status on Pika? It seems rather unloved. -J On Sun, May 23, 2010 at 11:56 AM, Matthias Radestock wrote: > Allan, > > allan bailey wrote: >> I just tried this patch in py-amqplib 0.6.2 and it doesn't seem to work, >> or raise an exception. ?It might be >> rabbitmq isn't sending the channel.flow. > > Check the rabbit.log for memory alarms; that will tell you whether > channel.flow is working. > >> I tested with rabbitmq 1.7.2 on OSX 10.6.2. ?I'll test on a real OS when >> I can. ? I definately need the flow control >> to stop producers from overwhelming the server. > > If the patch doesn't work, perhaps you could develop one that does and > release it, or a forked repo, to the community? > > > Regards, > > Matthias. > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > From matthias at rabbitmq.com Sun May 23 19:51:26 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Sun, 23 May 2010 19:51:26 +0100 Subject: [rabbitmq-discuss] Pika and Channel.Flow In-Reply-To: References: <4BF96C32.4020802@rabbitmq.com> Message-ID: <4BF9792E.1000106@rabbitmq.com> Jason, Jason J. W. Williams wrote: > What's the dev status on Pika? It seems rather unloved. I doubt the RabbitMQ core team will get much work done on pika in the next six months. Perhaps somebody else would like to step up to the plate? Are there any specific bug fixes / feature requests you have in mind? Matthias. From jasonjwwilliams at gmail.com Sun May 23 20:17:24 2010 From: jasonjwwilliams at gmail.com (Jason J. W. Williams) Date: Sun, 23 May 2010 13:17:24 -0600 Subject: [rabbitmq-discuss] Pika and Channel.Flow In-Reply-To: <4BF9792E.1000106@rabbitmq.com> References: <4BF96C32.4020802@rabbitmq.com> <4BF9792E.1000106@rabbitmq.com> Message-ID: Hey Matthias, Yeah...it's pretty much at the same usability level as py-amqplib due to the lack of defined exceptions. You have to play with every possible failure behavior to reverse engineer the exceptions that get thrown that will indicate those behaviors. Until Pika develops to have documented, predictable exceptions we're going to stick with py-amqplib and txAMQP. Which is a shame because Pika looks like it'll be a very good replacement for py-amqplib. -J On Sun, May 23, 2010 at 12:51 PM, Matthias Radestock wrote: > Jason, > > Jason J. W. Williams wrote: >> >> What's the dev status on Pika? It seems rather unloved. > > I doubt the RabbitMQ core team will get much work done on pika in the next > six months. Perhaps somebody else would like to step up to the plate? > > Are there any specific bug fixes / feature requests you have in mind? > > > Matthias. > From zirpubolci at gmail.com Mon May 24 19:33:08 2010 From: zirpubolci at gmail.com (allan bailey) Date: Mon, 24 May 2010 11:33:08 -0700 Subject: [rabbitmq-discuss] Pika and Channel.Flow In-Reply-To: <4BF96C32.4020802@rabbitmq.com> References: <4BF96C32.4020802@rabbitmq.com> Message-ID: Matthias, On Sun, May 23, 2010 at 10:56 AM, Matthias Radestock wrote: > Allan, > > > allan bailey wrote: > >> I just tried this patch in py-amqplib 0.6.2 and it doesn't seem to work, >> or raise an exception. It might be >> rabbitmq isn't sending the channel.flow. >> > > Check the rabbit.log for memory alarms; that will tell you whether > channel.flow is working. > > Yes, I see the alarms. But a connected producer is allowed, w/ the patch to continue sending. New producers are disallowed from sending though. So it's close. I need for the connected producer to catch and exception so that it will stop sending. I'll work on this fork and publish it when I get it working with an example. -allan > I tested with rabbitmq 1.7.2 on OSX 10.6.2. I'll test on a real OS when I >> can. I definately need the flow control >> to stop producers from overwhelming the server. >> > > If the patch doesn't work, perhaps you could develop one that does and > release it, or a forked repo, to the community? > > > Regards, > > Matthias. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100524/e99191c1/attachment.htm From zirpubolci at gmail.com Mon May 24 20:45:23 2010 From: zirpubolci at gmail.com (allan bailey) Date: Mon, 24 May 2010 12:45:23 -0700 Subject: [rabbitmq-discuss] Pika and Channel.Flow In-Reply-To: References: <4BF96C32.4020802@rabbitmq.com> Message-ID: If you do a channel.access_request before every channel.basic_publish (or after ever N publishes), then amqplib properly raises the AMQPContentTransmissionForbidden exception since the active state will have been updated. I don't think it's very efficient to do, but it does show that the patch is working. Apparently the AMQP protocol does not send an exception to an active client connection until it reconnects or re-requests access. I definately don't know the AMQP protocol in detail, so someone please correct me if I'm wrong. thanks, Allan On Mon, May 24, 2010 at 11:33 AM, allan bailey wrote: > Matthias, > > On Sun, May 23, 2010 at 10:56 AM, Matthias Radestock < > matthias at rabbitmq.com> wrote: > >> Allan, >> >> >> allan bailey wrote: >> >>> I just tried this patch in py-amqplib 0.6.2 and it doesn't seem to work, >>> or raise an exception. It might be >>> rabbitmq isn't sending the channel.flow. >>> >> >> Check the rabbit.log for memory alarms; that will tell you whether >> channel.flow is working. >> >> > Yes, I see the alarms. But a connected producer is allowed, w/ the patch > to continue sending. > New producers are disallowed from sending though. So it's close. I need > for the connected producer > to catch and exception so that it will stop sending. > > I'll work on this fork and publish it when I get it working with an > example. > > -allan > > >> I tested with rabbitmq 1.7.2 on OSX 10.6.2. I'll test on a real OS when >>> I can. I definately need the flow control >>> to stop producers from overwhelming the server. >>> >> >> If the patch doesn't work, perhaps you could develop one that does and >> release it, or a forked repo, to the community? >> >> >> Regards, >> >> Matthias. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100524/4c78d304/attachment.htm From matthias at rabbitmq.com Mon May 24 20:54:37 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Mon, 24 May 2010 20:54:37 +0100 Subject: [rabbitmq-discuss] Pika and Channel.Flow In-Reply-To: References: <4BF96C32.4020802@rabbitmq.com> Message-ID: <4BFAD97D.4000505@rabbitmq.com> Allan, allan bailey wrote: > Apparently the AMQP protocol does not > send an exception to an active client connection until it reconnects or > re-requests access. When the memory alarm is raised, RabbitMQ sends a channel.flow on all channels. There are no delays other than the usual processing and networking delays. Also, access.request is a no-op in RabbitMQ and has been removed from the AMQP spec in 0-9-1. There is on need for clients to ever invoke it. Matthias. From alexis.richardson at gmail.com Mon May 24 21:08:24 2010 From: alexis.richardson at gmail.com (Alexis Richardson) Date: Mon, 24 May 2010 21:08:24 +0100 Subject: [rabbitmq-discuss] June 9th - Meetup in London Message-ID: Right Let's organise this... Beers on Wednesday June 9th starting at ... 5:30pm? Location? alexis On Wed, May 12, 2010 at 12:22 PM, Alvaro Videla wrote: > That's OK for me, since I'll be arriving in the morning > > > On May 12, 2010, at 7:09 PM, Alexis Richardson wrote: > >> On Wed, May 12, 2010 at 12:05 PM, James Governor wrote: >>> Pub sub. Lets pick it up. Les plans diaboliques. >> >> Merveilleux. >> >> >> >> >>> When in june? >> >> Do as the junians do? >> >> I suggest Wednesday June 9th. >> >> alexis >> >> >>> >>> >>> -----Original Message----- >>> From: alexis.richardson at gmail.com [mailto:alexis.richardson at gmail.com] On >>> Behalf Of Alexis Richardson >>> Sent: 12 May 2010 11:59 >>> To: Alvaro Videla >>> Cc: rabbitmq-discuss; James Governor; Jonathan Lister >>> Subject: Re: [rabbitmq-discuss] Meeting in London >>> >>> Alvaro >>> >>> That sounds like an excellent plan. ?Perhaps it's time for another >>> 'pubsub' meet-up? ?If it is the week of the EF then we can invite a >>> lot of 'NoSQL' folks along too... >>> >>> alexis >>> >>> >>> On Wed, May 12, 2010 at 10:08 AM, Alvaro Videla >>> wrote: >>>> Hi guys/gals, >>>> >>>> I'll asked Alexis about this and he told me to ask here: >>>> >>>> I'll be in London next June for the Erlang Factory. Since I'm traveling >>> from China and I won't be going there any time like every week :) I would >>> like to meet with some of the RabbitMQ guys in London, can we arrange >>> something? >>>> >>>> Perhaps going to a pub or something? >>>> >>>> Regards, >>>> >>>> Alvaro >>>> _______________________________________________ >>>> rabbitmq-discuss mailing list >>>> rabbitmq-discuss at lists.rabbitmq.com >>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>>> >>> > > From zirpubolci at gmail.com Mon May 24 21:48:31 2010 From: zirpubolci at gmail.com (allan bailey) Date: Mon, 24 May 2010 13:48:31 -0700 Subject: [rabbitmq-discuss] Pika and Channel.Flow In-Reply-To: <4BFAD97D.4000505@rabbitmq.com> References: <4BF96C32.4020802@rabbitmq.com> <4BFAD97D.4000505@rabbitmq.com> Message-ID: Matthias, On Mon, May 24, 2010 at 12:54 PM, Matthias Radestock wrote: > Allan, > > > allan bailey wrote: > >> Apparently the AMQP protocol does not >> send an exception to an active client connection until it reconnects or >> re-requests access. >> > > When the memory alarm is raised, RabbitMQ sends a channel.flow on all > channels. There are no delays other than the usual processing and networking > delays. > > Also, access.request is a no-op in RabbitMQ and has been removed from the > AMQP spec in 0-9-1. There is on need for clients to ever invoke it. > > > So should I just redeclare my exchange, would that be a sufficient no-op? I tested it just now and it works to trigger the alert. -allan Matthias. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100524/c3f3fac6/attachment.htm From matthias at rabbitmq.com Tue May 25 06:47:02 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Tue, 25 May 2010 06:47:02 +0100 Subject: [rabbitmq-discuss] Pika and Channel.Flow In-Reply-To: References: <4BF96C32.4020802@rabbitmq.com> <4BFAD97D.4000505@rabbitmq.com> Message-ID: <4BFB6456.2090608@rabbitmq.com> Allan, allan bailey wrote: > On Mon, May 24, 2010 at 12:54 PM, Matthias Radestock > > wrote: > When the memory alarm is raised, RabbitMQ sends a channel.flow on > all channels. There are no delays other than the usual processing > and networking delays. > > So should I just redeclare my exchange, would that be a sufficient no-op? > > I tested it just now and it works to trigger the alert. You shouldn't have to do send any other command - if the client library is implemented correctly. Matthias. From matthias at rabbitmq.com Tue May 25 08:48:05 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Tue, 25 May 2010 08:48:05 +0100 Subject: [rabbitmq-discuss] rabbitmq-jsonrpc "shortcut" HTTP calls? In-Reply-To: References: <14f55851003150951s206bdcb9r5160f73fedbd3926@mail.gmail.com> <4BABDA08.8070506@lshift.net> Message-ID: <4BFB80B5.9020201@rabbitmq.com> Ivan, Ivan Delchev wrote: > Hi Tony, any thoughts for the future about optimizing the HTTP > adapter? Some thoughs were listed previously in this thread but never > got any reply.. Apologies for the delay. We have been rather busy and the HTTP adapter isn't particularly high on our priority list ... >> 1. Combine the "system.describe" calls to /rpc/rabbitmq and >> /rpc/{service_hash}. Return a different hash in the "name" parameter >> if the URL is already in use, otherwise return the same. Thus the 2 >> "system.describe" calls can become 1. Sounds plausible. >> 2. Bundle calls that do not depend on each other in one call - e.g by >> providing an array of method calls, that should be executed in the >> same order. >> >> If no anonymous declarations are used, this should be acceptable: Actually that works for anonymous declarations too, thanks to AMQP's "most recently declared queue" feature that allows methods following an anonymous declaration to refer to the queue by an empty name. >> That should be possible and I think and will save quite some HTTP >> roundtrips. If you provide the server-side I can try to deliver the >> javascript client :) I doubt we will have time to work on this any time soon. Perhaps you could submit patches for both the client and server side? Regards, Matthias. From matthias at rabbitmq.com Tue May 25 09:00:10 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Tue, 25 May 2010 09:00:10 +0100 Subject: [rabbitmq-discuss] socket read timeout in rabbitmq-c In-Reply-To: <131339.14680.qm@web31812.mail.mud.yahoo.com> References: <131339.14680.qm@web31812.mail.mud.yahoo.com> Message-ID: <4BFB838A.5090900@rabbitmq.com> Alex, apologies for the delay in responding to this ... alex chen wrote: > I am wondering if it can support specifying a time out (e.g. > amqp_set_timeout(int timeout)), and add select(timeout) before the > read() in wait_frame? That would seem like a worthwhile addition. Care to submit a patch? > We found in several cases that amqp_channel_open hanged while doing > read() in wait_frame_inner(). That really shouldn't happen, from an AMQP protocol perspective. Was there anything noteworthy in the server logs? Is this reproducible? If so it may help to run via rabbit's tracer (http://www.rabbitmq.com/examples.html#tracer) or wireshark to see what's happening at the protocol level and thus determine whether there is a problem at the server end (highly unlikely) or client. Matthias. From matthias at rabbitmq.com Tue May 25 09:36:11 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Tue, 25 May 2010 09:36:11 +0100 Subject: [rabbitmq-discuss] Caching proxy for cloud HA In-Reply-To: References: Message-ID: <4BFB8BFB.8030808@rabbitmq.com> Jon, Jon Brisbin wrote: > I'm thinking I can also proxy my RabbitMQ servers for HA as well. > > My proxies would be immediately responsive to changes in my cloud > services, so servers will drop off and join the cloud at unknown > intervals. I'm thinking I could have my RMQ clients connect to the HA > proxy, which load-balances requests to the configured back-end > servers. The proxy would have to operate with sticky sessions, since AMQP is a connection/session-oriented protocol, but other than that this should work. > I could easily introduce caching here because the proxy is > transparent. What would the proxy be caching? All AMQP operations carrying payloads are non-idempotent, which makes them unsuitable for caching. > I could duplicate data coming in to multiple > back-end servers Multi-casting doesn't make sense for most operations. The obvious exception is basic.publish. What would you do with the responses from the multiple back-end servers? How would you deal with operations that return different results depending on the back-end server? Anonymous queue declaration is one such example. Also, some aspects of AMQP are inherently racy. For example, operations on different channels can be executed in any order. That too means servers can return different responses for the same series of requests. Regards, Matthias. From jon.brisbin at npcinternational.com Tue May 25 14:29:40 2010 From: jon.brisbin at npcinternational.com (Jon Brisbin) Date: Tue, 25 May 2010 08:29:40 -0500 Subject: [rabbitmq-discuss] Caching proxy for cloud HA In-Reply-To: <4BFB8BFB.8030808@rabbitmq.com> References: <4BFB8BFB.8030808@rabbitmq.com> Message-ID: <8AB83759-BB3B-4C63-9161-FBF8E4DA2C47@npcinternational.com> response below... On May 25, 2010, at 3:36 AM, Matthias Radestock wrote: > Jon, > > Jon Brisbin wrote: >> I'm thinking I can also proxy my RabbitMQ servers for HA as well. >> My proxies would be immediately responsive to changes in my cloud services, so servers will drop off and join the cloud at unknown intervals. I'm thinking I could have my RMQ clients connect to the HA >> proxy, which load-balances requests to the configured back-end servers. > > The proxy would have to operate with sticky sessions, since AMQP is a connection/session-oriented protocol, but other than that this should work. > >> I could easily introduce caching here because the proxy is >> transparent. > > What would the proxy be caching? All AMQP operations carrying payloads are non-idempotent, which makes them unsuitable for caching. > >> I could duplicate data coming in to multiple back-end servers > > Multi-casting doesn't make sense for most operations. The obvious exception is basic.publish. > > What would you do with the responses from the multiple back-end servers? How would you deal with operations that return different results depending on the back-end server? Anonymous queue declaration is one such example. Also, some aspects of AMQP are inherently racy. For example, operations on different channels can be executed in any order. That too means servers can return different responses for the same series of requests. > > > Regards, > > Matthias. Actually, HAProxy does just about everything I need so far, so I'm just using that to front a standard cluster. The HA I was thinking of would basically be a proxy pretending to be a single server. Incoming requests (client -> server) go out to all backend servers and responses (server -> client) go back to the client by using the first responder. The idea is that all backend servers are equal and no matter which one replies, that answer will be valid. It seems to me that any cloud or HA solution is going to involve a middle-man of some sort. No matter what service it is, something like HAProxy will have to be integrated into the platform to allow dynamic membership on the backend with a fixed front-end. As for caching, some of the things I'm using MQ for include running SQL queries. Since the results will be cacheable, I could return the last result directly from the proxy, saving the db connection, etc... and masking the caching from the client. Not everything would be cacheable, of course, but query bodies strike me as something I could easily cache. Jon Brisbin Portal Webmaster NPC International, Inc. From pascal.dergane at sagem.com Tue May 25 15:20:37 2010 From: pascal.dergane at sagem.com (DERGANE Pascal (SAGEM SECURITE)) Date: Tue, 25 May 2010 16:20:37 +0200 Subject: [rabbitmq-discuss] how to get a response from rabbitMq filtering on CorrelationID Message-ID: I implement a java client that allow to publish some message and get response. I have to get response filtered on correlationID. How can I implement that option. Thanks a lot, Pascal # " Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles ou ayant un caract?re priv?. S'ils ne vous sont pas destin?s, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque mani?re que ce soit le contenu. Si ce message vous a ?t? transmis par erreur, merci d'en informer l'exp?diteur et de supprimer imm?diatement de votre syst?me informatique ce courriel ainsi que tous les documents qui y sont attach?s." ****** " This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system." # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100525/467aad8c/attachment.htm From alexis at rabbitmq.com Tue May 25 16:04:10 2010 From: alexis at rabbitmq.com (Alexis Richardson) Date: Tue, 25 May 2010 16:04:10 +0100 Subject: [rabbitmq-discuss] how to get a response from rabbitMq filtering on CorrelationID In-Reply-To: References: Message-ID: Pascal Apologies if this is not what you are looking for, but is it this: http://www.rabbitmq.com/api-guide.html#rpc ? alexis On Tue, May 25, 2010 at 3:20 PM, DERGANE Pascal (SAGEM SECURITE) wrote: > I implement a java client that allow to publish some message and get > response. I have to get response filtered on correlationID. How can I > implement that option. > > Thanks a lot, > > Pascal > > # > " Ce courriel et les documents qui lui sont joints peuvent contenir des > informations confidentielles ou ayant un caract?re priv?. S'ils ne vous sont > pas destin?s, nous vous signalons qu'il est strictement interdit de les > divulguer, de les reproduire ou d'en utiliser de quelque mani?re que ce > soit le contenu. Si ce message vous a ?t? transmis par erreur, merci d'en > informer l'exp?diteur et de supprimer imm?diatement de votre syst?me > informatique ce courriel ainsi que tous les documents qui y sont attach?s." > ??? ??? ??? ??? ??? ??? ??? ??? ****** > " This e-mail and any attached documents may contain confidential or > proprietary information. If you are not the intended recipient, you are > notified that any dissemination, copying of this e-mail and any attachments > thereto or use of their contents by any means whatsoever is strictly > prohibited. If you have received this e-mail in error, please advise the > sender immediately and delete this e-mail and all attached documents > from your computer system." > # > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > From videlalvaro at gmail.com Tue May 25 18:02:46 2010 From: videlalvaro at gmail.com (Alvaro Videla) Date: Wed, 26 May 2010 01:02:46 +0800 Subject: [rabbitmq-discuss] June 9th - Meetup in London In-Reply-To: References: Message-ID: <8EC96D2F-DF66-4261-9D8D-AE9C51D4D068@gmail.com> For me it' ok too, just let me know the details -Alvaro On May 26, 2010, at 1:01 AM, Jonathan Lister wrote: > Sounds good to me. > > On Mon, May 24, 2010 at 9:08 PM, Alexis Richardson > wrote: >> Right >> >> Let's organise this... >> >> Beers on Wednesday June 9th starting at ... 5:30pm? >> >> Location? >> >> alexis >> >> >> >> >> On Wed, May 12, 2010 at 12:22 PM, Alvaro Videla wrote: >>> That's OK for me, since I'll be arriving in the morning >>> >>> >>> On May 12, 2010, at 7:09 PM, Alexis Richardson wrote: >>> >>>> On Wed, May 12, 2010 at 12:05 PM, James Governor wrote: >>>>> Pub sub. Lets pick it up. Les plans diaboliques. >>>> >>>> Merveilleux. >>>> >>>> >>>> >>>> >>>>> When in june? >>>> >>>> Do as the junians do? >>>> >>>> I suggest Wednesday June 9th. >>>> >>>> alexis >>>> >>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: alexis.richardson at gmail.com [mailto:alexis.richardson at gmail.com] On >>>>> Behalf Of Alexis Richardson >>>>> Sent: 12 May 2010 11:59 >>>>> To: Alvaro Videla >>>>> Cc: rabbitmq-discuss; James Governor; Jonathan Lister >>>>> Subject: Re: [rabbitmq-discuss] Meeting in London >>>>> >>>>> Alvaro >>>>> >>>>> That sounds like an excellent plan. Perhaps it's time for another >>>>> 'pubsub' meet-up? If it is the week of the EF then we can invite a >>>>> lot of 'NoSQL' folks along too... >>>>> >>>>> alexis >>>>> >>>>> >>>>> On Wed, May 12, 2010 at 10:08 AM, Alvaro Videla >>>>> wrote: >>>>>> Hi guys/gals, >>>>>> >>>>>> I'll asked Alexis about this and he told me to ask here: >>>>>> >>>>>> I'll be in London next June for the Erlang Factory. Since I'm traveling >>>>> from China and I won't be going there any time like every week :) I would >>>>> like to meet with some of the RabbitMQ guys in London, can we arrange >>>>> something? >>>>>> >>>>>> Perhaps going to a pub or something? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Alvaro >>>>>> _______________________________________________ >>>>>> rabbitmq-discuss mailing list >>>>>> rabbitmq-discuss at lists.rabbitmq.com >>>>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss >>>>>> >>>>> >>> >>> >> > > > > -- > t: @jayfresh > b: http://www.jaybyjayfresh.com From zirpubolci at gmail.com Tue May 25 18:48:35 2010 From: zirpubolci at gmail.com (allan bailey) Date: Tue, 25 May 2010 10:48:35 -0700 Subject: [rabbitmq-discuss] Pika and Channel.Flow In-Reply-To: <4BFB6456.2090608@rabbitmq.com> References: <4BF96C32.4020802@rabbitmq.com> <4BFAD97D.4000505@rabbitmq.com> <4BFB6456.2090608@rabbitmq.com> Message-ID: Matthias, On Mon, May 24, 2010 at 10:47 PM, Matthias Radestock wrote: > Allan, > > allan bailey wrote: > >> On Mon, May 24, 2010 at 12:54 PM, Matthias Radestock < >> matthias at rabbitmq.com > wrote: >> When the memory alarm is raised, RabbitMQ sends a channel.flow on >> all channels. There are no delays other than the usual processing >> and networking delays. >> >> So should I just redeclare my exchange, would that be a sufficient no-op? >> >> I tested it just now and it works to trigger the alert. >> > > You shouldn't have to do send any other command - if the client library is > implemented correctly. > > > Are you suggesting that basic_publish should return something? From my brief reading of the protocol it doesn't return anything. In my code I'm in a tight look just sending messages via basic_publish. At no point does basic_publish notice the channel.flow state change. I'll take a look at the java and/or php clients and see how they handle this. -allan > Matthias. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100525/5907f028/attachment-0001.htm From alexis at rabbitmq.com Tue May 25 19:00:36 2010 From: alexis at rabbitmq.com (Alexis Richardson) Date: Tue, 25 May 2010 19:00:36 +0100 Subject: [rabbitmq-discuss] Pika and Channel.Flow In-Reply-To: References: <4BF96C32.4020802@rabbitmq.com> <4BFAD97D.4000505@rabbitmq.com> <4BFB6456.2090608@rabbitmq.com> Message-ID: Allan I won't speculate as to what Matthias is suggesting; but interestingly there *is* a use case for ack-on-publish. alexis On Tue, May 25, 2010 at 6:48 PM, allan bailey wrote: > Matthias, > > On Mon, May 24, 2010 at 10:47 PM, Matthias Radestock > wrote: >> >> Allan, >> >> allan bailey wrote: >>> >>> On Mon, May 24, 2010 at 12:54 PM, Matthias Radestock >>> > wrote: >>> ? ?When the memory alarm is raised, RabbitMQ sends a channel.flow on >>> ? ?all channels. There are no delays other than the usual processing >>> ? ?and networking delays. >>> >>> So should I just redeclare my exchange, would that be a sufficient no-op? >>> >>> ?I tested it just now and it works to trigger the alert. >> >> You shouldn't have to do send any other command - if the client library is >> implemented correctly. >> >> > > Are you suggesting that basic_publish should return something? ?From my > brief reading of the protocol it doesn't return anything. > In my code I'm in a tight look just sending messages via basic_publish. ?At > no point does basic_publish notice the channel.flow state change. > I'll take a look at the java and/or php clients and see how they handle > this. > -allan > >> >> Matthias. > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > > From matthias at rabbitmq.com Tue May 25 19:58:49 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Tue, 25 May 2010 19:58:49 +0100 Subject: [rabbitmq-discuss] Pika and Channel.Flow In-Reply-To: References: <4BF96C32.4020802@rabbitmq.com> <4BFAD97D.4000505@rabbitmq.com> <4BFB6456.2090608@rabbitmq.com> Message-ID: <4BFC1DE9.6070900@rabbitmq.com> Allan, allan bailey wrote: > Are you suggesting that basic_publish should return something? From my > brief reading of the protocol it doesn't return anything. The basic.publish AMQP command has no response. That doesn't mean the corresponding client library method cannot return something or throw an exception. > In my code I'm in a tight look just sending messages via basic_publish. > At no point does basic_publish notice the channel.flow state change. That's a problem with the library. Once a client library has seen a channel.flow{active=false}, it should a) return channel.flow-ok{active=false}, and b) prevent any further basic.publishes to the channel until a channel.flow{active=true} has been received and replied to. What exactly the library should do when refusing to send a basic.publish is up to the library designer... we have seen all of the following in the wild: - block the thread that is trying to send the basic.publish until flow can resume (that's what the RabbitMQ Java and .net clients do) - throw an exception to the initiator of the basic.publish - silently drop the basic.publish Regards, Matthias. From david at rabbitmq.com Tue May 25 22:51:40 2010 From: david at rabbitmq.com (David Wragg) Date: Tue, 25 May 2010 22:51:40 +0100 Subject: [rabbitmq-discuss] Caching proxy for cloud HA In-Reply-To: <8AB83759-BB3B-4C63-9161-FBF8E4DA2C47@npcinternational.com> (Jon Brisbin's message of "Tue, 25 May 2010 08:29:40 -0500") References: <4BFB8BFB.8030808@rabbitmq.com> <8AB83759-BB3B-4C63-9161-FBF8E4DA2C47@npcinternational.com> Message-ID: Hi Jon, Jon Brisbin writes: > Actually, HAProxy does just about everything I need so far, so I'm > just using that to front a standard cluster. > > The HA I was thinking of would basically be a proxy pretending to be a > single server. Incoming requests (client -> server) go out to all > backend servers and responses (server -> client) go back to the client > by using the first responder. The idea is that all backend servers are > equal and no matter which one replies, that answer will be valid. It > seems to me that any cloud or HA solution is going to involve a > middle-man of some sort. No matter what service it is, something like > HAProxy will have to be integrated into the platform to allow dynamic > membership on the backend with a fixed front-end. What you describe doesn't seem feasible for AMQP, at least in general. Matthias mentioned a few reasons, but I expect it's possible to come up with many more objections. It might be possible to get further by making application-specific assumptions. For example, if you know that certain messages are part of idempotent or cacheable request-response exchanges. But once you start making such assumptions, it's questionable what the result has to do with AMQP. Why not just use an application-specific protocol instead, or HTTP, which explicitly covers issues such as cacheability and idempotency? David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware From jon.brisbin at npcinternational.com Tue May 25 23:12:00 2010 From: jon.brisbin at npcinternational.com (Jon Brisbin) Date: Tue, 25 May 2010 17:12:00 -0500 Subject: [rabbitmq-discuss] Caching proxy for cloud HA In-Reply-To: References: <4BFB8BFB.8030808@rabbitmq.com> <8AB83759-BB3B-4C63-9161-FBF8E4DA2C47@npcinternational.com> Message-ID: <0B9F92ED-58AC-4B40-A7BC-3D54A970986A@npcinternational.com> On May 25, 2010, at 4:51 PM, David Wragg wrote: > What you describe doesn't seem feasible for AMQP, at least in > general. Matthias mentioned a few reasons, but I expect it's possible > to come up with many more objections. I wasn't really looking at AMQP specifically. In my mind, a TCP proxy like HAProxy is just that. It hooks two bytes streams together. On one end is a client that needs to talk to a broker. On the other end are n number of brokers who can talk to the client. The HA in this case is very application and protocol agnostic. It would seem to the broker that a client was directly connected. > It might be possible to get further by making application-specific > assumptions. For example, if you know that certain messages are part of > idempotent or cacheable request-response exchanges. But once you start > making such assumptions, it's questionable what the result has to do > with AMQP. Why not just use an application-specific protocol instead, > or HTTP, which explicitly covers issues such as cacheability and > idempotency? That just doesn't sound like fun at all! :) I'm not interested in re-inventing new protocols to transmit my data. I'm interested in starting n number of clones of a virtual machine on which I have RabbitMQ installed and providing one (or all) of those brokers to a client that needs to send or consume messages and shielding the client from having to know who is active and who isn't. It's a basic cloud scenario where membership in a functional group is dynamic and changeable over time. I don't see that this has anything at all to do with AMQP as a protocol. I'm thinking strictly in terms of TCP byte streams to whatever broker is active. Long-term (and pie-in-the-sky) it would be nice to have all these brokers work together as a unit, but I know that's a long way off. Basic clustering works for me at the size and amount of traffic I give it, so using HAProxy to front these servers seems to approximate very closely what I'm wanting here. What I was thinking was basically HAProxy (which I hadn't heard of until recently) but RabbitMQ-specific. It might even be possible to write an HAProxy handler so you could do acl's for AMQP like you do for TCP and HTTP! :) With dynamic reconfiguration, that would be killer... Jon Brisbin Portal Webmaster NPC International, Inc. From matthias at rabbitmq.com Tue May 25 23:40:33 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Tue, 25 May 2010 23:40:33 +0100 Subject: [rabbitmq-discuss] Caching proxy for cloud HA In-Reply-To: <0B9F92ED-58AC-4B40-A7BC-3D54A970986A@npcinternational.com> References: <4BFB8BFB.8030808@rabbitmq.com> <8AB83759-BB3B-4C63-9161-FBF8E4DA2C47@npcinternational.com> <0B9F92ED-58AC-4B40-A7BC-3D54A970986A@npcinternational.com> Message-ID: <4BFC51E1.4070404@rabbitmq.com> Jon, Jon Brisbin wrote: > I wasn't really looking at AMQP specifically. In my mind, a TCP proxy > like HAProxy is just that. It hooks two bytes streams together. On > one end is a client that needs to talk to a broker. On the other end > are n number of brokers who can talk to the client. The HA in this > case is very application and protocol agnostic. It would seem to the > broker that a client was directly connected. Sure, technically a generic TCP proxy in the way you described could handle AMQP. After all, AMQP travels over TCP. However, what David and I have been trying to point out is that *semantically* that makes no sense at the AMQP level. Two AMQP brokers when fed with the same input data stream will *not* produce the same output data stream. Not even at the level of a single connection, let alone when multiple connections are involved. Regards, Matthias. From simon at rabbitmq.com Wed May 26 16:42:18 2010 From: simon at rabbitmq.com (Simon MacMullen) Date: Wed, 26 May 2010 16:42:18 +0100 Subject: [rabbitmq-discuss] lost message due to binding delay In-Reply-To: References: Message-ID: <4BFD415A.9070400@rabbitmq.com> Hi Aaron. Interesting problem! There are a few possibilities for what could be happening, see below... On 21/05/10 20:57, Aaron Westendorf wrote: > We tracked down an interesting bug today in a 1.7.2 cluster. Our > setup is as follows: > > cluster: 4 hosts, 1 node each ("rabbit1", "rabbit2", "rabbit3", "rabbit4") > clients: 2 services, "serviceA" and "serviceB"; 1 or more processes each > > In this situation both services are connected to rabbit1. Both > services have a standard queue and binding setup that is built into > our application stack so that they can receive messages from our HTTP > bridge, and also receive messages that we send between services. The > queues, bindings and consumers are all declared when the services > start, and the queues are by service name to distribute messages > between all instances of each service. > > The bug occurs when we use the part of our stack that allows serviceA > to query serviceB and receive a response. To be sure that the > response ends up with the right process, each process sets up a queue > that resolves to its host and pid. The queue and its bindings are not > allocated at startup but instead on-demand when services interact. > > Our python driver is a fork of py-amqplib which uses libevent for all > IO and scheduling. The driver has been in use for awhile now, though > it needs a lot of documentation before it is ready to be released into > the wild (we promise, we're working on it). What this means is that > if we have multiple AMQP messages sent during the same event loop > cycle, the bytes reside locally in a buffer until the current cycle > completes. When a write event is processed, we push as many bytes > into the socket buffer as possible, and in this case, likely all of > the bytes would be able to fit into the socket buffer. I'm not completely sure I understand but if you're saying that your driver pipelines synchronous methods (e.g. sends queue.bind in the dialogue below before receiving queue.declare-ok from the broker) then that's very bad. We don't attempt to detect this in the broker (as any such detection would be very racy) but it violates the spec and could cause any sort of weird behaviour. So that's possibility #1. > So, when we perform inter-service communication, the first time it > occurs in that process, the bytes for setting up our subscription are > immediately followed by the message sent to the second service. For > example: > > serviceA: exchange_declare('response', 'topic') # already exists > serviceA: queue_declare('serviceA.response.host.pid') > serviceA: queue_bind('serviceA.response.host.pid', 'response', > routing_key='serviceA.response.host.pid') > serviceA: basic_consume( 'serviceA.response.host.pid' ) > serviceA: tx_select() > serviceA: basic_publish( ) > serviceA: tx_commit() > serviceB: on receipt, do a DB query and send response back to serviceA > > Using our passive listener application, we can confirm that serviceB > writes a response with the correct routing keys, but serviceA never > receives it. Subsequent messages skip everything before > basic_publish() and work as expected. I note you don't talk about channels here. In AMQP the only real ordering guarantees are within channels. So if each service is using more than one channel in the dialogue above then that's possibility #2. > We are unable to reproduce this bug if we're running a single Rabbit > node. The reason I suspect that it's a problem with the > exchange-queue binding is that all of the messages are flowing, which > means that Rabbit is handling the queue_* and tx_* methods in the > order in which we expect them to be processed. Because we're running > this in a cluster, it is necessary for all nodes to register the > binding of the exchange to the queue. I suspect that this is an > asynchronous operation, and that "rabbit1" has not confirmed that the > binding is in place by the time serviceB writes its response. We > don't have exact timings, but the round-trip time for the request and > response is between 1 and 5ms. We have recently found and fixed a bug which could cause messages (internal to Rabbit, so they could be basic.publish, tx.commit or various other things) to overtake each other in certain (we thought) theoretical circumstances. So this could be possibility #3. *However*, queue.bind is not one of the messages that could be overtaken. And I'm afraid binding to a queue is in fact a synchronous operation anyway. So the explanation as presented can't be quite right. And I can't immediately see any other way for something to get overtaken and cause the results you're seeing, although it would help to see the dialogue expanded to show the bit where serviceB replies. But you might want to try compiling from hg (default branch) and see if that fixes your problem. Cheers, Simon From matthias at rabbitmq.com Wed May 26 17:11:48 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Wed, 26 May 2010 17:11:48 +0100 Subject: [rabbitmq-discuss] rabbitmq recovery, channelflow, and clients In-Reply-To: <20100523083245.GA11935@wellquite.org> References: <8B49B6A4-FB50-4250-9820-D198C6A68662@echonest.com> <20100523083245.GA11935@wellquite.org> Message-ID: <4BFD4844.9040308@rabbitmq.com> Tyler, On 23/05/10 09:32, Matthew Sackman wrote: > On Sat, May 22, 2010 at 09:21:32AM -0400, Tyler Williams wrote: >> ** Reason for termination == >> ** {{badmatch,{error,emfile}}, > > Hmm, you really have run out of file descriptors. This is not meant to > happen! On Thursday and Friday we added a few fixes to try and prevent > some mis-behaving clients from overwhelming Rabbit from the connection > point of view (rapidly opening new sockets etc). I've just merged all > that into bug21673 so if you pull and try again, I'd be interested to > see if things have improved there. We since then discovered the most likely source of the problem you encountered, namely that the fd limiting is ineffective during queue recovery. We are working on a fix for that. Note that the bug is specific to the bug21673 branch and will only get triggered if a) rabbit wasn't shut down cleanly, and b) there are lots of durable queues and/or these queues have quite a lot of messages. Regards, Matthias. From aaron at agoragames.com Wed May 26 20:16:16 2010 From: aaron at agoragames.com (Aaron Westendorf) Date: Wed, 26 May 2010 15:16:16 -0400 Subject: [rabbitmq-discuss] lost message due to binding delay In-Reply-To: <4BFD415A.9070400@rabbitmq.com> References: <4BFD415A.9070400@rabbitmq.com> Message-ID: Simon, Thank you for the reply. Responses inline. On Wed, May 26, 2010 at 11:42 AM, Simon MacMullen wrote: > > I'm not completely sure I understand but if you're saying that your > driver pipelines synchronous methods (e.g. sends queue.bind in the > dialogue below before receiving queue.declare-ok from the broker) then > that's very bad. We don't attempt to detect this in the broker (as any > such detection would be very racy) but it violates the spec and could > cause any sort of weird behaviour. So that's possibility #1. Your understanding is correct, and a year ago we implemented a pending queue for basic.consume after running into problems when multiple consume requests were pending. From what you're saying, this scope needs to be expanded to anything with a corresponding "_ok" method, correct? Is there another rule on which methods are synchronous and which are not? For instance, we wrote basic.publish_synchronous to abstract the basic.publish and tx.commit behavior, and that also needed to implement a pending queue of basic.publish calls that is drained as we receive tx.commit_oks, even though basic.publish itself is not a synchronous call. The drivers speed and resource requirements benefit mostly from the evented IO and timers, so we can implement queuing without much overall impact. It seems that much of the spec is written with the expectation of synchronous request-response, which makes an asynchronous driver a bit challenging at times. It does allow our highest-trafficked applications, the protocol bridges (HTTP - Rabbit) to have very high throughput with low overhead. To date, the buffering of data hasn't adversely impacted memory usage because Rabbit kindly works fast enough to not keep data buffered in our clients for long. > I note you don't talk about channels here. In AMQP the only real > ordering guarantees are within channels. So if each service is using > more than one channel in the dialogue above then that's possibility #2. In the context of the transaction taking place, we're using a single channel. We can make use of multiple channels, but not in this case, and we're always using a single channel for a transaction (in the app sense, not tx.* sense). > We have recently found and fixed a bug which could cause messages > (internal to Rabbit, so they could be basic.publish, tx.commit or > various other things) to overtake each other in certain (we thought) > theoretical circumstances. So this could be possibility #3. > > *However*, queue.bind is not one of the messages that could be > overtaken. And I'm afraid binding to a queue is in fact a synchronous > operation anyway. So the explanation as presented can't be quite right. > And I can't immediately see any other way for something to get overtaken > and cause the results you're seeing, although it would help to see the > dialogue expanded to show the bit where serviceB replies. ServiceB would call basic.publish and tx.commit only, having already set up its outbound channel. > But you might want to try compiling from hg (default branch) and see if > that fixes your problem. Will give it a try, but our main cluster is now in production so we will have to spin up our test hosts and an isolated test case. Please let us know what you think of the synchronous vs. pipelining question, i.e. how to know when we should buffer a request. cheers, Aaron -- Aaron Westendorf Senior Software Engineer Agora Games 359 Broadway Troy, NY 12180 Phone: 518.268.1000 aaron at agoragames.com www.agoragames.com From matthias at rabbitmq.com Wed May 26 20:40:55 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Wed, 26 May 2010 20:40:55 +0100 Subject: [rabbitmq-discuss] lost message due to binding delay In-Reply-To: References: <4BFD415A.9070400@rabbitmq.com> Message-ID: <4BFD7947.4010309@rabbitmq.com> Aaron, Aaron Westendorf wrote: > Is there a[nother] rule on which methods are synchronous and > which are not? The AMQP xml spec marks methods with a 'synchronous="1"' when they are synchronous, *except* that many such methods can be turned into asynchronous ones by setting a 'nowait' field. > It seems that much of the spec is written with the > expectation of synchronous request-response Not really. The 'nowait' flag mentioned above, plus features like being able to refer to the "most recently declared queue" are evidence of that. > ServiceB would call basic.publish and tx.commit only, having already > set up its outbound channel. Ah. That could trigger the bug Simon mentioned, causing the commit to get executed before the publish. Regards, Matthias. From pdezwart at rubiconproject.com Wed May 26 22:52:15 2010 From: pdezwart at rubiconproject.com (Pieter de Zwart) Date: Wed, 26 May 2010 14:52:15 -0700 Subject: [rabbitmq-discuss] Librabbitmq Message-ID: Hey Tony & gang, I am having some trouble with the librabbitmq library, and I am hoping you can help me out. We have managed to created a situation whereby a connection gets closed down, but the PHP client does not know about it yet. As a result, when it tries to clean itself up with amqp_channel_close(), a SIGPIPE is thrown and PHP gets all kinds of pissed off. I was wondering if you could help me either: 1. catch SIGPIPE in the PHP C client somehow. (I am a n00b.) 2. pass some sort of flag to the connection to ignore SIGPIPE and return false instead. In case you are as clueless as I am (I am sure you are not, but just in case) I found this: setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&set, sizeof(int)); Thanks! Pieter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100526/ec30a58f/attachment.htm From jacekolszak at gmail.com Thu May 27 13:07:40 2010 From: jacekolszak at gmail.com (jacek_) Date: Thu, 27 May 2010 05:07:40 -0700 (PDT) Subject: [rabbitmq-discuss] Java client problem Message-ID: <28693038.post@talk.nabble.com> Hi, I am testing currently the Java RabbitMQ client. I want to make sure that any problems that can occur with connection to RabbitMQ server will be handled properly. To test if everything is working fine I stopped rabbitmq server proces (using kill -s SIGSTOP command). This imitate more or less problems which can occur in the future. I specified the heartbeat in Java client and want to get exceptions when the server does not respond. Unfortunatelly when the client tries to connect it enters into endless loop. The socket timeout exception is thrown by standard Java socket mechanism but RabbitMQ client catch this exception and retry. No MissedHeartbeatException exception is thrown. I have looked into source code of AMQConnection class and found that method: public void handleSocketTimeout() throws MissedHeartbeatException { if (_heartbeat == 0) { // No heartbeating. Go back and wait some more. return; } _missedHeartbeats++; // We check against 8 = 2 * 4 because we need to wait for at // least two complete heartbeat setting intervals before // complaining, and we've set the socket timeout to a quarter // of the heartbeat setting in setHeartbeat above. if (_missedHeartbeats > (2 * 4)) { throw new MissedHeartbeatException("Heartbeat missing with heartbeat == " + _heartbeat + " seconds"); } } The problem is that _heartbeat field is filled with data after connection is created (not before). The initial value is 0. Until connection is successfully made client will try to connect again and again. Exception will never be thrown, so my application will have no information about server problems. In my opinion only minor changes are required to make this thing work - _hearbeat field should be filled before making the connection. Please correct me if I am wrong. Thanks in advance, Jacek -- View this message in context: http://old.nabble.com/Java-client-problem-tp28693038p28693038.html Sent from the RabbitMQ mailing list archive at Nabble.com. From aaron at agoragames.com Thu May 27 13:49:27 2010 From: aaron at agoragames.com (Aaron Westendorf) Date: Thu, 27 May 2010 08:49:27 -0400 Subject: [rabbitmq-discuss] lost message due to binding delay In-Reply-To: <4BFD7947.4010309@rabbitmq.com> References: <4BFD415A.9070400@rabbitmq.com> <4BFD7947.4010309@rabbitmq.com> Message-ID: > The AMQP xml spec marks methods with a 'synchronous="1"' when they are > synchronous, *except* that many such methods can be turned into asynchronous > ones by setting a 'nowait' field. All of the exchange, queue, binding and consumer declaration methods take a nowait flag, so does that mean that we can set nowait=True and issue them in succession without waiting for the _ok response? On the one hand, that makes sense, but I would expect that nowait would simply imply that the client is not expecting an _ok response, and that the broker's behavior would be identical up until the point that it decided whether to send out an _ok response. I've never liked the split in documentation for the protocol, and missed the sync vs.async descriptors in the xml doc. >> ServiceB would call basic.publish and tx.commit only, having already >> set up its outbound channel. > > Ah. That could trigger the bug Simon mentioned, causing the commit to get > executed before the publish. Interesting, that implies that we could see a widespread problem. So far though, we haven't, and we've been using that pattern for many months now. As the bug we noted only occurred for the first round-trip as the binding was being created, I don't think we've actually encountered this bug yet. Good to know that we should be looking for this. -Aaron -- Aaron Westendorf Senior Software Engineer Agora Games 359 Broadway Troy, NY 12180 Phone: 518.268.1000 aaron at agoragames.com www.agoragames.com From matthias at rabbitmq.com Thu May 27 13:56:15 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Thu, 27 May 2010 13:56:15 +0100 Subject: [rabbitmq-discuss] lost message due to binding delay In-Reply-To: References: <4BFD415A.9070400@rabbitmq.com> <4BFD7947.4010309@rabbitmq.com> Message-ID: <4BFE6BEF.8040500@rabbitmq.com> Aaron, On 27/05/10 13:49, Aaron Westendorf wrote: > All of the exchange, queue, binding and consumer declaration methods > take a nowait flag, so does that mean that we can set nowait=True and > issue them in succession without waiting for the _ok response? Correct. Matthias. From emile at rabbitmq.com Thu May 27 14:52:32 2010 From: emile at rabbitmq.com (Emile Joubert) Date: Thu, 27 May 2010 14:52:32 +0100 Subject: [rabbitmq-discuss] Java client problem In-Reply-To: <28693038.post@talk.nabble.com> References: <28693038.post@talk.nabble.com> Message-ID: <4BFE7920.9040309@rabbitmq.com> Hi Jacek, You are correct that the heartbeat only starts after the connection tuning phase of the protocol negotiation so that both peers agree on the frequency. It would not make sense to throw a heartbeat exception until both peers agreed on a frequency and the heartbeat has started. So I don't think it makes sense to set the value any earlier as you suggest. Can you please confirm what connection retry logic you are referring to - is that logic in the com.rabbitmq.client namespace? Regards Emile jacek_ wrote: > Hi, > > I am testing currently the Java RabbitMQ client. I want to make sure that > any problems that can occur with connection to RabbitMQ server will be > handled properly. To test if everything is working fine I stopped rabbitmq > server proces (using kill -s SIGSTOP command). This imitate more or less > problems which can occur in the future. I specified the heartbeat in Java > client and want to get exceptions when the server does not respond. > Unfortunatelly when the client tries to connect it enters into endless loop. > The socket timeout exception is thrown by standard Java socket mechanism but > RabbitMQ client catch this exception and retry. No MissedHeartbeatException > exception is thrown. I have looked into source code of AMQConnection class > and found that method: > > public void handleSocketTimeout() throws MissedHeartbeatException { > if (_heartbeat == 0) { > // No heartbeating. Go back and wait some more. > return; > } > > _missedHeartbeats++; > > // We check against 8 = 2 * 4 because we need to wait for at > // least two complete heartbeat setting intervals before > // complaining, and we've set the socket timeout to a quarter > // of the heartbeat setting in setHeartbeat above. > if (_missedHeartbeats > (2 * 4)) { > throw new MissedHeartbeatException("Heartbeat missing with > heartbeat == " + > _heartbeat + " seconds"); > } > } > > > The problem is that _heartbeat field is filled with data after connection is > created (not before). The initial value is 0. Until connection is > successfully made client will try to connect again and again. Exception will > never be thrown, so my application will have no information about server > problems. In my opinion only minor changes are required to make this thing > work - _hearbeat field should be filled before making the connection. Please > correct me if I am wrong. > > Thanks in advance, > Jacek From matthias at rabbitmq.com Thu May 27 15:10:19 2010 From: matthias at rabbitmq.com (Matthias Radestock) Date: Thu, 27 May 2010 15:10:19 +0100 Subject: [rabbitmq-discuss] rabbitmq recovery, channelflow, and clients In-Reply-To: <4BFD4844.9040308@rabbitmq.com> References: <8B49B6A4-FB50-4250-9820-D198C6A68662@echonest.com> <20100523083245.GA11935@wellquite.org> <4BFD4844.9040308@rabbitmq.com> Message-ID: <4BFE7D4B.60702@rabbitmq.com> On 26/05/10 17:11, Matthias Radestock wrote: > Tyler, > [...] > We since then discovered the most likely source of the problem you > encountered, namely that the fd limiting is ineffective during queue > recovery. We are working on a fix for that. Fixed on the bug21673 branch. Matthias. From jacekolszak at gmail.com Thu May 27 15:17:16 2010 From: jacekolszak at gmail.com (Jacek Olszak) Date: Thu, 27 May 2010 16:17:16 +0200 Subject: [rabbitmq-discuss] Java client problem In-Reply-To: <4BFE7920.9040309@rabbitmq.com> References: <28693038.post@talk.nabble.com> <4BFE7920.9040309@rabbitmq.com> Message-ID: Hi, first of all thanks for quick reply :) I use classes from "com.rabbitmq.client" package. The code I pasted here is from class com.rabbitmq.client.impl.AMQConnection. My problem is that the client will never throw an exception and will hangs indefinitely until the server socket is closed or the process will continue to work. My idea is that the Java client should throw some exception in such case, because it is possible that under very heavy load or network problems rabbitmq server will not reply in reasonable amount of time. In such case I want to connect to another MQ server. Best regards, Jacek On Thu, May 27, 2010 at 3:52 PM, Emile Joubert wrote: > > Hi Jacek, > > You are correct that the heartbeat only starts after the connection tuning > phase of the protocol negotiation so that both peers agree on the frequency. > It would not make sense to throw a heartbeat exception until both peers > agreed on a frequency and the heartbeat has started. So I don't think it > makes sense to set the value any earlier as you suggest. > > Can you please confirm what connection retry logic you are referring to - is > that logic in the com.rabbitmq.client namespace? > > Regards > > Emile > > > > jacek_ wrote: >> >> Hi, >> I am testing currently the Java RabbitMQ client. I want to make sure that >> any problems that can occur with connection to RabbitMQ server will be >> handled properly. To test if everything is working fine I stopped rabbitmq >> server proces (using kill -s SIGSTOP command). This imitate more or less >> problems which can occur in the future. I specified the heartbeat in Java >> client and want to get exceptions when the server does not respond. >> Unfortunatelly when the client tries to connect it enters into endless >> loop. >> The socket timeout exception is thrown by standard Java socket mechanism >> but >> RabbitMQ client catch this exception and retry. ?No >> MissedHeartbeatException >> exception is thrown. I have looked into source code of AMQConnection class >> and found that method: >> ? ?public void handleSocketTimeout() throws MissedHeartbeatException { >> ? ? if (_heartbeat == 0) { ? ? ? ? ? ? // No heartbeating. Go back and wait >> some more. ? ? ? ? ? ? return; ? ? ? ? } >> ? ? ? ?_missedHeartbeats++; >> ? ? ? ?// We check against 8 = 2 * 4 because we need to wait for at >> ? // least two complete heartbeat setting intervals before ? ? ? ? // >> complaining, and we've set the socket timeout to a quarter ? ? ? ? // of the >> heartbeat setting in setHeartbeat above. ? ? ? ? if (_missedHeartbeats > (2 >> * 4)) { ? ? ? ? ? ? throw new MissedHeartbeatException("Heartbeat missing >> with >> heartbeat == " + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?_heartbeat >> + " seconds"); ? ? ? ? } ? ? } >> >> The problem is that _heartbeat field is filled with data after connection >> is >> created (not before). The initial value is 0. Until connection is >> successfully made client will try to connect again and again. Exception >> will >> never be thrown, so my application will have no information about server >> problems. In my opinion only minor changes are required to make this thing >> work - _hearbeat field should be filled before making the connection. >> Please >> correct me if I am wrong. >> Thanks in advance, Jacek > > From david at rabbitmq.com Thu May 27 15:47:26 2010 From: david at rabbitmq.com (David Wragg) Date: Thu, 27 May 2010 15:47:26 +0100 Subject: [rabbitmq-discuss] Librabbitmq In-Reply-To: (Pieter de Zwart's message of "Wed, 26 May 2010 14:52:15 -0700") References: Message-ID: Hi Pieter, Pieter de Zwart writes: > I am having some trouble with the librabbitmq library, and I am hoping you > can help me out. We have managed to created a situation whereby a connection > gets closed down, but the PHP client does not know about it yet. As a > result, when it tries to clean itself up with amqp_channel_close(), a > SIGPIPE is thrown and PHP gets all kinds of pissed off. > > I was wondering if you could help me either: > > 1. catch SIGPIPE in the PHP C client somehow. (I am a n00b.) > > 2. pass some sort of flag to the connection to ignore SIGPIPE and return > false instead. In case you are as clueless as I am (I am sure you are not, > but just in case) I found this: > setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&set, sizeof(int)); I haven't heard of SO_NOSIGPIPE before - it seems to be only available on OS X. There are a couple of other options: 3. If the process sets the handler for SIGPIPE to SIG_IGN, then SIGPIPE will not be raised, and the offending write call will fail with EPIPE. A lot of UNIX processes do this, I believe; SIGPIPE is often more of a nuisance than a feature. librabbitmq will propagate EPIPE, I expect. 4. If, instead of using write(2), we use send(2) and specify the MSG_NOSIGNAL flag, then SIGPIPE will not be raised, and the send call will fail with EPIPE. It sounds like modifying amqp_channel_close to do this might make sense: There's little value in a SIGPIPE when we are trying to close the connection anyway. Unfortunately, MSG_NOSIGNAL is only supported by some OSes. I suspect that (3) might be your best option, at least for now. It's process wide, but if PHP isn't happy about getting SIGPIPE, that is probably quite reasonable. David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware From brad.smith at fullspectrum.net Thu May 27 16:36:14 2010 From: brad.smith at fullspectrum.net (bradleyd) Date: Thu, 27 May 2010 11:36:14 -0400 Subject: [rabbitmq-discuss] rabbitmq-c and rabbitmq 1.5.4 Message-ID: <4BFE916E.7090504@fullspectrum.net> Hello, I am trying to test rabbitmq-c with rabbitmq 1.5.4--I followed the README in the src--I am running into issue testing the example amqp_sendstring--I think this is the right one. I can see the example send info via ngrep to the mq server. The problem is nothing shows up in the que. I am not sure I am even going about this in the right way. This is what I am passing to amqp_sendstring: ./amqp_sendstring remotehost 5672 amq.direct helloworld foobar I am using Ruby's amqp(6.7) gem as the consumer. Thanks for your time. From pdezwart at rubiconproject.com Thu May 27 16:37:31 2010 From: pdezwart at rubiconproject.com (Pieter de Zwart) Date: Thu, 27 May 2010 08:37:31 -0700 Subject: [rabbitmq-discuss] Librabbitmq In-Reply-To: Message-ID: Hey David, Thanks for the tips. As you could probably tell, I have little knowledge in this area. I will go with option #3 in this case and let you guys know how it work out. Pieter On 5/27/10 7:47 AM, "David Wragg" wrote: > Hi Pieter, > > Pieter de Zwart writes: >> > I am having some trouble with the librabbitmq library, and I am hoping you >> > can help me out. We have managed to created a situation whereby a >> connection >> > gets closed down, but the PHP client does not know about it yet. As a >> > result, when it tries to clean itself up with amqp_channel_close(), a >> > SIGPIPE is thrown and PHP gets all kinds of pissed off. >> > >> > I was wondering if you could help me either: >> > >> > 1. catch SIGPIPE in the PHP C client somehow. (I am a n00b.) >> > >> > 2. pass some sort of flag to the connection to ignore SIGPIPE and return >> > false instead. In case you are as clueless as I am (I am sure you are not, >> > but just in case) I found this: >> > setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&set, sizeof(int)); > > I haven't heard of SO_NOSIGPIPE before - it seems to be only available > on OS X. > > There are a couple of other options: > > 3. If the process sets the handler for SIGPIPE to SIG_IGN, then SIGPIPE > will not be raised, and the offending write call will fail with EPIPE. > A lot of UNIX processes do this, I believe; SIGPIPE is often more of a > nuisance than a feature. librabbitmq will propagate EPIPE, I expect. > > 4. If, instead of using write(2), we use send(2) and specify the > MSG_NOSIGNAL flag, then SIGPIPE will not be raised, and the send call > will fail with EPIPE. It sounds like modifying amqp_channel_close to > do this might make sense: There's little value in a SIGPIPE > when we are trying to close the connection anyway. Unfortunately, > MSG_NOSIGNAL is only supported by some OSes. > > I suspect that (3) might be your best option, at least for now. It's > process wide, but if PHP isn't happy about getting SIGPIPE, that is > probably quite reasonable. > > David > > -- > David Wragg > Staff Engineer, RabbitMQ > SpringSource, a division of VMware > -- the rubicon project PIETER DE ZWART | INTERFACES ENGINEER ??? P 310 207 0272 | x224 ??? F 323 466 7119 1925 S. BUNDY DRIVE LOS ANGELES, CALIFORNIA 90025 WWW.RUBICONPROJECT.COM ?COMPANY OF THE YEAR? ALWAYSON ONMEDIA 2009 #24 ON FAST COMPANY FAST 50 READER FAVORITES 2008 ALWAYSON 250 GLOBAL WINNER 2008 ALWAYSON ONMEDIA 100 WINNER TWIISTUP3 BEST IN SHOW PRICEWATERHOUSECOOPERS ? ENTRETECH BEST STARTUP AMERICAN BUSINESS AWARDS - STEVIES ?08 FINALIST BEST NEW COMPANY AMERICAN BUSINESS AWARDS - STEVIES ?08 FINALIST MOST INNOVATIVE COMPANY AMERICAN BUSINESS AWARDS - STEVIES ?08 FINALIST NEW PRODUCT OR SERVICE - SERVICES P Please consider the environment before printing this e-mail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100527/e310dc35/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 28320 bytes Desc: not available Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100527/e310dc35/attachment-0001.png From emile at rabbitmq.com Thu May 27 17:58:52 2010 From: emile at rabbitmq.com (Emile Joubert) Date: Thu, 27 May 2010 17:58:52 +0100 Subject: [rabbitmq-discuss] Java client problem In-Reply-To: References: <28693038.post@talk.nabble.com> <4BFE7920.9040309@rabbitmq.com> Message-ID: <4BFEA4CC.8070504@rabbitmq.com> Hi Jacek, The core rabbit java client produces a ShutdownSignalException if a java.io.EOFException occurs, providing notification of network problems in the scenario you describe. If the reconnect logic you refer to is in the com.rabbitmq.client namespace then I assume you are using the messagepatterns library. This library aims to provide generic message patterns (including connection reliability) that are typically implemented on top of the core client library. If you don't want connection retries then you can lower the number of retry attempts or use the core library directly. -Emile Jacek Olszak wrote: > Hi, > > first of all thanks for quick reply :) I use classes from > "com.rabbitmq.client" package. The code I pasted here is from class > com.rabbitmq.client.impl.AMQConnection. My problem is that the client > will never throw an exception and will hangs indefinitely until the > server socket is closed or the process will continue to work. My idea > is that the Java client should throw some exception in such case, > because it is possible that under very heavy load or network problems > rabbitmq server will not reply in reasonable amount of time. In such > case I want to connect to another MQ server. > > Best regards, > Jacek > > On Thu, May 27, 2010 at 3:52 PM, Emile Joubert wrote: >> Hi Jacek, >> >> You are correct that the heartbeat only starts after the connection tuning >> phase of the protocol negotiation so that both peers agree on the frequency. >> It would not make sense to throw a heartbeat exception until both peers >> agreed on a frequency and the heartbeat has started. So I don't think it >> makes sense to set the value any earlier as you suggest. >> >> Can you please confirm what connection retry logic you are referring to - is >> that logic in the com.rabbitmq.client namespace? >> >> Regards >> >> Emile >> >> >> >> jacek_ wrote: >>> Hi, >>> I am testing currently the Java RabbitMQ client. I want to make sure that >>> any problems that can occur with connection to RabbitMQ server will be >>> handled properly. To test if everything is working fine I stopped rabbitmq >>> server proces (using kill -s SIGSTOP command). This imitate more or less >>> problems which can occur in the future. I specified the heartbeat in Java >>> client and want to get exceptions when the server does not respond. >>> Unfortunatelly when the client tries to connect it enters into endless >>> loop. >>> The socket timeout exception is thrown by standard Java socket mechanism >>> but >>> RabbitMQ client catch this exception and retry. No >>> MissedHeartbeatException >>> exception is thrown. I have looked into source code of AMQConnection class >>> and found that method: >>> public void handleSocketTimeout() throws MissedHeartbeatException { >>> if (_heartbeat == 0) { // No heartbeating. Go back and wait >>> some more. return; } >>> _missedHeartbeats++; >>> // We check against 8 = 2 * 4 because we need to wait for at >>> // least two complete heartbeat setting intervals before // >>> complaining, and we've set the socket timeout to a quarter // of the >>> heartbeat setting in setHeartbeat above. if (_missedHeartbeats > (2 >>> * 4)) { throw new MissedHeartbeatException("Heartbeat missing >>> with >>> heartbeat == " + _heartbeat >>> + " seconds"); } } >>> >>> The problem is that _heartbeat field is filled with data after connection >>> is >>> created (not before). The initial value is 0. Until connection is >>> successfully made client will try to connect again and again. Exception >>> will >>> never be thrown, so my application will have no information about server >>> problems. In my opinion only minor changes are required to make this thing >>> work - _hearbeat field should be filled before making the connection. >>> Please >>> correct me if I am wrong. >>> Thanks in advance, Jacek >> From alexis at rabbitmq.com Fri May 28 07:46:13 2010 From: alexis at rabbitmq.com (Alexis Richardson) Date: Fri, 28 May 2010 07:46:13 +0100 Subject: [rabbitmq-discuss] Update on broker behaviour. In-Reply-To: <4BFEC788.7020408@rabbitmq.com> References: <4BFEC788.7020408@rabbitmq.com> Message-ID: Hi, I am posting this document on behalf of Michael Bridgen who is away for a couple of days. To follow up from the discussion of AMQP PR3 a few weeks ago, here is a DRAFT proposal for setting out what "Broker Behaviour" means in AMQP 1-0. Many of you have said, on looking at 1-0 drafts, "hey, but where did ... go?". The answer is that 1-0 attempts to break AMQP into parts, which *ulimately* could lead to a protocol that is easier to use and implement. One of those parts is the definition of intermediary / broker behaviour. In Michael's own words: "I think this one at least sets out the stall, on the things it needs to. It still requires: ?- formalisation (and in a few cases, formulation) of requirements ?- possibly, types for broker model items ?- the examples to be filled out Of these, I think the first two should wait until we've had a full discussion of erm, the discussion in the document." Please do comment on this document and indeed on any aspect of the emerging 1-0 documents. alexis -------------- next part -------------- A non-text attachment was scrubbed... Name: amqp-broker.pdf Type: application/pdf Size: 146262 bytes Desc: not available Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100528/316dcf56/attachment-0001.pdf From david at rabbitmq.com Fri May 28 12:06:49 2010 From: david at rabbitmq.com (David Wragg) Date: Fri, 28 May 2010 12:06:49 +0100 Subject: [rabbitmq-discuss] rabbitmq-c and rabbitmq 1.5.4 In-Reply-To: <4BFE916E.7090504@fullspectrum.net> (bradleyd's message of "Thu, 27 May 2010 11:36:14 -0400") References: <4BFE916E.7090504@fullspectrum.net> Message-ID: Hi Brad, bradleyd writes: > I am trying to test rabbitmq-c with rabbitmq 1.5.4--I followed the > README in the src--I am running into issue testing the example > amqp_sendstring--I think this is the right one. I can see the example > send info via ngrep to the mq server. The problem is nothing shows up > in the que. I am not sure I am even going about this in the right way. > This is what I am passing to amqp_sendstring: > ./amqp_sendstring remotehost 5672 amq.direct helloworld foobar > I am using Ruby's amqp(6.7) gem as the consumer. First of all, note that rabbitmq 1.5.4 is quite old - the current version is 1.7.2. While this is unlikely to be the source of your problem, I'd strongly recommend upgrading. I suspect the issue is that you haven't bound your queue. Your amqp_sendstring command is publishing the string "foobar" to the "amq.direct" exchange with the routing key "helloworld". While the AMQP spec says that the borker should automatically supply a direct exchange called "amq.direct", applications still have to bind queues to that exchange if they want messages going to the exchange to appear on queues. This is in contrast to the nameless exchange, to which queues are automatically bound. I can illustrate the difference using the amqp-consume utility that is now supplied with rabbitmq-c. If I ask amqp-consume to consume from a queue "myqueue" with the -q option $ tools/amqp-consume -q myqueue cat and leave it running, and then publish with your command $ examples/amqp_sendstring localhost 5672 amq.direct helloworld foobar amqp-consume doesn't produce any output, because although it has created the queue "myqueue", it has not bound it to any exchanges. But if I now tell it to bind to "amq.direct" with the routing key "helloworld" $ tools/amqp-consume -q myqueue -e amq.direct -r helloworld cat and publish again, it outputs "foobar". Finally, to demonstrate the implicit binds of the nameless exchange, if I once again consume from "myqueue" without binding it $ tools/amqp-consume -q myqueue cat and the publish to the nameless exchange, using "myqueue" as the routing key $ examples/amqp_sendstring localhost 5672 "" myqueue foobar then the amqp-consume outputs "foobar". You should be able to reproduce this behaviour using the Ruby amqp client. You can also use the rabbitmqctl utility supplied with rabbitmq-server to check that your queues and bindings are set up as expected. David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware From ryan.teising at baml.com Fri May 28 16:26:34 2010 From: ryan.teising at baml.com (Teising, Ryan (FICC Principal Technology)) Date: Fri, 28 May 2010 11:26:34 -0400 Subject: [rabbitmq-discuss] Large Message Timeout on Receive Message-ID: <4CF0C7B31BFF934B9F5FBB66A93A6702047E8272@MLNYC20MB052.amrs.win.ml.com> I put together the attached sample code (using the .NET API). <> I put 10 messages on a queue, and then I try to read those same messages off of the queue. The first call to BasicGet returns the first message, but the second call to BasicGet never returns. If I reduce the size of the of the messages down to 4096 bytes (instead of 2097152), then the BasicGet calls work as expected. Is there a size limitation on on messages that can be put on the queue? Ryan Teising 1 Bryant Park 9th Floor, 09N-221 New York, NY 10036 Office: 646-855-2611 Mobile: 201-710-0718 -------------------------------------------------------------------------- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. The information contained in this e-mail was obtained from sources believed to be reliable; however, the accuracy or completeness of this information is not guaranteed. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. References to "Merrill Lynch" are references to any company in the Merrill Lynch & Co., Inc. group of companies, which are wholly-owned by Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Past performance is no guarantee of future results. Attachments that are part of this E-communication may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. -------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100528/829e3a51/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Program.cs Type: application/octet-stream Size: 2588 bytes Desc: Program.cs Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100528/829e3a51/attachment.obj From simon at rabbitmq.com Fri May 28 17:28:29 2010 From: simon at rabbitmq.com (Simon MacMullen) Date: Fri, 28 May 2010 17:28:29 +0100 Subject: [rabbitmq-discuss] Large Message Timeout on Receive In-Reply-To: <4CF0C7B31BFF934B9F5FBB66A93A6702047E8272@MLNYC20MB052.amrs.win.ml.com> References: <4CF0C7B31BFF934B9F5FBB66A93A6702047E8272@MLNYC20MB052.amrs.win.ml.com> Message-ID: <4BFFEF2D.6060906@rabbitmq.com> Hi Ryan. There certainly should not be a problem with messages of that size. I don't have a .NET development environment to hand right now but as a sanity check I converted your test program into Python and it worked fine (against 1.7.2). I'll poke about in the .NET client next week - in the meantime can you confirm the client and server versions you're using? Cheers, Simon On 28/05/10 16:26, Teising, Ryan (FICC Principal Technology) wrote: > I put together the attached sample code (using the .NET API). > > <> > I put 10 messages on a queue, and then I try to read those same messages > off of the queue. > > The first call to BasicGet returns the first message, but the second > call to BasicGet never returns. If I reduce the size of the of the > messages down to 4096 bytes (instead of 2097152), then the BasicGet > calls work as expected. > > Is there a size limitation on on messages that can be put on the queue? > > /Ryan Teising/ > /1 Bryant Park/ > /9th Floor, 09N-221/ > /New York, NY 10036/ > /Office: 646-855-2611/ > /Mobile: 201-710-0718/ > > ------------------------------------------------------------------------ > This message w/attachments (message) may be privileged, confidential or > proprietary, and if you are not an intended recipient, please notify the > sender, do not use or share it and delete it. The information contained > in this e-mail was obtained from sources believed to be reliable; > however, the accuracy or completeness of this information is not > guaranteed. Unless specifically indicated, this message is not an offer > to sell or a solicitation of any investment products or other financial > product or service, an official confirmation of any transaction, or an > official statement of Merrill Lynch. Subject to applicable law, Merrill > Lynch may monitor, review and retain e-communications (EC) traveling > through its networks/systems. The laws of the country of each > sender/recipient may impact the handling of EC, and EC may be archived, > supervised and produced in countries other than the country in which you > are located. This message cannot be guaranteed to be secure or > error-free. References to "Merrill Lynch" are references to any company > in the Merrill Lynch & Co., Inc. group of companies, which are > wholly-owned by Bank of America Corporation. Securities and Insurance > Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose > Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking > Service or Activity * Are Not Insured by Any Federal Government Agency. > Past performance is no guarantee of future results. Attachments that are > part of this E-communication may have additional important disclosures > and disclaimers, which you should read. This message is subject to terms > available at the following link: > http://www.ml.com/e-communications_terms/. By messaging with Merrill > Lynch you consent to the foregoing. > ------------------------------------------------------------------------ > > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss From ryan.teising at baml.com Fri May 28 17:56:50 2010 From: ryan.teising at baml.com (Teising, Ryan (FICC Principal Technology)) Date: Fri, 28 May 2010 12:56:50 -0400 Subject: [rabbitmq-discuss] Large Message Timeout on Receive In-Reply-To: <4BFFEF2D.6060906@rabbitmq.com> References: <4CF0C7B31BFF934B9F5FBB66A93A6702047E8272@MLNYC20MB052.amrs.win.ml.com> <4BFFEF2D.6060906@rabbitmq.com> Message-ID: <4CF0C7B31BFF934B9F5FBB66A93A6702047E8275@MLNYC20MB052.amrs.win.ml.com> Sure, the server version is 1.7.2 and the .NET API Dll is 1.7.2 too. Thanks. Ryan Teising 1 Bryant Park 9th Floor, 09N-221 New York, NY 10036 Office: 646-855-2611 Mobile: 201-710-0718 -----Original Message----- From: rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of Simon MacMullen Sent: Friday, May 28, 2010 12:28 PM To: rabbitmq-discuss at lists.rabbitmq.com Subject: Re: [rabbitmq-discuss] Large Message Timeout on Receive Hi Ryan. There certainly should not be a problem with messages of that size. I don't have a .NET development environment to hand right now but as a sanity check I converted your test program into Python and it worked fine (against 1.7.2). I'll poke about in the .NET client next week - in the meantime can you confirm the client and server versions you're using? Cheers, Simon On 28/05/10 16:26, Teising, Ryan (FICC Principal Technology) wrote: > I put together the attached sample code (using the .NET API). > > <> > I put 10 messages on a queue, and then I try to read those same messages > off of the queue. > > The first call to BasicGet returns the first message, but the second > call to BasicGet never returns. If I reduce the size of the of the > messages down to 4096 bytes (instead of 2097152), then the BasicGet > calls work as expected. > > Is there a size limitation on on messages that can be put on the queue? > > /Ryan Teising/ > /1 Bryant Park/ > /9th Floor, 09N-221/ > /New York, NY 10036/ > /Office: 646-855-2611/ > /Mobile: 201-710-0718/ > > ------------------------------------------------------------------------ > This message w/attachments (message) may be privileged, confidential or > proprietary, and if you are not an intended recipient, please notify the > sender, do not use or share it and delete it. The information contained > in this e-mail was obtained from sources believed to be reliable; > however, the accuracy or completeness of this information is not > guaranteed. Unless specifically indicated, this message is not an offer > to sell or a solicitation of any investment products or other financial > product or service, an official confirmation of any transaction, or an > official statement of Merrill Lynch. Subject to applicable law, Merrill > Lynch may monitor, review and retain e-communications (EC) traveling > through its networks/systems. The laws of the country of each > sender/recipient may impact the handling of EC, and EC may be archived, > supervised and produced in countries other than the country in which you > are located. This message cannot be guaranteed to be secure or > error-free. References to "Merrill Lynch" are references to any company > in the Merrill Lynch & Co., Inc. group of companies, which are > wholly-owned by Bank of America Corporation. Securities and Insurance > Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose > Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking > Service or Activity * Are Not Insured by Any Federal Government Agency. > Past performance is no guarantee of future results. Attachments that are > part of this E-communication may have additional important disclosures > and disclaimers, which you should read. This message is subject to terms > available at the following link: > http://www.ml.com/e-communications_terms/. By messaging with Merrill > Lynch you consent to the foregoing. > ------------------------------------------------------------------------ > > > > _______________________________________________ > rabbitmq-discuss mailing list > rabbitmq-discuss at lists.rabbitmq.com > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss _______________________________________________ rabbitmq-discuss mailing list rabbitmq-discuss at lists.rabbitmq.com http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss -------------------------------------------------------------------------- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. The information contained in this e-mail was obtained from sources believed to be reliable; however, the accuracy or completeness of this information is not guaranteed. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. References to "Merrill Lynch" are references to any company in the Merrill Lynch & Co., Inc. group of companies, which are wholly-owned by Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Past performance is no guarantee of future results. Attachments that are part of this E-communication may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. -------------------------------------------------------------------------- From bobg at uic.edu Fri May 28 21:26:44 2010 From: bobg at uic.edu (Bob Goldstein) Date: Fri, 28 May 2010 15:26:44 -0500 Subject: [rabbitmq-discuss] Can the consumer know who sent the message? In-Reply-To: References: Message-ID: <4C002704.5020705@uic.edu> Is there a way for the message consumer to know the rabbitmq userid of the process that sent the message? I realize there is the props hash, which has a user_id attribute. But I believe props is filled in by the sender, so the sender could forge anything. The best I can figure is to create a queue, and make sure that a particular sender is the only one with privs to write to that queue. However, that seems cumbersome, fragile, and not particularly scalable. I see that the receiver does get info about what exchange was used, and what routing key. But I don't see the sender user_id anywhere. Surely I'm missing something? bobg From jesse at wavemarket.com Fri May 28 23:37:04 2010 From: jesse at wavemarket.com (jesse at wavemarket.com) Date: Fri, 28 May 2010 15:37:04 -0700 (PDT) Subject: [rabbitmq-discuss] detecting publish failure across restart Message-ID: <28712608.post@talk.nabble.com> I'm running RabbitMQ 1.7.2 from package on Ubuntu 10.04 LTS and using the Java Client (also 1.7.2). I'm using a single durable, non-auto delete exchange, a single durable queue, and a single direct binding for a single routing key. I'm testing calls to Channel.basicPublish using persistent, mandatory (but non-immediate) messages. I have another process that consumes the messages, but it's not relevant for this test. My test case was: - Publish ~100K messages - In the middle, restart RabbitMQ - Count the number of messages in the queue according to both my Java client and RabbitMQ (via "rabbitmqctl list_queues") I consistently see that the Java client sends some messages that do not cause an exception and that do not make into the queue. I have a registered ReturnListener, but it does not record any messages being returned. I understand that publishing a message is asynchronous, but surely there must be a way to discover that message was not successfully published. What am I missing? Thanks, Jesse -- View this message in context: http://old.nabble.com/detecting-publish-failure-across-restart-tp28712608p28712608.html Sent from the RabbitMQ mailing list archive at Nabble.com. From sh at defuze.org Sat May 29 09:12:39 2010 From: sh at defuze.org (Sylvain Hellegouarch) Date: Sat, 29 May 2010 10:12:39 +0200 Subject: [rabbitmq-discuss] detecting publish failure across restart In-Reply-To: <28712608.post@talk.nabble.com> References: <28712608.post@talk.nabble.com> Message-ID: Hi Jesse, I understand that publishing a message is asynchronous, but surely there > must be a way to discover that message was not successfully published. What > am I missing? > > > The protocol (I assume 0-8 here) suggests that you set the "mandatory" flag to 1 for each message. If a message cannot be routed from an exchange to at least one queue, it'll be returned to the publisher with a "312 unroutable" error code. You must define a handler for those errors on the publisher side [1] and decide what to do with the returned message. Personally I just keep trying publishing it with after a small period of time. This means my publisher becomes responsible for not losing messages in that specific use case. -- - Sylvain http://www.defuze.org [1] http://www.rabbitmq.com/api-guide.html#returning -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100529/1c6f4cb6/attachment.htm From jesse at wavemarket.com Sat May 29 17:31:49 2010 From: jesse at wavemarket.com (Jesse Myers) Date: Sat, 29 May 2010 09:31:49 -0700 Subject: [rabbitmq-discuss] detecting publish failure across restart In-Reply-To: References: <28712608.post@talk.nabble.com> Message-ID: <4C014175.9090207@wavemarket.com> Hi Sylvain - Thanks for your response. In my case, I am publishing the messages with the mandatory flag set to true and I am registering a ReturnListener with the channel. However, I do not see any messages being returned. For what it's worth, I do see messages returned if I set the immediate flag to true and do not have a consumer running, but that's a different scenario. Jesse On 5/29/10 1:12 AM, Sylvain Hellegouarch wrote: > Hi Jesse, > > > I understand that publishing a message is asynchronous, but surely > there > must be a way to discover that message was not successfully > published. What > am I missing? > > > > > The protocol (I assume 0-8 here) suggests that you set the "mandatory" > flag to 1 for each message. If a message cannot be routed from an > exchange to at least one queue, it'll be returned to the publisher > with a "312 unroutable" error code. You must define a handler for > those errors on the publisher side [1] and decide what to do with the > returned message. Personally I just keep trying publishing it with > after a small period of time. This means my publisher becomes > responsible for not losing messages in that specific use case. > > -- > - Sylvain > http://www.defuze.org > > [1] http://www.rabbitmq.com/api-guide.html#returning > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100529/18db6636/attachment.htm From Kai.Steverding at gws.ms Mon May 31 13:28:58 2010 From: Kai.Steverding at gws.ms (Steverding, Kai) Date: Mon, 31 May 2010 14:28:58 +0200 Subject: [rabbitmq-discuss] RabbitMQ does not start with rabbit-status plugin - broker is running Message-ID: Hi ! I have a Rabbit node running on Ubtuntu 10.04 64 bit (running RabbitMQ 1.7.2). When I put the rabbit-status plugin into the plugin dir and do a rabbitmq-active-plugins, the rabbitmq does not start anymore. Here is what happens : Restarting rabbitmq-server: No nodes running FAILED - check /var/log/rabbitmq/startup_log, _err Startup_log contains : Starting all nodes... Starting node rabbit at rabbit... +---+ +---+ | | | | | | | | | | | | | +---+ +-------+ | | | RabbitMQ +---+ | | | | | | v1.7.2 +---+ | | | +-------------------+ AMQP 8-0 Copyright (C) 2007-2010 LShift Ltd., Cohesive Financial Technologies LLC., and Rabbit Technologies Ltd. Licensed under the MPL. See http://www.rabbitmq.com/ node : rabbit at rabbit app descriptor: /usr/lib/rabbitmq/lib/rabbitmq_server-1.7.2/sbin/../ebin/rabbit.app home dir : /var/lib/rabbitmq cookie hash : 13Uwjf5cBjAWS9rsT6HSIA== log : /var/log/rabbitmq/rabbit.log sasl log : /var/log/rabbitmq/rabbit-sasl.log database dir : /var/lib/rabbitmq/mnesia/rabbit starting internal event notification system ...done starting logging server ...done starting database ...done -- kernel ready starting alarm handler ...done starting queue supervisor ...done starting node monitor ...done starting cluster router ...done -- core initialized starting empty DB check ...done starting codec correctness check ...done starting exchange recovery ...done starting queue recovery ...done starting persister ...done starting guid generator ...done -- message delivery logic ready starting error log relay ...done starting networking ...done -- network listeners available broker running {"Kernel pid terminated",application_controller,"{application_start_failure,rabbit_st atus,{shutdown,{rabbit_status_app,start,[normal,[]]}}}"} Startup_err contains Erlang has closed Error: {node_start_failed,normal} Crash dump was written to: erl_crash.dump Kernel pid terminated (application_controller) ({application_start_failure,rabbit_status,{shutdown,{rabbit_status_app,s tart,[normal,[]]}}}) After reading some older posts containing startup problems, i "hand-started" epmd ( epmd -d >/tmp/emp.log 2>&1) Here is what the log says : epmd: Mon May 31 14:22:08 2010: epmd running - daemon = 0 epmd: Mon May 31 14:22:15 2010: ** got ALIVE2_REQ epmd: Mon May 31 14:22:15 2010: registering 'rabbitmq_multi31265:1', port 57996 epmd: Mon May 31 14:22:15 2010: type 77 proto 0 highvsn 5 lowvsn 5 epmd: Mon May 31 14:22:15 2010: ** sent ALIVE2_RESP for "rabbitmq_multi31265" epmd: Mon May 31 14:22:15 2010: ** got PORT2_REQ epmd: Mon May 31 14:22:15 2010: ** sent PORT2_RESP (error) for "rabbit" epmd: Mon May 31 14:22:15 2010: ** got PORT2_REQ epmd: Mon May 31 14:22:15 2010: ** sent PORT2_RESP (error) for "rabbit" epmd: Mon May 31 14:22:15 2010: ** got ALIVE2_REQ epmd: Mon May 31 14:22:15 2010: registering 'rabbit:1', port 55295 epmd: Mon May 31 14:22:15 2010: type 77 proto 0 highvsn 5 lowvsn 5 epmd: Mon May 31 14:22:15 2010: ** sent ALIVE2_RESP for "rabbit" epmd: Mon May 31 14:22:15 2010: ** got PORT2_REQ epmd: Mon May 31 14:22:15 2010: ** sent PORT2_RESP (ok) for "rabbit" epmd: Mon May 31 14:22:16 2010: unregistering 'rabbit:1', port 55295 epmd: Mon May 31 14:22:17 2010: ** got PORT2_REQ epmd: Mon May 31 14:22:17 2010: ** sent PORT2_RESP (error) for "rabbit" epmd: Mon May 31 14:22:17 2010: unregistering 'rabbitmq_multi31265:1', port 57996 I can't find an obvious reason why it does not start. Can you give me some more directions where to look ? Kai From emile at rabbitmq.com Mon May 31 13:35:31 2010 From: emile at rabbitmq.com (Emile Joubert) Date: Mon, 31 May 2010 13:35:31 +0100 Subject: [rabbitmq-discuss] Large Message Timeout on Receive In-Reply-To: <4CF0C7B31BFF934B9F5FBB66A93A6702047E8275@MLNYC20MB052.amrs.win.ml.com> References: <4CF0C7B31BFF934B9F5FBB66A93A6702047E8272@MLNYC20MB052.amrs.win.ml.com> <4BFFEF2D.6060906@rabbitmq.com> <4CF0C7B31BFF934B9F5FBB66A93A6702047E8275@MLNYC20MB052.amrs.win.ml.com> Message-ID: <4C03AD13.5020605@rabbitmq.com> Ryan, The .net client currently imposes an arbitrary limit of 32Mb on incoming messages. If you exceed this size then a BodyTooLongException will be thrown. Modifying this limit involves changing MaximumPermittedReceivableBodySize in ContentHeaderBase and recompiling. In attempting to replicate your results on commodity hardware I was able to send and receive messages of up to 500Mb before the client ran out of RAM. Transfers took a few seconds and BasicGet never failed to return. Can you confirm whether there was any network activity on port 5672 while waiting for BasicGet? Also, what is the output of "rabbitmqctl list_queues messages_ready messages_unacknowledged memory" on the broker? Regards Emile Op 28/05/2010 17:56, Teising, Ryan (FICC Principal Technology) het geskryf: > Sure, the server version is 1.7.2 and the .NET API Dll is 1.7.2 too. > > Thanks. > > Ryan Teising > 1 Bryant Park > 9th Floor, 09N-221 > New York, NY 10036 > Office: 646-855-2611 > Mobile: 201-710-0718 > > -----Original Message----- > From: rabbitmq-discuss-bounces at lists.rabbitmq.com > [mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of Simon > MacMullen > Sent: Friday, May 28, 2010 12:28 PM > To: rabbitmq-discuss at lists.rabbitmq.com > Subject: Re: [rabbitmq-discuss] Large Message Timeout on Receive > > Hi Ryan. > > There certainly should not be a problem with messages of that size. I > don't have a .NET development environment to hand right now but as a > sanity check I converted your test program into Python and it worked > fine (against 1.7.2). > > I'll poke about in the .NET client next week - in the meantime can you > confirm the client and server versions you're using? > > Cheers, Simon > > On 28/05/10 16:26, Teising, Ryan (FICC Principal Technology) wrote: >> I put together the attached sample code (using the .NET API). >> >> <> >> I put 10 messages on a queue, and then I try to read those same > messages >> off of the queue. >> >> The first call to BasicGet returns the first message, but the second >> call to BasicGet never returns. If I reduce the size of the of the >> messages down to 4096 bytes (instead of 2097152), then the BasicGet >> calls work as expected. >> >> Is there a size limitation on on messages that can be put on the > queue? From david at rabbitmq.com Mon May 31 14:21:57 2010 From: david at rabbitmq.com (David Wragg) Date: Mon, 31 May 2010 14:21:57 +0100 Subject: [rabbitmq-discuss] detecting publish failure across restart In-Reply-To: <28712608.post@talk.nabble.com> (jesse@wavemarket.com's message of "Fri, 28 May 2010 15:37:04 -0700 (PDT)") References: <28712608.post@talk.nabble.com> Message-ID: Hi Jesse, "jesse at wavemarket.com" writes: > I consistently see that the Java client sends some messages that do not > cause an exception and that do not make into the queue. I have a registered > ReturnListener, but it does not record any messages being returned. > > I understand that publishing a message is asynchronous, but surely there > must be a way to discover that message was not successfully published. What > am I missing? This is almost certainly due to the issue that AMQP's basic.publish has no corresponding response from the server to the client (at least, not in the normal case). Once a client has written the basic.publish command otyo to the socket, it has done all it can. So when you restart RabbitMQ, the client has no way to know which publishes have been recieved and processed by the server, and which are merely in transmission (i.e. in the operating system's TCP socket buffer on the client of server). This lack of publish acks is often noted as a significant omission from AMQP. The workaroud is to use the transaction support in AMQP: Start a transaction (with Channel.txSelect), do some publishes on the channel, and then commit the transaction (with Channel.txCommit). If the commit completes successfully, you know that the publishes have taken place on the server. David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware From matthew at rabbitmq.com Mon May 31 14:42:14 2010 From: matthew at rabbitmq.com (Matthew Sackman) Date: Mon, 31 May 2010 14:42:14 +0100 Subject: [rabbitmq-discuss] detecting publish failure across restart In-Reply-To: References: <28712608.post@talk.nabble.com> Message-ID: <20100531134213.GA7172@wellquite.org> On Mon, May 31, 2010 at 02:21:57PM +0100, David Wragg wrote: > The workaroud is to use the transaction support in AMQP: Start a > transaction (with Channel.txSelect), do some publishes on the channel, > and then commit the transaction (with Channel.txCommit). If the commit > completes successfully, you know that the publishes have taken place on > the server. Note that doing this converts the semantics from "at most once" to "at least once". I.e. before, with mandatory set, you will not have to deal with duplicates - if the error (due to not being able to route the msg to a queue) gets lost (network issue or client/server crashing) then the published message is lost, but you don't run the risk of duplicates - even in the case where you republish if you get the delivery failure. With transactions, there's the possibility that the commit_ok message gets lost as it goes back from the server to the client. In that case you have no choice but to assume in the client that the server has not accepted responsibility for the messages in the transaction and thus you must republish yourself. However, if it's just the commit_ok message that got lost then you'll be publishing the same messages more than once and thus you need to account for the possibility of duplicates when receiving messages. Matthew From sh at defuze.org Mon May 31 20:13:33 2010 From: sh at defuze.org (Sylvain Hellegouarch) Date: Mon, 31 May 2010 21:13:33 +0200 Subject: [rabbitmq-discuss] detecting publish failure across restart In-Reply-To: References: <28712608.post@talk.nabble.com> Message-ID: Hi David, > The workaroud is to use the transaction support in AMQP: Start a > transaction (with Channel.txSelect), do some publishes on the channel, > and then commit the transaction (with Channel.txCommit). If the commit > completes successfully, you know that the publishes have taken place on > the server. > > I'm curious, in the general case, what's the cost of using a transaction? Does it consume more resources? Roughly, what takes place within RabbitMQ? Cheers, -- - Sylvain http://www.defuze.org http://twitter.com/lawouach -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100531/2d18787d/attachment.htm From david at rabbitmq.com Mon May 31 21:30:42 2010 From: david at rabbitmq.com (David Wragg) Date: Mon, 31 May 2010 21:30:42 +0100 Subject: [rabbitmq-discuss] detecting publish failure across restart In-Reply-To: (Sylvain Hellegouarch's message of "Mon, 31 May 2010 21:13:33 +0200") References: <28712608.post@talk.nabble.com> Message-ID: Hi Sylvain, Sylvain Hellegouarch writes: > I'm curious, in the general case, what's the cost of using a transaction? > Does it consume more resources? Roughly, what takes place within > RabbitMQ? There is indeed a cost associated with a transaction. One source of overhead is the fact that the AMQP tx.commit method is synchronous, and so involves a round-trip over the network to the server. Another is the fact that when the server commits a transaction, it must make sure that the relevant effects of a transaction have reached stable storage (e.g. that a persistent message that reaches a queue has been stored on disk). My colleagues might be able to list other costs. It's difficult to quantify these costs in general, but I think its fair to say that they have a significant impact compared with non-transactional uses of AMQP. The MulticastMain tool included with our Java client library has command line options that allow the impact to be measured in various scenarios. David -- David Wragg Staff Engineer, RabbitMQ SpringSource, a division of VMware