[rabbitmq-discuss] State-of-the-art Perl client?

[Toby Corkindale]

On 31/01/12 21:25, Alessandro Ranellucci wrote:
> On 25-01-2012 at 6:30, Toby Corkindale wrote:
>
>  >>I've done some searching and haven't found a consensus answer: What's
>  >>the state-of-the-art Perl client for RabbitMQ?
>  >
>  >The only decent one I've found is Net::STOMP::Client.
>  >The author is active on this list and responds to bug reports.
>  >I filed bugs against the others on CPAN ages ago and have been ignored
>  >by their authors.
>
> I published this module one year ago and I'm still using it:
>
> https://metacpan.org/module/Net::RabbitMQ::Java
>
> It exposes the *full* RabbitMQ API as available through the official
> Java client. While some may dislike to run a Java library in a Perl
> environment, it has proven to be fairly reliable without a single issue.

I'm sure you can understand that it's not really desirable for many 
people to do this, though, due to:
  * Massively higher memory usage.
  * Longer start-up times.
  * Sysadmins' unfamiliarity with JVM deployment, tuning, failure modes, 
etc.
  * JVM incompatibility with OpenVZ containers.
  * The general nervousness you get when playing around with somewhat 
esoteric magic inter-language bindings like Inline::Java.


To be fair, you can tune the JVM memory use with some environment 
variables - but by default with Net::RabbitMQ::Java, the jvm portion 
grabs 1906M (virtual), which you have to admit is rather excessive. (You 
can enable memory over-commit on your Linux system, but by default it's 
still only going to let you run a couple of those jvms up before it 
starts complaining)


I admit, it's a interesting endeavour that you have here. I didn't 
realise you were actually using it seriously in the field though.

By the way - why do you require the user to call ->init manually? Why 
not put that into the import() subroutine which is called automatically?

Cheers,
Toby