Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #10018
| From | Fredrik Jonson <fredrik@jonson.org> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: JMS scalability question |
| Date | 2011-11-17 21:01 +0000 |
| Message-ID | <slrnjcatit.u4r.fredrik@scout.jonson.org> (permalink) |
| References | <bb8b61d2-fe1f-42b8-93d8-2d1a329e6afb@a16g2000yqk.googlegroups.com> <slrnjc9gda.tm7.fredrik@scout.jonson.org> <39166d35-4fc6-40ed-898a-d747b5f761c0@m7g2000vbc.googlegroups.com> |
saxo123@gmx.de wrote: > my first post was not that specific in order to keep the problem > description short. If you have a look at my reply with the MyActor > class, there is much more information provided. That message wasn't available at my server when I responded this morning. One might almost think that the usenet deities also wanted to get a word in in this thread about asynchronous messaging. ;) > For non-distributed communication between actors that all reside > inside the same vm I won't go with JMS, but with plain JDK1.5 > BlockingQueues. What I want to develop is some kind of runtime > environment for actors to live in. The Actor pattern implies that a message should be consumed with a once and only once delivery guarantee. Sounds like a great point-to-point candidate to me. You know IIRC the freely availabe version of Akka doesn't support message persistence[0]. So if you use queues for all messages, even in-vm, you'll actually have a feature in your Actor system that even Akka doesn't match. Throughput (TPS) will obviously be much worse when compared to a java BlockingQueue but if your machine or jvm should crash, the messages that hasn't been acted on yet will still be there after a restart. [0] I can't find a reference right now, I might be completely wrong here. Anyone else know more about message persistence in Akka? > [...] Another approach is to make actors interruptible. Without having the actors also transacted by default you can't interrupt them reliably. Was the current message content acted on, not acted on, or partially acted on? Now, if you use jms you can simply close the session, and the consumer thread will rollback a transacted dispatch, or wait for completion of non-transacted dispatch. I hope you get your project of the ground, sounds like fun hacking on a interesting problem. -- Fredrik Jonson
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
JMS scalability question saxo123@gmx.de - 2011-11-15 02:07 -0800
Re: JMS scalability question Roedy Green <see_website@mindprod.com.invalid> - 2011-11-16 06:21 -0800
Re: JMS scalability question saxo123@gmx.de - 2011-11-16 09:35 -0800
Re: JMS scalability question Lew <lewbloch@gmail.com> - 2011-11-16 10:30 -0800
Re: JMS scalability question saxo123@gmx.de - 2011-11-16 14:25 -0800
Re: JMS scalability question Lew <lewbloch@gmail.com> - 2011-11-16 17:18 -0800
Re: JMS scalability question saxo123@gmx.de - 2011-11-16 22:59 -0800
Re: JMS scalability question jlp <jlp@jlp.com> - 2011-11-17 08:41 +0100
Re: JMS scalability question saxo123@gmx.de - 2011-11-17 01:00 -0800
Re: JMS scalability question Roedy Green <see_website@mindprod.com.invalid> - 2011-11-16 16:16 -0800
Re: JMS scalability question Fredrik Jonson <fredrik@jonson.org> - 2011-11-17 08:11 +0000
Re: JMS scalability question saxo123@gmx.de - 2011-11-17 01:26 -0800
Re: JMS scalability question Fredrik Jonson <fredrik@jonson.org> - 2011-11-17 21:01 +0000
Re: JMS scalability question Saxo <saxo123@gmx.de> - 2011-11-17 23:27 -0800
csiph-web