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

Re: JMS scalability question

Date	2011-11-17 08:41 +0100
From	jlp <jlp@jlp.com>
Newsgroups	comp.lang.java.programmer
Subject	Re: JMS scalability question
References	(2 earlier) <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> <780efba5-4448-48ee-87f6-530cd16c55fd@m10g2000vbc.googlegroups.com>
Message-ID	<4ec4baa1$0$2512$ba4acef3@reader.news.orange.fr> (permalink)
Organization	les newsgroups par Orange

Show all headers | View raw

[OT] There is an implementation of Actor Pattern ( Scala and Java ) => 
http://akka.io/docs/akka/1.3-RC1/Akka.pdf

Le 17/11/2011 07:59, saxo123@gmx.de a écrit :
> 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

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