The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 |
From: Sergio Bossa <sergio.bo...@gmail.com>
Date: Wed, 11 Nov 2009 16:10:08 +0100
Local: Wed, Nov 11 2009 10:10 am
Subject: Re: Threading Policies
On Wed, Nov 11, 2009 at 3:53 PM, Stefan Weber <stefan.we...@gmail.com> wrote:
Great to know about your use case, thanks for sharing :)
> I'm working on an application that is supposed to serve as an adapter > to a 3rd party product. The communication to the latter happens with > ASCII messages over TCP/IP and I found that dispatching the incoming > messages to their handlers seems like a good case to try Actorom. It > actually works very good, I hardly had to restructure the application > and could get rid of a lot of code. So thanks for that :) > However, since the OSMessageDispatcher ensures that messages handled
I didn't implement "concurrent" actors because of two main reasons:
> by the same actor run sequentially I have some worries when the > handler takes longer (I need to parse potentially big ASCII message, > for example) than the inter arrival time of its messages. > If I understand the actors model correctly, this is to ensure that the > actor does not need to worry about synchronization. However, if the > handler is state less, it seems like it should be no problem for this > actor to accept messages concurrently. > What is your thought on this? Do you discourage this upfront or do you
1) They break the principles of the actors model itself. 2) They could be misused, leading people to use actors in wrong ways. That said, I'm not saying to be completely *against* such a use case:
> I was thinking to implement a MessageDispatcher myself that does the
Another way to offload actors for stateless tasks could be to use an
> same thing as the OSMessageDispatcher but allowing concurrent handling > on the same actor if it has the @ThreadSafe annotation. external thread pool and schedule those tasks on it: by doing so, actors would be used only to represent the messaging abstraction, while the actual computation would be executed on another thread (launched by the actor who received the related message). What do you think? Just let me know if you need more details about this solution. Cheers,
Sergio B.
-- You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||