Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Fredrik Jonson Newsgroups: comp.lang.java.programmer Subject: Re: JMS scalability question Date: 17 Nov 2011 21:01:50 GMT Lines: 42 Message-ID: References: <39166d35-4fc6-40ed-898a-d747b5f761c0@m7g2000vbc.googlegroups.com> X-Trace: individual.net fZOUC7Yv+B1JtDFnJn4DpQj5OZda6xIKBJ/s9A3SojMY/0T0Q= Cancel-Lock: sha1:ruxSfBBADmM0pOqgFZQJDqH29XE= User-Agent: slrn/pre1.0.0-18 (Linux) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10018 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