Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #10018

Re: JMS scalability question

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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