On Tue, 25 Oct 2011 17:39:59 +0200, Uberto Barbini <[email protected]>
wrote:
Hi Fabrizio
For a moment I wasn't understanding why you were writing in english :-)
Just for the record, my code is such as:
final String path =
"/media/Media/Photography/Photos/Incoming/2011/September";
final UnitOfWork unitOfWork =
FileScanRequestMessage.forPath(path).send();
unitOfWork.waitForCompletion(); // yeah, not very
actor-oriented,
but the world is made of mixed stuff
I'm a bit lost here. Is unitOfWork sending a broadcast message to other
actors?
which kind of magic is behind
@Message, @Actor and @MessageListener? :)
I like your code, but I'd like to see a more complete example of how
using 2-3 actors together for doing async tasks.
I didn't go through more details since my code is still an experiment and
I'd first like to see some other library before deciding of going on. At
the current stage, I didn't decide yet for things such as
stateful/stateless and probably those @Actors aren't truly actors. Perhaps
I don't need actors and I should rather use a different terminology.
In any case:
+ there's a very simple pubsub EventBus behind the scenes which broadcasts
messages, and the topic is the message class
+ @MessageListener is used by reflection to register the method as
listener for the topic given by its unique parameter
+ @Message is just used for a formal check (@MessageListener methods must
have a single @Message parameter)
+ @Actor is currently not used in the small test, but in a real thing it
would be used for classpath discovery and actor instantiation
+ each actor instance is backed by an EventBus listener that receives the
message and posts it to a simple worker executor which dispatches to a
pool of threads
That's all. I don't need to dynamically instantiate and shutdown actors,
don't need fault tolerance, don't need remote actors, don't need software
transactional memory. That's why Akka or a similar thing is too heavy for
my needs. It sounds as the community is great for providing high quality,
complex libraries and framework for complex problems, but there are not
simple things for solving simple problems. Fortunately, there are a lot of
simple problems around, but the lack of simple solutions is the main
reason for the excessive growth of classpath.
For the record, my code is at
https://bitbucket.org/tidalwave/bluemarine-integritychecker-src/ but it's
still very rough (it's an incomplete NetBeans Platform project and to run
a small test you need to manually launch a Main from inside the NetBeans
IDE).
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
[email protected]
http://tidalwave.it - http://fabriziogiudici.it
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
