[clojure-rabbitmq] OpenTracing API with Langohr
Has anyone done this? We have a distributed system that uses langohr for messaging between services. We are trying to add distributed tracing to this system with opentracing.io. Does anyone know if it would be possible, for example, to use the opentracing rabbitmq client <https://github.com/opentracing-contrib/java-rabbitmq-client> with langohr in place of the default client? Or some other way to propagate span and trace IDs along with messages? Thanks -- You received this message because you are subscribed to the Google Groups "clojure-rabbitmq" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure-rabbitmq/b05f457d-0b78-4e39-b555-a7714bfbc03d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] Are lazy queues still bound by memory limit?
Thank you! On Sunday, September 17, 2017 at 11:32:17 PM UTC-5, Michael Klishin wrote: > > The point of lazy queues is not that nothing ever is stored in memory. > It's that queues try to move messages > to disk very aggressively (default mode keeps a portion in RAM using > metrics such as ingress/egress rates and various > configurable values). > > On Sun, Sep 17, 2017 at 10:29 PM, Michael Klishin <mkli...@pivotal.io > > wrote: > >> This is a question for rabbitmq-users but I'm happy to answer it here. >> >> Lazy queues per se don't have a limit but RabbitMQ message store still >> does: when messages >> are sent to the message store [as opposed to being embedded into queue >> index], message store index(es) >> come into play and by default the index is in-memory. >> >> There is a plugin [1] that lets you use LevelDB for the index. Even >> though LevelDB is an efficient >> data store, expect a write throughput hit compared to the default >> implementation. >> >> 1. https://github.com/rabbitmq/rabbitmq-msg-store-index-eleveldb >> >> On Sun, Sep 17, 2017 at 8:25 PM, Steve Suehs <skelt...@gmail.com >> > wrote: >> >>> I've been experimenting with Clojure and RabbitMQ using the langohr >>> library. Thank you for building and sharing it. >>> >>> I've been learning more about the care and feeding of a rabbitmq >>> server. I crashed mine installed on my dev laptop several times by filling >>> a queue with messages. If queues fill up and memory gets tight, a server >>> can be overwhelmed and fall over. If I set or arrange for a reasonable >>> memory limit, things go ok. I am now running RabbitMQ in a Docker container >>> with a memory limit. >>> >>> My latest experiments were with lazy queues, which are supposed to write >>> events to disk and not exhaust memory. I still seem to hit..well, not hit, >>> rather, an asymptotic limit at around 261 million events in the queue. Is >>> this considered outrageously and unreasonably large? Publication rate >>> slowed to 700/s. >>> >>> I also notice that if the consumers are caught up with the producer >>> everything seems to scream at twice the rate than when storage is used. If >>> storage is used I'm seeing about 6000r/s. That's cool...just not exactly >>> what I expected from the description of a lazy queue. >>> >>> >>> <https://lh3.googleusercontent.com/-XSzuKvXxMxI/Wb8uHb7LKmI/EYA/G6V5v93_yGcJW6jFPCnQUUBOp1LGCm7nQCLcBGAs/s1600/rabbitmqLimit.png> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "clojure-rabbitmq" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure-rabbit...@googlegroups.com . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> MK >> >> Staff Software Engineer, Pivotal/RabbitMQ >> > > > > -- > MK > > Staff Software Engineer, Pivotal/RabbitMQ > -- You received this message because you are subscribed to the Google Groups "clojure-rabbitmq" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] Are lazy queues still bound by memory limit?
The point of lazy queues is not that nothing ever is stored in memory. It's that queues try to move messages to disk very aggressively (default mode keeps a portion in RAM using metrics such as ingress/egress rates and various configurable values). On Sun, Sep 17, 2017 at 10:29 PM, Michael Klishin <mklis...@pivotal.io> wrote: > This is a question for rabbitmq-users but I'm happy to answer it here. > > Lazy queues per se don't have a limit but RabbitMQ message store still > does: when messages > are sent to the message store [as opposed to being embedded into queue > index], message store index(es) > come into play and by default the index is in-memory. > > There is a plugin [1] that lets you use LevelDB for the index. Even though > LevelDB is an efficient > data store, expect a write throughput hit compared to the default > implementation. > > 1. https://github.com/rabbitmq/rabbitmq-msg-store-index-eleveldb > > On Sun, Sep 17, 2017 at 8:25 PM, Steve Suehs <skelter@gmail.com> > wrote: > >> I've been experimenting with Clojure and RabbitMQ using the langohr >> library. Thank you for building and sharing it. >> >> I've been learning more about the care and feeding of a rabbitmq server. >> I crashed mine installed on my dev laptop several times by filling a queue >> with messages. If queues fill up and memory gets tight, a server can be >> overwhelmed and fall over. If I set or arrange for a reasonable memory >> limit, things go ok. I am now running RabbitMQ in a Docker container with a >> memory limit. >> >> My latest experiments were with lazy queues, which are supposed to write >> events to disk and not exhaust memory. I still seem to hit..well, not hit, >> rather, an asymptotic limit at around 261 million events in the queue. Is >> this considered outrageously and unreasonably large? Publication rate >> slowed to 700/s. >> >> I also notice that if the consumers are caught up with the producer >> everything seems to scream at twice the rate than when storage is used. If >> storage is used I'm seeing about 6000r/s. That's cool...just not exactly >> what I expected from the description of a lazy queue. >> >> >> <https://lh3.googleusercontent.com/-XSzuKvXxMxI/Wb8uHb7LKmI/EYA/G6V5v93_yGcJW6jFPCnQUUBOp1LGCm7nQCLcBGAs/s1600/rabbitmqLimit.png> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "clojure-rabbitmq" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure-rabbitmq+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > MK > > Staff Software Engineer, Pivotal/RabbitMQ > -- MK Staff Software Engineer, Pivotal/RabbitMQ -- You received this message because you are subscribed to the Google Groups "clojure-rabbitmq" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] Are lazy queues still bound by memory limit?
This is a question for rabbitmq-users but I'm happy to answer it here. Lazy queues per se don't have a limit but RabbitMQ message store still does: when messages are sent to the message store [as opposed to being embedded into queue index], message store index(es) come into play and by default the index is in-memory. There is a plugin [1] that lets you use LevelDB for the index. Even though LevelDB is an efficient data store, expect a write throughput hit compared to the default implementation. 1. https://github.com/rabbitmq/rabbitmq-msg-store-index-eleveldb On Sun, Sep 17, 2017 at 8:25 PM, Steve Suehs <skelter@gmail.com> wrote: > I've been experimenting with Clojure and RabbitMQ using the langohr > library. Thank you for building and sharing it. > > I've been learning more about the care and feeding of a rabbitmq server. > I crashed mine installed on my dev laptop several times by filling a queue > with messages. If queues fill up and memory gets tight, a server can be > overwhelmed and fall over. If I set or arrange for a reasonable memory > limit, things go ok. I am now running RabbitMQ in a Docker container with a > memory limit. > > My latest experiments were with lazy queues, which are supposed to write > events to disk and not exhaust memory. I still seem to hit..well, not hit, > rather, an asymptotic limit at around 261 million events in the queue. Is > this considered outrageously and unreasonably large? Publication rate > slowed to 700/s. > > I also notice that if the consumers are caught up with the producer > everything seems to scream at twice the rate than when storage is used. If > storage is used I'm seeing about 6000r/s. That's cool...just not exactly > what I expected from the description of a lazy queue. > > > <https://lh3.googleusercontent.com/-XSzuKvXxMxI/Wb8uHb7LKmI/EYA/G6V5v93_yGcJW6jFPCnQUUBOp1LGCm7nQCLcBGAs/s1600/rabbitmqLimit.png> > > > > -- > You received this message because you are subscribed to the Google Groups > "clojure-rabbitmq" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure-rabbitmq+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- MK Staff Software Engineer, Pivotal/RabbitMQ -- You received this message because you are subscribed to the Google Groups "clojure-rabbitmq" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[clojure-rabbitmq] Are lazy queues still bound by memory limit?
I've been experimenting with Clojure and RabbitMQ using the langohr library. Thank you for building and sharing it. I've been learning more about the care and feeding of a rabbitmq server. I crashed mine installed on my dev laptop several times by filling a queue with messages. If queues fill up and memory gets tight, a server can be overwhelmed and fall over. If I set or arrange for a reasonable memory limit, things go ok. I am now running RabbitMQ in a Docker container with a memory limit. My latest experiments were with lazy queues, which are supposed to write events to disk and not exhaust memory. I still seem to hit..well, not hit, rather, an asymptotic limit at around 261 million events in the queue. Is this considered outrageously and unreasonably large? Publication rate slowed to 700/s. I also notice that if the consumers are caught up with the producer everything seems to scream at twice the rate than when storage is used. If storage is used I'm seeing about 6000r/s. That's cool...just not exactly what I expected from the description of a lazy queue. <https://lh3.googleusercontent.com/-XSzuKvXxMxI/Wb8uHb7LKmI/EYA/G6V5v93_yGcJW6jFPCnQUUBOp1LGCm7nQCLcBGAs/s1600/rabbitmqLimit.png> -- You received this message because you are subscribed to the Google Groups "clojure-rabbitmq" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] RabbitMQ Langohr no heartbeat
I am traveling till mid-May, we will see how it goes. > On 22 abr 2016, at 13:35, David Smith <shmish...@gmail.com> wrote: > > Hi Guys, > > I realise you are busy, I'm just checking the status on this to make sure it > doesn't get forgotten :) > > When I posted the issue initially it was just a theoretical problem but we > have now had a situation where it caused real problems. > > Thanks, > > David. > >> On Thursday, April 14, 2016 at 5:30:53 PM UTC+1, David Smith wrote: >> Attached is a wireshark capture, hope this helps. > > -- > You received this message because you are subscribed to the Google Groups > "clojure-rabbitmq" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure-rabbitmq+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "clojure-rabbitmq" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] RabbitMQ Langohr no heartbeat
Hi Guys, I realise you are busy, I'm just checking the status on this to make sure it doesn't get forgotten :) When I posted the issue initially it was just a theoretical problem but we have now had a situation where it caused real problems. Thanks, David. On Thursday, April 14, 2016 at 5:30:53 PM UTC+1, David Smith wrote: > > Attached is a wireshark capture, hope this helps. > -- You received this message because you are subscribed to the Google Groups "clojure-rabbitmq" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] RabbitMQ Langohr no heartbeat
Attached is a wireshark capture, hope this helps. -- You received this message because you are subscribed to the Google Groups "clojure-rabbitmq" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. rabbit.pcapng Description: Binary data
Re: [clojure-rabbitmq] RabbitMQ Langohr no heartbeat
No, I wasn't referring to the TCP connection timeout. Can you please take a Wireshark capture? Our team is quite busy this and next week. > On 14 abr 2016, at 17:42, David Smith <shmish...@gmail.com> wrote: > > What I see in langohr is that the following are set: > > (doto cf > (.setClientProperties client-properties) > (.setUsername username) > (.setPassword password) > (.setVirtualHostvhost) > (.setHost host) > (.setPort final-port) > (.setRequestedHeartbeat requested-heartbeat) > (.setConnectionTimeout connection-timeout) > (.setRequestedChannelMax requested-channel-max)) > > I am setting connection-timeout and requested-heartbeat, isn't that what you > meant by setting a timeout? > >> On Thu, Apr 14, 2016 at 3:39 PM, David Smith <shmish...@gmail.com> wrote: >> I'm using 3.5.1 which is the latest version according to github and clojars. >> >> I am running rabbit as a docker container using docker-machine and image >> rabbitmq:3-management >> >>> On Thu, Apr 14, 2016 at 3:33 PM, Michael Klishin <mklis...@pivotal.io> >>> wrote: >>> Langohr is a wrapper around RabbitMQ Java client and in recent versions >>> relies on it to also perform connection recocovery. >>> Heartbeats were never implemented in Clojure. >>> >>> Your Langohr version is from 2014 or so. Have you considered trying the >>> most recent release (or does it still use 2014 in client properties? Also >>> possible) >>> >>> Anyhow, investigating this kind if issues would be the same with every >>> client library:) >>> >>>> On 14 abr 2016, at 17:29, David Smith <shmish...@gmail.com> wrote: >>>> >>>> It was just that it sounded like you were answering the question from a >>>> Java perspective but didn't know anything about the Clojure wrapper, but I >>>> can see from the connections page that you wrote it :) I couldn't see >>>> anything about the heartbeat on the connections page, just: >>>> >>>> productLangohr >>>> copyright Copyright (C) 2011-2014 Michael S. Klishin, Alex Petrov >>>> capabilities >>>> exchange_exchange_bindings:true >>>> connection.blocked:true >>>> authentication_failure_close: true >>>> basic.nack:true >>>> publisher_confirms:true >>>> consumer_cancel_notify:true >>>> informationSee http://clojurerabbitmq.info/ >>>> version3.0.x >>>> platform Clojure 1.8.0 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_66 >>>> >>>>> On Thu, Apr 14, 2016 at 3:25 PM, Michael Klishin <mklis...@pivotal.io> >>>>> wrote: >>>>> It is. What difference does it make? We need to base our assumptions on >>>>> data and network traffic capture is the best data we can get. Server logs >>>>> are also helpful and trivial to collect. >>>>> >>>>>> On 14 abr 2016, at 17:22, David Smith <shmish...@gmail.com> wrote: >>>>>> >>>>>> Isn't this a mailing list for the Clojure client? >>>>>> >>>>>>> On Thu, Apr 14, 2016 at 2:21 PM, Michael Klishin <mklis...@pivotal.io> >>>>>>> wrote: >>>>>>> Also, please post full RabbitMQ logs and ideally a Wireshark traffic >>>>>>> capture. With the amount of information we have at the moment the best >>>>>>> we can do is guessing. >>>>>>> >>>>>>>> On 14 abr 2016, at 14:39, David Smith <shmish...@gmail.com> wrote: >>>>>>>> >>>>>>> >>>>>>>> I have tried (connection (assoc (:rabbit conf) :requested-heartbeat 3 >>>>>>>> :automatically-recover false :connection-timeout 5)) based on what you >>>>>>>> said but no joy, I would have thought I would at least see something >>>>>>>> in the logs to suggest it's trying to do something. I thought the >>>>>>>> connection was supposed to be closed if 2 heartbeats were missed? >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>>> On Thu, Apr 14, 2016 at 12:31 PM, Michael Klishin >>>>>>>>> <mklis...@pivotal.io> wrote: >>>>>>&g
Re: [clojure-rabbitmq] RabbitMQ Langohr no heartbeat
OK, that also reveals that RabbitMQ is running in a remote host, which I expected but wasn't sure. Are there any load balancers involved? > On 14 abr 2016, at 17:33, David Smith <shmish...@gmail.com> wrote: > > Nothing in the logs, just the open connection line then nothing: > > =INFO REPORT 14-Apr-2016::14:27:45 === > accepting AMQP connection <0.1484.0> (192.168.99.1:50383 -> 172.17.0.2:5672) > > >> On Thu, Apr 14, 2016 at 3:29 PM, David Smith <shmish...@gmail.com> wrote: >> It was just that it sounded like you were answering the question from a Java >> perspective but didn't know anything about the Clojure wrapper, but I can >> see from the connections page that you wrote it :) I couldn't see anything >> about the heartbeat on the connections page, just: >> >> product Langohr >> copyrightCopyright (C) 2011-2014 Michael S. Klishin, Alex Petrov >> capabilities >> exchange_exchange_bindings: true >> connection.blocked: true >> authentication_failure_close:true >> basic.nack: true >> publisher_confirms: true >> consumer_cancel_notify: true >> information See http://clojurerabbitmq.info/ >> version 3.0.x >> platform Clojure 1.8.0 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_66 >> >>> On Thu, Apr 14, 2016 at 3:25 PM, Michael Klishin <mklis...@pivotal.io> >>> wrote: >>> It is. What difference does it make? We need to base our assumptions on >>> data and network traffic capture is the best data we can get. Server logs >>> are also helpful and trivial to collect. >>> >>>> On 14 abr 2016, at 17:22, David Smith <shmish...@gmail.com> wrote: >>>> >>>> Isn't this a mailing list for the Clojure client? >>>> >>>>> On Thu, Apr 14, 2016 at 2:21 PM, Michael Klishin <mklis...@pivotal.io> >>>>> wrote: >>>>> Also, please post full RabbitMQ logs and ideally a Wireshark traffic >>>>> capture. With the amount of information we have at the moment the best we >>>>> can do is guessing. >>>>> >>>>>> On 14 abr 2016, at 14:39, David Smith <shmish...@gmail.com> wrote: >>>>>> >>>>> >>>>>> I have tried (connection (assoc (:rabbit conf) :requested-heartbeat 3 >>>>>> :automatically-recover false :connection-timeout 5)) based on what you >>>>>> said but no joy, I would have thought I would at least see something in >>>>>> the logs to suggest it's trying to do something. I thought the >>>>>> connection was supposed to be closed if 2 heartbeats were missed? >>>>>> >>>>>> Thanks. >>>>>> >>>>>>> On Thu, Apr 14, 2016 at 12:31 PM, Michael Klishin <mklis...@pivotal.io> >>>>>>> wrote: >>>>>>> You can see effective heartbeat in the management UI on the connection >>>>>>> page. >>>>>>> >>>>>>> Heartbeats do not close connection and it't not correct that connection >>>>>>> should be considered dead in 1.5 seconds with a 3 second interval: it >>>>>>> will be 3 seconds. >>>>>>> >>>>>>> I'm curious if Langohr simply tries to re-connect because missed >>>>>>> heartbeats are treated the same way as connection loss in recent Java >>>>>>> client versions: is connection recovery enabled? >>>>>>> >>>>>>>> On 14 abr 2016, at 14:20, David Smith <shmish...@gmail.com> wrote: >>>>>>>> >>>>>>>> Can anyone help me with this >>>>>>>> http://stackoverflow.com/questions/36596446/rabbitmq-langohr-no-heartbeat >>>>>>>> >>>>>>>> I am setting up a connection to Rabbit using >>>>>>>> >>>>>>>> (rmq/connect (assoc (:rabbit conf) :requested-heartbeat 3)) >>>>>>>> I have 3 subscribers to 3 channels, no producers. When I shutdown the >>>>>>>> rabbit server, nothing happens to my client. I would expect it to >>>>>>>> report missing heartbeat after 1.5 seconds and close the connection >>>>>>>> after 3 seconds. I have left the program running with rabbit down for >>>>>>>> quite a few minutes and nothing. >>>>>>>>
Re: [clojure-rabbitmq] RabbitMQ Langohr no heartbeat
I have tried (connection (assoc (:rabbit conf) :requested-heartbeat 3 :automatically-recover false :connection-timeout 5)) based on what you said but no joy, I would have thought I would at least see something in the logs to suggest it's trying to do something. I thought the connection was supposed to be closed if 2 heartbeats were missed? Thanks. On Thu, Apr 14, 2016 at 12:31 PM, Michael Klishin <mklis...@pivotal.io> wrote: > You can see effective heartbeat in the management UI on the connection > page. > > Heartbeats do not close connection and it't not correct that connection > should be considered dead in 1.5 seconds with a 3 second interval: it will > be 3 seconds. > > I'm curious if Langohr simply tries to re-connect because missed > heartbeats are treated the same way as connection loss in recent Java > client versions: is connection recovery enabled? > > On 14 abr 2016, at 14:20, David Smith <shmish...@gmail.com> wrote: > > Can anyone help me with this > http://stackoverflow.com/questions/36596446/rabbitmq-langohr-no-heartbeat > > I am setting up a connection to Rabbit using > > (rmq/connect (assoc (:rabbit conf) :requested-heartbeat 3)) > > I have 3 subscribers to 3 channels, no producers. When I shutdown the > rabbit server, nothing happens to my client. I would expect it to report > missing heartbeat after 1.5 seconds and close the connection after 3 > seconds. I have left the program running with rabbit down for quite a few > minutes and nothing. > > I'm using langohr 3.5.1 > > I have checked .getHeartbeat rabbit-conn and it is correctly set to 3. I > have also tried setting :connection-timeout 5 which I believe is 5ms. If > I set that to 1 then my app fails to start up (timeout too small to make > the initial connection), so I'm sure that setting is correct as well. > > -- > You received this message because you are subscribed to the Google Groups > "clojure-rabbitmq" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure-rabbitmq+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "clojure-rabbitmq" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure-rabbitmq/Z39EavO9Eas/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > clojure-rabbitmq+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "clojure-rabbitmq" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] kithara 0.1.0 - Reliable RabbitMQ Consumers for Clojure
This is great - we're planning to open source our tiny consumer lib - there might be no need after all :-) Looking at the source and the readme it's **very** similar to our solution. Łukasz -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] kithara 0.1.0 - Reliable RabbitMQ Consumers for Clojure
kithara aims to facilitate the creation of RabbitMQ consumers in Clojure. It is based on Lyra (https://github.com/jhalterman/lyra) to provide recovery and retry mechanisms. It _is not_ a universal RabbitMQ client. - GitHub: https://github.com/xsc/kithara - Generated Documentation: http://xsc.github.io/kithara/ I'm happy to answer any questions and concerns! Yannick -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] Nacks and Publisher Acknowledgements
Oops, sorry. Something made me believe it was a Github issue notification.
MK
> On 11/9/2015, at 6:25, j...@signafire.com wrote:
>
> I'm confused—I thought this was the mailing list…
> That said, if there's a more appropriate place to ask this question, I'm
> happy to move there.
>
>> On Thursday, September 10, 2015 at 11:20:27 PM UTC-4, Michael Klishin wrote:
>> Questions belong to the mailing list.
>>
>>> On 11/9/2015, at 6:17, jo...@signafire.com wrote:
>>>
>>> Essentially, it's not clear to me how an application is supposed to recover
>>> when handling a nack or when langohr.confirm/wait-for-confirms returns
>>> false. It seems to me that the delivery tag that the nack handler receives
>>> is only useful if I've been maintaining a map from delivery tags to
>>> messages (so that I know which message needs to be retried). Is that a
>>> responsibility expected of the application developer? I.e., should I be
>>> doing something like (swap! delivery-tag->message assoc
>>> (.getNextPublishSeqNo channel) message) before each invocation of
>>> langohr.basic/publish? (If so, I'd probably also (swap!
>>> delivery-tag->message dissoc delivery-tag) inside of the ack-handler.)
>>>
>>> And in the case of langohr.confirm/wait-for-confirms returning false: all I
>>> know in that circumstance is that some message failed to send since the
>>> last time I called wait-for-confirms. So in order to use wait-for-confirms,
>>> should I be maintaining a set of pending messages? Something along the
>>> lines of:
>>> (if (wait-for-confirms channel)
>>> (reset! sent-yet-unconfirmed-messages #{}) ; flush our memory of the
>>> recently-sent messages
>>> (try-resending-the-messages))
>>>
>>>
>>> I'd really appreciate any guidance you can provide.
>>> -Josh Tilles
>>>
>>> P.S. I'm new to AMQP, RabbitMQ, and Langohr, so if I'm going about this the
>>> wrong way, feel free to point it out.
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "clojure-rabbitmq" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to clojure-rabbit...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "clojure-rabbitmq" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure-rabbitmq+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"clojure-rabbitmq" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure-rabbitmq+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[clojure-rabbitmq] ANN Langohr 3.3.0 is released
Langohr [1] is a small, feature complete Clojure client for RabbitMQ. Release notes: http://blog.clojurewerkz.org/blog/2015/07/27/langohr-3-dot-3-0-is-released/ 1. http://clojurerabbitmq.info -- MK Staff Software Engineer, Pivotal/RabbitMQ -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[clojure-rabbitmq] autorecovery failure on queue status operation
I have a number of rabbitmq clients, most of which fail over well enough, but one client is experiencing apparent thread death on a queue status operation when the connection times out on heartbeat. I wondered if anybody had any clues here. Note the langohr.queue$status.invoke() Exception in thread async-dispatch-3 java.lang.Error: java.io.IOException at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1151) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.io.IOException at com.rabbitmq.client.impl.AMQChannel.wrap(AMQChannel.java:106) at com.rabbitmq.client.impl.AMQChannel.wrap(AMQChannel.java:102) at com.rabbitmq.client.impl.AMQChannel.exnWrappingRpc(AMQChannel.java:124) at com.rabbitmq.client.impl.ChannelN.queueDeclarePassive(ChannelN.java:873) at com.rabbitmq.client.impl.recovery.AutorecoveringChannel.queueDeclarePassive(AutorecoveringChannel.java:287) at langohr.queue$status.invoke(queue.clj:130) at de.data.messaging.scheduler$fill_jobs_BANG_.invoke(scheduler.clj:115) at de.data.messaging.scheduler$go_release_jobs_BANG_$fn__1064$state_machine__11049__auto1065$fn__1067.invoke(scheduler.clj:129) at de.data.messaging.scheduler$go_release_jobs_BANG_$fn__1064$state_machine__11049__auto1065.invoke(scheduler.clj:129) at clojure.core.async.impl.ioc_macros$run_state_machine.invoke(ioc_macros.clj:940) at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invoke(ioc_macros.clj:944) at clojure.core.async.impl.ioc_macros$take_BANG_$fn__11065.invoke(ioc_macros.clj:953) at clojure.core.async.impl.channels.ManyToManyChannel$fn__7516.invoke(channels.clj:102) at clojure.lang.AFn.run(AFn.java:22) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ... 2 more Caused by: com.rabbitmq.client.ShutdownSignalException: connection error at com.rabbitmq.utility.ValueOrException.getValue(ValueOrException.java:67) at com.rabbitmq.utility.BlockingValueOrException.uninterruptibleGetValue(BlockingValueOrException.java:33) at com.rabbitmq.client.impl.AMQChannel$BlockingRpcContinuation.getReply(AMQChannel.java:348) at com.rabbitmq.client.impl.AMQChannel.privateRpc(AMQChannel.java:221) at com.rabbitmq.client.impl.AMQChannel.exnWrappingRpc(AMQChannel.java:118) ... 14 more Caused by: com.rabbitmq.client.MissedHeartbeatException: Heartbeat missing with heartbeat = 60 seconds at com.rabbitmq.client.impl.AMQConnection.handleSocketTimeout(AMQConnection.java:597) at com.rabbitmq.client.impl.AMQConnection.access$600(AMQConnection.java:65) at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:560) ... 1 more -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] The execution hangs when nested publish inside consumer handler function
I posted the code snippet that can cause the issue on github. Also posted
differences in network trace between blocking and success run that I've
noticed there.
The output from rabbitmqctl eval `rabbitmq_diagnostics:maybe_stuck().` is
Error: {undef,[{rabbitmq_diagnostics,maybe_stuck,[],[]},
{erl_eval,do_apply,6,[{file,erl_eval.erl},{line,657}]},
{rpc,'-handle_call_call/6-fun-0-',5,
[{file,rpc.erl},{line,205}]}]}
On Tuesday, July 21, 2015 at 5:47:44 PM UTC+7, Michael Klishin wrote:
On 21 Jul 2015 at 11:17:50, Nuttanart Pornprasitsakul (visib...@gmail.com
javascript:) wrote:
Follow up from the issue #74 I created on Github(
https://github.com/michaelklishin/langohr/issues/74).
Sorry that I posted there.
It doesn't eventually unblock, both in and out queue are in idle
state not flow state. I'll get back again with the log and thread
dump.
There’s nothing unusual in the thread stack traces. We need a Wireshark
protocol
capture.
rabbitmqctl eval `rabbitmq_diagnostics:maybe_stuck().` output may also
help.
--
MK
Staff Software Engineer, Pivotal/RabbitMQ
--
You received this message because you are subscribed to the Google Groups
clojure-rabbitmq group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure-rabbitmq+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] The execution hangs when nested publish inside consumer handler function
On 22 Jul 2015 at 10:46:18, Nuttanart Pornprasitsakul (visiblet...@gmail.com)
wrote:
I posted the code snippet that can cause the issue on github.
Also posted differences in network trace between blocking and
success run that I've noticed there.
Thanks, this is a fairly busy week for me with 3 releases but I will take a look
in the next few days.
The output from rabbitmqctl eval `rabbitmq_diagnostics:maybe_stuck().`
is
Error: {undef,[{rabbitmq_diagnostics,maybe_stuck,[],[]},
{erl_eval,do_apply,6,[{file,erl_eval.erl},{line,657}]},
{rpc,'-handle_call_call/6-fun-0-',5,
[{file,rpc.erl},{line,205}]}]}
This means your version doesn’t have that function (it’s fairly new, I think
3.5.x)
--
MK
Staff Software Engineer, Pivotal/RabbitMQ
--
You received this message because you are subscribed to the Google Groups
clojure-rabbitmq group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure-rabbitmq+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[clojure-rabbitmq] Re: Reusing channel in message handler function
On Wednesday, July 22, 2015 at 12:14:36 PM UTC+3, Nuttanart Pornprasitsakul wrote: Hi, This question is related to blocking issue that I'm asking https://github.com/michaelklishin/langohr/issues/74, but I think better separating this to prevent putting more noises in that issue. I started to think that the issue that happens to me causes by opening and closing channel to often in the subscribe handler function (the snippet below extracted from here https://github.com/michaelklishin/langohr/issues/74#issuecomment-123536849 ) (lc/subscribe channel source (fn [ch meta message] (let [pub-ch (lch/open conn)] (lb/publish pub-ch destination (str message)) (lch/close pub-ch)) (lb/ack ch (:delivery-tag meta The reason I keep doing it this way is because in the Java RabbitMQ client Channel documentation https://www.rabbitmq.com/releases/rabbitmq-java-client/current-javadoc/com/rabbitmq/client/Channel.html says that a channel shouldn't be shared between threads. As my understanding, message handler function can be executed in multiple threads that's why I create a new channel and close it within the handler function. But from my other test results, it seems like sharing channel between threads making handler function run a lot faster and importantly, blocking issue doesn't happen. You can reuse the channel in this particular case. Yes, consumer methods will be executed in a thread pool but per-channel ordering is guaranteed by the Java client (ConsumerWorkService, in case you wonder). I didn't realise you were closing and opening channels inside a delivery handler. That should not be necessary and sounds more dangerous than technically having channel sharing ;) Thread sharing is a no-go if you intend to publish on a channel concurrently. As I explained in above, Java client will effectively make publishing sequential in your case. If this solves the blocking issue for you, I'd simply recommend you publish responses on the same channel your deliveries are on (this is why the callback has `ch` as the first argument!) and move on :) MK -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[clojure-rabbitmq] ANN Langohr 3.1.0 is released
Langohr [1] is a small, feature complete Clojure client for RabbitMQ. Release notes: http://blog.clojurewerkz.org/blog/2015/02/27/langohr-3-dot-1-0-is-released/ 1. http://clojurerabbitmq.info -- @michaelklishin, github.com/michaelklishin -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] Re: Socket Exception thrown when trying to make a remote connection to server over adhoc network
Any idea what the possible causes of this problem are? sorry I know its not much information to work with.. On Wednesday, June 11, 2014 2:34:42 PM UTC-4, Samuel Nelson wrote: I tested via telnet: telnet 10.10.10.3 5672 and the rabbitMQ server reports in the log that it accepted the connection 10.10.10.5:46899 - 10.10.10.3:5672. Then the connection times out and an error log is written: Closing AMQP connection 10.10.10.5:46899 - 10.10.10.3:5672. However, when I run the Clojure/Langohr code, the log file accepts the connection, but does not attempt to close. Instead we have the SocketException on the client side, 10.10.10.5, which I listed in the first post. Thanks! On Wednesday, June 11, 2014 2:00:54 PM UTC-4, Michael Klishin wrote: On 11 June 2014 at 21:57:11, Samuel Nelson (snel...@ycp.edu) wrote: Caused by: SocketException Connection reset This message is very generic and does not explain much. Can you see connection entries in RabbitMQ log? Try connecting to RabbitMQ via telnet, for example (note that it will quickly close connection unless you enter a valid protocol header, AMQP091, and then due to connection negotiation timeout). -- MK Software Engineer, Pivotal/RabbitMQ This information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. -- This information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[clojure-rabbitmq] Socket Exception thrown when trying to make a remote connection to server over adhoc network
I am new to langohr and rabbitmq, and I want to try and use it for sending
data across a distributed network.
To test it out, I have two laptops, both connected over and adhoc network
and both running rabbitmq and their IP's are set to 10.10.10.3 and
10.10.10.5... I added a rabbitmq username and password client, client
on the 10.10.10.3 laptop
From the repl on the 10.10.10.5 laptop, I enter the following command:
(def conn (langohr.core/connect { :host 10.10.10.3
:username client
:password client}))
And after a few seconds, it gives me the following exception:
SocketException Connection reset java.net.SocketInputStream.read
(SocketInputStream.java:185)
I know that it isn't the network because the log file on the 10.10.10.3
laptop says something like :
accepting amqp connection: 0.209.0 (10.10.10.5:46647 - 10.10.10.3:5672)
Any idea what could be causing this exception?
also, will langohr and rabbitmq work on embedded ARM processors?
--
This information is intended solely for the use of the individual to whom it is
addressed.
Any review, disclosure, copying, distribution or use of this e-mail
communication by
others is strictly prohibited. If you are not the intended recipient, please
notify us
immediately by returning this message to the sender and delete all copies.
--
You received this message because you are subscribed to the Google Groups
clojure-rabbitmq group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure-rabbitmq+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] Re: Socket Exception thrown when trying to make a remote connection to server over adhoc network
On 11 June 2014 at 21:57:11, Samuel Nelson (snels...@ycp.edu) wrote: Caused by: SocketException Connection reset This message is very generic and does not explain much. Can you see connection entries in RabbitMQ log? Try connecting to RabbitMQ via telnet, for example (note that it will quickly close connection unless you enter a valid protocol header, AMQP091, and then due to connection negotiation timeout). -- MK Software Engineer, Pivotal/RabbitMQ -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] Re: Socket Exception thrown when trying to make a remote connection to server over adhoc network
I tested via telnet: telnet 10.10.10.3 5672 and the rabbitMQ server reports in the log that it accepted the connection 10.10.10.5:46899 - 10.10.10.3:5672. Then the connection times out and an error log is written: Closing AMQP connection 10.10.10.5:46899 - 10.10.10.3:5672. However, when I run the Clojure/Langohr code, the log file accepts the connection, but does not attempt to close. Instead we have the SocketException on the client side, 10.10.10.5, which I listed in the first post. Thanks! On Wednesday, June 11, 2014 2:00:54 PM UTC-4, Michael Klishin wrote: On 11 June 2014 at 21:57:11, Samuel Nelson (snel...@ycp.edu javascript:) wrote: Caused by: SocketException Connection reset This message is very generic and does not explain much. Can you see connection entries in RabbitMQ log? Try connecting to RabbitMQ via telnet, for example (note that it will quickly close connection unless you enter a valid protocol header, AMQP091, and then due to connection negotiation timeout). -- MK Software Engineer, Pivotal/RabbitMQ -- This information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] Re: Can TopologyRecoveryException be simulated?
On Jun 4, 2014, at 3:31 AM, Michael Klishin mklis...@gopivotal.com wrote: Feel free to contribute this feature: https://github.com/michaelklishin/langohr/issues/47 I'll have the new guy do it when he starts in August. Let us go then, TMI, When their profiles are spread out against the sky, Like a patient etherized upon a table. The Love Song of J. Random Profile -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] Re: Can TopologyRecoveryException be simulated?
On 4 June 2014 at 18:21:51, Brian Marick (br...@getset.com) wrote: I'll have the new guy do it when he starts in August. Hopefully it'll be done by then ;) -- MK Software Engineer, Pivotal/RabbitMQ -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] Can TopologyRecoveryException be simulated?
On Jun 3, 2014, at 2:16 PM, Michael Klishin mklis...@gopivotal.com wrote: You can delete a queue and declare it with different attributes from out of process. Then recovery will attempt to declare it with the original attributes and fail. Thanks. Small note for anyone doing this: delete the queue, redeclare it differently, then shutdown and restart the server. Let us go then, TMI, When their profiles are spread out against the sky, Like a patient etherized upon a table. The Love Song of J. Random Profile -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[clojure-rabbitmq] Re: Can TopologyRecoveryException be simulated?
On Jun 3, 2014, at 2:13 PM, Brian Marick br...@getset.com wrote: We had a situation this morning where automatic topology recovery failed with this exception. I'd like to do something to my local rabbitmq server that provokes this exeption, to see if my fix works. Is there a way? Am I correct to think that there's no straightforward way of hooking into the autorecovery mechanism to handle a TopologyRecoveryException? In our case, the Ruby apps were written to exit and restart upon any AMQP problem. When they started in the normal way, the topology problem didn't stop them and all was well. The Clojure apps tried the auto-recovery, got stuck with the topology exception, didn't exit, and so were hung up until manually restarted. (Fortunately, only two real users were affected.) So what I'd like is for the Clojure apps to System/exit upon that exception. But it's swallowed (and printed) by beginAutomaticRecovery in Connection.java. Is the only option to hand-roll non-automatic recovery? Let us go then, TMI, When their profiles are spread out against the sky, Like a patient etherized upon a table. The Love Song of J. Random Profile -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] SocketTimeoutExceptions terminates listening process
On 21 May 2014 at 16:58:38, Thomas Kristensen (thomas.kristen...@uswitch.com) wrote: you'll notice that the message gets rejected as we'd expect when the exception is NOT re-thrown, but the reject seems to be ignored in the case where we re-throw. You could argue that you should never have a handler throw exceptions to the langohr-lib, but seeing as this can happen, and since it handles exceptions just fine when :auto-ack is true (not demonstrated in the experiment, but tested and verified), it seems that a consistent behaviour on a reject should be to continue consuming. Is there something I'm missing? What do you mean by ignored? Is the channel still open? Do you see basic.reject on the wire? (e.g. using Tracer: http://www.rabbitmq.com/java-tools.html) Throwing exceptions in delivery handlers is fine, it should not exhaust consumer thread pool or anything like that. -- MK Software Engineer, Pivotal/RabbitMQ -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] SocketTimeoutExceptions terminates listening process
On 21 May 2014 at 19:15:50, Thomas Kristensen (thomas.kristen...@uswitch.com) wrote: You are right, the channel has been closed by me throwing on the exception. I attached a debugger and traced it to line 106 of DefaultExceptionHandler which closes the channel in handleChannelKiller. All of this does makes sense as a default behaviour, but it doesn't seem to be documented in langohr, so it took quite a while to figure out. Feel free to contribute doc improvements. - ack-unless-exception is confusing at best - it should not throw the exception on but handle it to be valuable. Otherwise users of langohr should just call .basicAck and .basicReject themselves. I'd vote for just removing it from langohr. - The behaviour of langohr in the case where a handler throws an exception is not documented in the doc-string of langohr.consumers/subscribe Screw doc strings. They cannot describe much because they can't be too long. http://clojurerabbitmq.info should cover this, in both Working with Queues and Error Handling and Recovery (the Queues guide can link to the Error Handling one, for example ). -- MK Software Engineer, Pivotal/RabbitMQ -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
ANN RabbitMQ tutorials ported to Clojure
I'm happy to announce that 5 out of 6 RabbitMQ tutorials [1] are now available for Clojure: https://github.com/rabbitmq/rabbitmq-tutorials/tree/master/clojure and are tested for interoperability with 9 other clients. The final tutorial will be ported at a later point. 1. http://www.rabbitmq.com/getstarted.html -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN RabbitMQ tutorials ported to Clojure
This is awesome, thanks for your efforts! Wish this was around a few months ago, but I imagine people will be well served by it in the future :) On Monday, August 12, 2013 2:15:20 AM UTC-4, Michael Klishin wrote: I'm happy to announce that 5 out of 6 RabbitMQ tutorials [1] are now available for Clojure: https://github.com/rabbitmq/rabbitmq-tutorials/tree/master/clojure and are tested for interoperability with 9 other clients. The final tutorial will be ported at a later point. 1. http://www.rabbitmq.com/getstarted.html -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: RabbitMQ
On Thu, Mar 24, 2011 at 8:45 PM, Max Weber weber.maximil...@googlemail.com wrote: What is the best Clojure library to work with RabbitMQ? Give bunny a try. Might not be the best rabbitmq-client library :) https://github.com/icylisper/bunny example: (use 'bunny.publisher) (with-mq conn (publish This is a message)) where conn is a connection map. -- isaac http://icylisper.in -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
RabbitMQ
What is the best Clojure library to work with RabbitMQ? Best regards Max -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: RabbitMQ
I just wrapped their java client library: http://www.rabbitmq.com/java-client.html http://www.rabbitmq.com/java-client.html On Thu, Mar 24, 2011 at 11:15 AM, Max Weber weber.maximil...@googlemail.com wrote: What is the best Clojure library to work with RabbitMQ? Best regards Max -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: RabbitMQ
According to http://www.clojure-toolbox.com/ https://github.com/mefesto/wabbitmq But I'm pretty new to clojure and don't know if it is good. On Thu, Mar 24, 2011 at 10:30 AM, Mark Rathwell mark.rathw...@gmail.com wrote: I just wrapped their java client library: http://www.rabbitmq.com/java-client.html On Thu, Mar 24, 2011 at 11:15 AM, Max Weber weber.maximil...@googlemail.com wrote: What is the best Clojure library to work with RabbitMQ? Best regards Max -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: RabbitMQ
We did the same On Thu, Mar 24, 2011 at 10:30 AM, Mark Rathwell mark.rathw...@gmail.com wrote: I just wrapped their java client library: http://www.rabbitmq.com/java-client.html On Thu, Mar 24, 2011 at 11:15 AM, Max Weber weber.maximil...@googlemail.com wrote: What is the best Clojure library to work with RabbitMQ? Best regards Max -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
