How would you name the actor threads? I find that information useful in
designing the API.
For example in Jumi Test Runner I would have one central thread called
"Coordinator". Also there would be some dynamically created components
each in their own thread, in which case the name would have a sequence
number: "Runner-1", "Runner-2" etc.
I might also find it useful to differentiate between multiple actor
containers inside the same JVM. Then the first container would have
thread names "jumi-suite-1-coordinator", "jumi-suite-1-runner-1",
"jumi-suite-1-runner-2" etc. and the second container would have names
"jumi-suite-2-coordinator", "jumi-suite-2-runner-1" and so on.
One idea for an API would be
`startActorThread("jumi-suite-{pool}-runner-{thread}")` which where the
{pool} and {thread} placeholders will be replaced with the automatically
generated sequence numbers. A fixed name can be produced by just not
having those placeholders in the parameter. Also, the {thread} sequence
number would be unique to each name pattern; the same container can
produce thread names "foo-1", "foo-2" etc. and "bar-1", "bar-2" etc.
independently of each other.
I should have time to work on Jumi this summer. In the meanwhile you can
use a workaround such as this to set the thread names:
import java.util.concurrent.ThreadFactory;
public class CustomNameThreadFactory implements ThreadFactory {
private final ThreadLocal<String> nextThreadName = new ThreadLocal<>();
@Override
public Thread newThread(Runnable r) {
String name = nextThreadName.get();
nextThreadName.remove(); // prevent accidentally creating two
threads with the same name
return new Thread(r, name);
}
public void setNextThreadName(String name) {
this.nextThreadName.set(name);
}
}
Which can be used like this:
CustomNameThreadFactory threadFactory = new CustomNameThreadFactory();
ExecutorService executor = Executors.newCachedThreadPool(threadFactory);
MultiThreadedActors actors = new MultiThreadedActors(executor, ...);
threadFactory.setNextThreadName("foo");
ActorThread fooThread = actors.startActorThread();
threadFactory.setNextThreadName("bar");
ActorThread barThread = actors.startActorThread();
deakblue wrote on 21.4.2013 4:48:
> Specifically, I'm interested in naming my actor threads because my
> threads are long-lived and I'm using Logback and I like the pretty
> thread names in the log :) But since you asked, I'll elaborate on some
> of the ways I'm using Jumi Actors:
>
> The way I tend to use Jumi now is to create a protective coating around
> my POJOs so that any mutable state is protected from concurrent
> read/writes OR as a way of queuing requests in a non-blocking way. It's
> an Android application with a lot of random asynchronous communication
> and I don't like blocking. That said, I don't think I'm using Jumi
> quite the way it was envisioned. I actually tuck the actor interface
> within my POJOs, this way it's transparent to client access.
>
> Below is the base class for a non-blocking command receiver. If I were
> to hook this to a firehose of inbound requests, I am assured that the
> requests will queue within a particular Command (or group of related
> commands if I shared the ActorThread) and complete in order. The client
> code, the command dispatcher (not shown), is unaware that it's an actor,
> it just gets a very fast response. On the other hand, if I wanted to
> actually complete a method call with blocking code because I was
> interested in a computed result, I could skip the Actor and provide a
> Synchronous Command. Again, the client code is unaware.
>
> package com.xxxx.consistencyservice.commands;
>
> import com.xxxx.consistencyservice.ServiceThread;
>
> import fi.jumi.actors.ActorRef;
> import fi.jumi.actors.ActorThread;
>
> public abstract class AbstractAsynchCommand implements Command,
> SynchCommand{
>
> protected String synchResponse = "** accepted " +
> this.getClass().getSimpleName();
> protected String commandId;
> protected ActorRef<SynchCommand> actorCommandHandle;
> protected static final String TAG = ServiceThread.class.getSimpleName();
> public AbstractAsynchCommand(ActorThread thread){
> String name = this.getClass().getSimpleName();
> this.commandId = name.substring(0,name.length()-"AsynchCommand".length());
> this.actorCommandHandle = thread.bindActor(SynchCommand.class, this);
> }
> public String command(String command) {
> this.actorCommandHandle.tell().synchCommand(command);
> return this.synchResponse;
> }
>
> public String commandId() {
> return this.commandId;
> }
>
> public abstract void synchCommand(String payload);
> }
>
>
> interface SynchCommand{
> void synchCommand(String payload);
> }
>
>
> Likewise, I have another class (not included) that contains complex
> mutable state, multiple synchronized internal fields. I provide
> mutators that basically "decorate" my .tell() calls as I did above.
> This way I can safely manipulate the multiple internal fields across
> multiple mutator methods. Likewise I can provide accessors using
> callbacks. Finally, I've also used Jumi Actors to create some very nice
> Observable pattern code that can monitor for changes and then pass them
> to the observers without blocking the monitor.
>
> Going beyond this, I'm interested in Jumi Actors as the basis for a
> DataFlow Framework, but I'm way too busy right now to explore this further.
>
> Best regards,
> -db-
--
Esko Luontola
www.orfjackal.net