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


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

Re: JMS scalability question

From saxo123@gmx.de
Newsgroups comp.lang.java.programmer
Subject Re: JMS scalability question
Date 2011-11-16 22:59 -0800
Organization http://groups.google.com
Message-ID <780efba5-4448-48ee-87f6-530cd16c55fd@m10g2000vbc.googlegroups.com> (permalink)
References (1 earlier) <cch7c7lgr584uda3pemeeg5jlfhkdi8jnp@4ax.com> <5f805cc6-58b1-49e5-933f-4c6dbbceb65d@g7g2000vbd.googlegroups.com> <5890740.1493.1321468227592.JavaMail.geo-discussion-forums@prap37> <d422cdf4-1902-4d6d-86f0-03b89e4f2e7b@y42g2000yqh.googlegroups.com> <27800224.227.1321492704158.JavaMail.geo-discussion-forums@prdy11>

Show all headers | View raw


Hi Lew,

> This is why I asked about your use case.  Not all use cases call for queues, otherwise every single program would always use them.  No?

it's about developing a little actor framework (see
http://en.wikipedia.org/wiki/Actor_model) with distributed actors
connected through some means to exchange messages through the wire.
Actors are active objects, e.g. objects that run in their own thread
(to prevent deadlock and other locking issues). The usual approach to
implement this is something like this:

public class MyActor implements Runnable {

	BlockingQueue<Message> queue = new LinkedBlockingQueue<Message>();

	public static void main(String[] args)	{
		new Thread(new MyActor()).start();
	}

	public void run() {
		while(true) {
			Message message = queue.take();
			if(message.getSelector().equals("doWork")) {
				doWork();
				return;
			}
		}
	}

	public void doWork() {
		System.out.println("doing my work");
	}

}

So messages are exchanged between actors through queues when an actor
wants to notify another actor about something. With distributed actors
those messages would have to be exchanged through the wire. Since
these messages are similar to command objects that are added to queues
my first approach to move this into a distributed setting was to use
distributed queues like JMS queues. Each actor type serves a different
purpose with all the actors working in a collaborative fashion.

> You aren't specific, given that you've only mentioned the solutions you've examined and not the purpose they should serve, but the shape of your search (assuming your analysis of what you need is correct) does indicate that your use case might be appropriate for queues.

Yes, maybe it has become clearer now :-)

Cheers, Oliver

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