Stamp and other MQ systems (was Re: NAtiveBoost error)
Le 10/11/2014 20:00, Sven Van Caekenberghe a écrit :>
On 10 Nov 2014, at 19:07, Alain Rastoul <alf.mmm.cat@gmail.com> wrote: I have loaded your stamp package (very nice), and ran it against rabbitmq . If I do some benchmarking code against the rabbit, should I put the code in Stamp package and commit to stamp package ? or should I publish my own package ? What is the best practice with SmalltalkHub and what do you prefer ? No problem to publish a new package or to add it to Stamp, whatever you advise me, I'm not familiar with Pharo community practices and need some guidance here.
It (Stamp) is open source. Feedback and contributions are most welcome. There is already some benchmarking in there if I remember correctly. You can continue discussing it in this mailing list (but maybe under a different thread).
Yes, there is some benchmarking on time to send or receive. I wanted to first add a sample 'helloworld' producer/consumer and measure messages send/receive by second with one and several pharo VMs, and also may be find some benchs done by other MQ supplier. And, as I should have a much more powerfull computer than my laptop in few weeks (nothing to do with christmas, I am my own santa claus, supplier delays), I could make some tests with several linux+pharo VMs. I will add a Stamp-Benchmarks subpackage and put samples and code in it. This does not make sense under a client package perspective, but has under a server one. Alain
On 10 Nov 2014, at 20:28, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:
Le 10/11/2014 20:00, Sven Van Caekenberghe a écrit :>
On 10 Nov 2014, at 19:07, Alain Rastoul <alf.mmm.cat@gmail.com> wrote: I have loaded your stamp package (very nice), and ran it against rabbitmq . If I do some benchmarking code against the rabbit, should I put the code in Stamp package and commit to stamp package ? or should I publish my own package ? What is the best practice with SmalltalkHub and what do you prefer ? No problem to publish a new package or to add it to Stamp, whatever you advise me, I'm not familiar with Pharo community practices and need some guidance here.
It (Stamp) is open source. Feedback and contributions are most welcome. There is already some benchmarking in there if I remember correctly. You can continue discussing it in this mailing list (but maybe under a different thread).
Yes, there is some benchmarking on time to send or receive. I wanted to first add a sample 'helloworld' producer/consumer and measure messages send/receive by second with one and several pharo VMs, and also may be find some benchs done by other MQ supplier. And, as I should have a much more powerfull computer than my laptop in few weeks (nothing to do with christmas, I am my own santa claus, supplier delays), I could make some tests with several linux+pharo VMs. I will add a Stamp-Benchmarks subpackage and put samples and code in it.
OK.
This does not make sense under a client package perspective, but has under a server one.
Just for the record (I am being pedantic here, sorry): STAMP is a STOMP client, a way to connect to a message queue; but in messaging speak the parties are called producers and consumers, not client and servers (although this qualification can be useful architecturally); to run any code you always need both or not much will happen. Sven
Le 10/11/2014 20:52, Sven Van Caekenberghe a écrit :
Just for the record (I am being pedantic here, sorry): STAMP is a STOMP client, a way to connect to a message queue; but in messaging speak the parties are called producers and consumers, not client and servers (although this qualification can be useful architecturally); to run any code you always need both or not much will happen.
Sven
okok, didn't you forgot brokers ? I know but thank you anyway I should have untitled it 'Stamp, RabbitMQ and other MQ systems' not 'Stamp and other MQ systems', but the Rabbit went away, sorry :) just that I'm thinking of writing a small STOMP server may be within the Stamp package. Because to me stamp was a package name not a stomp client, if your feeling is that it is a client may be this package should not have a server or server benchs in it? I can put it outside, I don't mind, and the benchs too with the server (also that I do not want to break or dirty your work Sven) as I previously said, it has no sense from a client perspective. the benchs are done in that perspective : a way to compare performance of different servers, not to bench the stamp client performance (which is important too , but to do that I would have written the bench in java and C too, to bench Stamp client against java and C client. what I don't think I will). mmm... I did well to ask Alain
On 10 Nov 2014, at 21:36, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:
Le 10/11/2014 20:52, Sven Van Caekenberghe a écrit :
Just for the record (I am being pedantic here, sorry): STAMP is a STOMP client, a way to connect to a message queue; but in messaging speak the parties are called producers and consumers, not client and servers (although this qualification can be useful architecturally); to run any code you always need both or not much will happen.
Sven
okok, didn't you forgot brokers ? I know but thank you anyway I should have untitled it 'Stamp, RabbitMQ and other MQ systems' not 'Stamp and other MQ systems', but the Rabbit went away, sorry :)
just that I'm thinking of writing a small STOMP server may be within the Stamp package. Because to me stamp was a package name not a stomp client, if your feeling is that it is a client may be this package should not have a server or server benchs in it?
I can put it outside, I don't mind, and the benchs too with the server (also that I do not want to break or dirty your work Sven) as I previously said, it has no sense from a client perspective. the benchs are done in that perspective : a way to compare performance of different servers, not to bench the stamp client performance (which is important too , but to do that I would have written the bench in java and C too, to bench Stamp client against java and C client. what I don't think I will).
mmm... I did well to ask
No, you misunderstood me. My point was that in messaging parlance a client is any party talking to the messaging broker or server. If you would be doing a server implementation, that would mean you are rewriting RabbitMQ, not impossible but quite a challenge ;-) Any self-contained (apart from the MQ itself) demo will always contain a producer and a consumer, or not much will happen, right ? Often you organise functionality in a client and server part. For example: testSimpleRpc | client server request response | "The server is a client listening on commands coming in on a queue named factorial" server := self client. [ server open. server subscribeTo: 'factorial'. server runWith: [ :message | | number | message body = 'quit' ifTrue: [ ConnectionClosed signal ]. number := message body asInteger. server sendText: number factorial asString to: message replyTo ] ] fork. client := self client. client open. 10 to: 20 do: [ :each | request := client newSendFrameTo: 'factorial'. request text: each asString. request replyTo: '/temp-queue/factorial'. client write: request. "Wait up to standard timeout for a reply" response := client readMessage. self assert: response body equals: each factorial asString ]. client sendText: 'quit' to: 'factorial'. client close Notice how both the 'client' and 'server', architecturally speaking, are actually STOMP 'clients', in the protocol sense of the word. So a benchmark or tutorial will fit in a separate category. Sven BTW, I am happy that you got up and running on your own. Your previous experience probably helped. Keep the feedback coming.
Le 10/11/2014 23:32, Sven Van Caekenberghe a écrit :
My point was that in messaging parlance a client is any party talking to the messaging broker or server. If you would be doing a server implementation, that would mean you are rewriting RabbitMQ, not impossible but quite a challenge ;-)
RabbitMQ is certainly complex, but mostly because it deals with several protocols (which is a tedious part) and has tons of features, but do you know how much lines of code it has ? The server has less than *32k* lines of code! and including lot of comments and imports (in the "old" 2.4 version I have looked at by curiosity), ridiculously small in comparison to other java brokers, mainly because erlang is a very expressive language (due to its functional way of life) and kind features (native messages and processes). Pharo has an advantage here too. A STOMP server seems to be a good starting point: a small protocol, a small server. You did a good part (if not all) of the tricky stuff (frame encoding/decoding, negociation etc), I think it should not be difficult to add a tcp server and some in-memory queuing here (SharedQueues probably). As Stef said once, start small. At least I will try :) The goal is not to break the latest RabbitMQ benchamrks done by pivotal and google, IMHO lost in advance :). But how does pharo goes into some real world enterprise class application ? I am extremely curious about this kind of performance comparison. Aren't you interested ?
Any self-contained (apart from the MQ itself) demo will always contain a producer and a consumer, or not much will happen, right ? Often you organise functionality in a client and server part.
Yes, I saw your examples and they where very useful. I started an 'hello world' messages producer and a consumer for thoses 'hello world ' messages. Both clients of the RabbitMQ broker (server) (is it better here ? ;) )
BTW, I am happy that you got up and running on your own. Your previous experience probably helped. Keep the feedback coming.
about my experience, yes, it helped, not like the rabbit setup on windows which is a mess. I work in computer area from now nearly 30 years, starting with assembly in 82, then lot of C, C++, java, c# and other languages, on various systems (unix like most of the time then windows) always with databases, servers and clients, some MQ and http servers and EAI developments I think I know what a client is and what a server is ... or I should stop programming and do something else :)
participants (2)
-
Alain Rastoul -
Sven Van Caekenberghe