Are actors in Akka interruptible?

[Oliver Plow]

Hello,

just wondered whether it is possible in Akka to interrupt some actor
that is busy processing a long running task in order to make the actor
respond to some event it has to react to immediately (e.g., traffic
light turned red and the driver actor needs to stop the car). Well I
guess I can send some interrupt message, but I don't know whether that
would screw up the actor. Maybe there is a high-level way of doing
this. Some suspend-resume mechanism is what I'm looking for: interrupt
the actor, the actor ckecks out whether it needs to respond to some
newly arrived event, when done it resumes the interrupted task or
continues with doing something else.

Thanx, Oliver

[rkuhn]

Hi Oliver,

a method executing on the JVM cannot be “interrupted” or “suspended” unless it provides that functionality itself (i.e. checking some flag which can be set from a different thread). This translates directly to actors, except there is no place to put that flag. So, to keep an actor responsive it must look into its mailbox periodically, which means scheduling continuation tasks and keeping the processing of each message short.

Regards,

Roland

[√iktor Ҡlang]

Hi Oliver,

On Thu, Feb 2, 2012 at 10:02 AM, Oliver Plow <sax...@gmx.de> wrote:

Hello,

just wondered whether it is possible in Akka to interrupt some actor
that is busy processing a long running task in order to make the actor
respond to some event it has to react to immediately (e.g., traffic
light turned red and the driver actor needs to stop the car).

Actors shouldn't run long running tasks. Chunk the work into multiple messages.

 

Well I
guess I can send some interrupt message, but I don't know whether that
would screw up the actor. Maybe there is a high-level way of doing
this. Some suspend-resume mechanism is what I'm looking for: interrupt
the actor, the actor ckecks out whether it needs to respond to some
newly arrived event, when done it resumes the interrupted task or
continues with doing something else.

You're suggesting a solution to a problem that is not explained,

tell us what you're doing and we can suggest possible solutions.

Thanks!

Cheers,

√

 

Thanx, Oliver

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Jonas Bonér]

...and configure to use a priority queue mailbox to allow certain messages to jump the queue.

--
Jonas Bonér
CTO

Typesafe - The software stack for applications that scale

Phone: +46 733 777 123
Twitter: @jboner

--

You received this message because you are subscribed to the Google Groups "Akka User List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/HthJnJBSDcUJ.

[Oliver Plow]

> You're suggesting a solution to a problem that is not explained,
> tell us what you're doing and we can suggest possible solutions.

Well, it was just some general thought that struck my mind. The
example of the driver actor that needs to stop the car, because some
traffic light turned red was meant to be somewhat serious, though ;-).
Let's say your nuclear power plant control system also makes use of
actors and therefore actors need to be able to be interrupted to shut
down the plant in case of an earth quake or whatever.

Any application that needs to respond quickly to input of sensors
needs some way to ensure sufficient quick response time. There is,
e.g., interleaving in JADE (http://jade.tilab.com/). They had a very
nice slide about it on their site, but I can't find it anymore. The
processing of some message received by some agent is broken down into
nodes in a tree. Whenever a node in the tree has been executed, the
agent is available to poll any other input. It then resumes execution
by processing the next node in the tree. I don't really like this
approach as it appears quite effortful and cumbersome to me to create
that tree of nodes. But responsiveness is an issue people in the world
of agents have thought about. I was basically looking into actors,
because agents are somewhat dead (I guess ai never fulfilled its
promises and so agents couldn't do so, either). But actors are in
spirit very similar (active objects processing message queues) and
could serve as a replacement.

> ...and configure to use a priority queue mailbox to allow certain messages
> to jump the queue.

All right. If that kind of things can be configured, it can be done
anyway I guess.

Thanks, Oliver

[√iktor Ҡlang]

On Thu, Feb 2, 2012 at 1:15 PM, Oliver Plow <sax...@gmx.de> wrote:

> You're suggesting a solution to a problem that is not explained,
> tell us what you're doing and we can suggest possible solutions.

Well, it was just some general thought that struck my mind. The
example of the driver actor that needs to stop the car, because some
traffic light turned red was meant to be somewhat serious, though ;-).
Let's say your nuclear power plant control system also makes use of
actors and therefore actors need to be able to be interrupted to shut
down the plant in case of an earth quake or whatever.

The Driver actor is reating to events that are sent to his sensory systems and are reacted upon. So when he gets the redlight message, he'll break his car. If the driver actor is not following the law, and is texting while driving, and not occasionally looking up to receive new input, he'll not respect the red light.

When building with Actors, I find it usually helps me to think of the actors as people who react to events, then model it based on my observations of that.

 

Any application that needs to respond quickly to input of sensors
needs some way to ensure sufficient quick response time. There is,
e.g., interleaving in JADE (http://jade.tilab.com/). They had a very
nice slide about it on their site, but I can't find it anymore. The
processing of some message received by some agent is broken down into
nodes in a tree. Whenever a node in the tree has been executed, the
agent is available to poll any other input. It then resumes execution
by processing the next node in the tree. I don't really like this
approach as it appears quite effortful and cumbersome to me to create
that tree of nodes. But responsiveness is an issue people in the world
of agents have thought about. I was basically looking into actors,
because agents are somewhat dead (I guess ai never fulfilled its
promises and so agents couldn't do so, either). But actors are in
spirit very similar (active objects processing message queues) and
could serve as a replacement.

Can't he spawn child actors that work on individual pieces?

 

> ...and configure to use a priority queue mailbox to allow certain messages
> to jump the queue.

All right. If that kind of things can be configured, it can be done
anyway I guess.

Yes, but if your actor is blocking the thread, then you're essentially doing it wrong :-)

Cheers,

√

 

Thanks, Oliver

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--

Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Oliver Plow]

On Feb 2, 2:37 pm, √iktor Ҡlang <viktor.kl...@gmail.com> wrote:
> ...

> The Driver actor is reating to events that are sent to his sensory systems
> and are reacted upon. So when he gets the redlight message, he'll break his
> car. If the driver actor is not following the law, and is texting while
> driving, and not occasionally looking up to receive new input, he'll not
> respect the red light.

Hi Vik,

I see what you mean. Hm ... I believe things in the end remain much
simpler the way you suggest to address this issue. So the actor will
be reading a lot some values to see whether they have changed. Using
an STM here will therefore result in a lot of reads and few writes
which is the precondition for an STM to work efficiently, right? Yeah,
I like your approach better.

Cheers, Oliver

[√iktor Ҡlang]

Hi Oliver,

Even better, let the actor be a subscriber of events off of an EventBus, and chunk your work so you're not hogging your thread.

Think "reactive" instead of "active".

Cheers,

√

 

Cheers, Oliver

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Rüdiger Klaehn]

I had this discussion with roland a while ago. 

One use case for interrupting actors would be if you have some kind of computing server that takes third-party code and runs it, and you have a bug resulting in an endless loop.

Another would be if you have a large system of actors with some important components very well tested and guaranteed to work without hanging, and some components hacked together at the last minute due to some unreasonable customer demand (a situation we had several times in the past). It would be nice if you could somehow isolate the code you suspect to be buggy from the well-tested but very important actors without having to run them in separate processes and having the overhead of having to serialize/deserialize all messages.

I know the various methods for stopping an uncooperative thread like Thread.stop and Thread.destroy are all deprecated. But they do work, and having a way to kill an uncooperative actor that consumes 100% CPU to keep the system running would be extremely nice even if this would have the possibility of a deadlock. If all your messages are immutable (as they should be) this should be relatively safe and certainly better than the alternative of a bunch of uncooperative actors hogging all CPU cores and killing the system for sure. 

This would never be meant as a recommended way to stop an actor, but more as a measure of last resort like the Linux OOM killer.

2012/2/2 √iktor Ҡlang <viktor...@gmail.com>

[Derek Wyatt]

If we ever get to vote on doing anything that remotely resembles something like this, please mark my vote as a solid, bold and underlined 'no' :)

[Jonas Bonér]

LOL, mine as well.

--
Jonas Bonér
CTO

Typesafe - The software stack for applications that scale

Phone: +46 733 777 123
Twitter: @jboner

Blog: letitcrash.com

[edmond...@gmail.com]

I don't believe a framework feature should replace QA:)
Edmondo

Inviato da BlackBerry(R) Wireless Handheld

---

From: Rüdiger Klaehn <rkl...@googlemail.com>

Sender: akka...@googlegroups.com

Date: Thu, 2 Feb 2012 19:40:24 +0100

To: <akka...@googlegroups.com>

ReplyTo: akka...@googlegroups.com

Subject: Re: [akka-user] Are actors in Akka interruptible?

[Rüdiger Klaehn]

I guess I have to describe my use case a bit more:

We have a server application that gets data from various sources, does some processing and storage with it, and then allows a number of clients to query the data. The server application consists of several modules. There are several modules that use third-party proprietary libraries to decode proprietary data formats. These third party libraries are a bit buggy. They work fine most of the time, but once every few weeks they just hang when decoding some data for whatever reason. We don't have the source code, and for political reasons the company that provided us with the library has no interest whatsoever in fixing problems with it. So it is strictly "use as is". This might not be ideal, but I bet it is pretty common in the real world.

Now we would like to use akka for our server side infrastructure. We would like to have a way to isolate the actors that use the third-party library and thus have a low but non-zero probability of hanging when processing a message from the rest of our software that has to keep running. Ignoring the limitations of the JVM for a second, the perfect way to do this would be a watchdog that kills and restarts the actor whenever handling a message takes more than some predefined time. Basically a zombie-killer. The zombie-killer would write a message in the log that an actor has been killed, and the entire JVM should be restarted as soon as possible. 

Of course the brute force solution would be to launch every module in its own process with its own JVM, and then restart the JVM automatically as soon as an actor does not respond to ping messages for a certain time. But that would have a very large latency and throughput overhead because you would have to serialize and deserialize every single message. But it is the only way that provides perfect isolation. We will try to do something like this, since in our case the overhead might be acceptable. Other than the serialization overhead the location independence of actors should make this possible without too much pain.

But there are a lot of interesting scenarios where running each independent module in its own JVM is completely impractical. For example a multiplayer game where each player can script its own avatar by providing a .jar. Something like secondlife or eve online. At first glance this looks like a perfect fit for akka. But you need to provide isolation, and since there are a lot of players and they interact constantly, the overhead of starting a new JVM would be prohibitive. It is easy enough to prevent the users from doing bad stuff by limiting the namespaces they may use in a class loader. But it is not possible to prevent a user from accidentally creating an endless loop (or endless tail-recursion). So either you have some way to get rid of the occasional zombie, or you just can't use akka or the JVM period.

Maybe something could be done at JVM level to make creating multiple JVMs less expensive. But real isolation of actors would be a great feature and not just some hack to avoid having good QA. Besides, you can not really have a philosophy of "let it crash" and be able to completely freeze akka by having an accidental endless loop in one actor. 

[Derek Wyatt]

My bet is that everyone gets your use case.  I myself have encountered it a number of times.  But there are realities here:

1) You're not talking about Actors, you're talking about threads.  It might look like something Actors can do because of the beautiful way these guys hide the nasty world from you but it's not.

2) There is no way, in any language that I know of, on any platform that I know of, where "killing" a thread is actually supported.  There are remnants of this mistake out there but they are deprecated.

3) I argue that it is not as common as you think.  Smart companies that make good software don't let this situation occur.  Google, Twitter, etc… these guys ensure the libraries they use don't suck.  If they do, then they write better ones and displace the garbage.  Your company is making a very poor decision.

4) Edmondo had it right.  You're replacing QA with toolkit functionality - toolkit functionality that can't exist at this point in time.

5) A separate process is really the only way to go if you want to do this

Your situation is completely awful.  If the powers that be are forcing you into an awful situation and you can't find a good way out of it, then you have to find a not-so-good way out of it.  Using defective software in production software is just a wrong thing to do.

Regs,

Derek

[√iktor Ҡlang]

You can always create your own Dispatcher that tracks misbehaving actors and kills their current worker thread. But since this is not supported or recommended on the JVM (Thread.stop/destroy), it means I cannot add it to Akka and then have to support it for our customers.

Cheers,

√

[Oliver Plow]

> Now we would like to use akka for our server side infrastructure. We would
> like to have a way to isolate the actors that use the third-party library
> and thus have a low but non-zero probability of hanging when processing a
> message from the rest of our software that has to keep running. Ignoring
> the limitations of the JVM for a second, the perfect way to do this would
> be a watchdog that kills and restarts the actor whenever handling a message
> takes more than some predefined time. Basically a zombie-killer.

Maybe this is naiv now or I might not be getting something... Simply
doing myActorThread.interrupt() as in
http://docs.oracle.com/javase/tutorial/essential/concurrency/simple.html
won't be sufficient?

Regards, Oliver

[Oliver Plow]

On Feb 2, 7:40 pm, Rüdiger Klaehn <rkla...@googlemail.com> wrote:
> I had this discussion with roland a while ago.
>
> One use case for interrupting actors would be if you have some kind of
> computing server that takes third-party code and runs it, and you have a
> bug resulting in an endless loop.

As a render of last resort you can interrupt the thread with some
approach like this: http://docs.oracle.com/javase/tutorial/essential/concurrency/simple.html

Your actor then needs to do its work in a try-catch-block like this:

try {
// do my work
}
catch (InterruptedException e) {
System.out.println("got interrupted");
}

[Oliver Plow]

>I know the various methods for stopping an uncooperative thread like
>Thread.stop and Thread.destroy are all deprecated. But they do work,

As the javadocs mention these methods are deadlock-prone and therefore
deprecated. The propper way is to use Thread.interrupt(). Seems that
you cannot include links in a post. It then gets rejected as I already
posted this reply twice. If you google for 'Java "The SimpleThreads
Example"' you get a sample of how to do this propperly using
Thread.interrupt(). Only a remark. The discussion is about something
else, I know.

--Oliver

[√iktor Ҡlang]

Nope, interrupt only sets a flag on a thread, and you need to poll that and react to it.

 

Regards, Oliver

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Rüdiger Klaehn]

On Fri, Feb 3, 2012 at 10:50 AM, Derek Wyatt <de...@derekwyatt.org> wrote:

My bet is that everyone gets your use case.  I myself have encountered it a number of times.  But there are realities here:

1) You're not talking about Actors, you're talking about threads.  It might look like something Actors can do because of the beautiful way these guys hide the nasty world from you but it's not.

Of course. I was hoping that since the Akka guys seem to know the JVM inside out they might find a solution for this problem. Also, interrupting a thread that runs actor should be less troublesome than interrupting a thread in your run of the mill java program since a well-designed actor should not use locks or do blocking IO. And you could ensure this with a class loader.

 

2) There is no way, in any language that I know of, on any platform that I know of, where "killing" a thread is actually supported.  There are remnants of this mistake out there but they are deprecated.

Well, in .NET you have the concept of an app-domain, which provides a level of isolation. And of course many scripting languages make using a process as a level of isolation easier because they don't have such a huge overhead for creating a new process. In low-level languages like C you have fork(), so you can also cheaply create a process at least on linux.

 

3) I argue that it is not as common as you think.  Smart companies that make good software don't let this situation occur.  Google, Twitter, etc… these guys ensure the libraries they use don't suck.  If they do, then they write better ones and displace the garbage.  Your company is making a very poor decision.

It's not up to us. We are a tiny company that have to work together with huge companies for some projects. These huge companies have software departments of their own, so they see us as a competitor and are thus not that interested in providing us with bug-free libraries. They just grudgingly provide us with a library that works most of the time. 

 

4) Edmondo had it right.  You're replacing QA with toolkit functionality - toolkit functionality that can't exist at this point in time.

5) A separate process is really the only way to go if you want to do this

This is where we want to go in the long term. We already do it for some interfaces. And akka should make this a bit easier. I think we should be OK.

 

Your situation is completely awful.  If the powers that be are forcing you into an awful situation and you can't find a good way out of it, then you have to find a not-so-good way out of it.  Using defective software in production software is just a wrong thing to do.

Well, as I said it is not up to us. But I am willing to bet that there are a lot of companies in a similar situation. 

[rkuhn]

Hi Rüdiger,

there was a ticket enabling something which would probably cover your use case: http://www.assembla.com/spaces/akka/tickets/1014
(this is of course no coincidence since it was created following a discussion we had last year ;-) )

The reason why Viktor closed it as invalid is plausible, because it would indeed be hard (in the sense that we would be re-implementing JBOSS or something within Akka); I am not yet convinced that it is impossible, though, by waving the dark magician’s wand and conjuring the powers of ClassLoaders with (possibly) SecurityManagers.

This will need some more thought after 2.0 is out, because sand-boxing parts of an application is definitely a very interesting feature.

Regards,

Roland

2012/2/2 √iktor Ҡlang <viktor...@gmail.com>

Hi Oliver,

√

 

Thanx, Oliver

To unsubscribe from this group, send email to akka-user+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.

To unsubscribe from this group, send email to akka-user+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.

To unsubscribe from this group, send email to akka-user+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.

To unsubscribe from this group, send email to akka-user+unsubscribe@googlegroups.com.

[√iktor Ҡlang]

On Fri, Feb 3, 2012 at 11:10 AM, Rüdiger Klaehn <rkl...@googlemail.com> wrote:

On Fri, Feb 3, 2012 at 10:50 AM, Derek Wyatt <de...@derekwyatt.org> wrote:

My bet is that everyone gets your use case.  I myself have encountered it a number of times.  But there are realities here:

1) You're not talking about Actors, you're talking about threads.  It might look like something Actors can do because of the beautiful way these guys hide the nasty world from you but it's not.

Of course. I was hoping that since the Akka guys seem to know the JVM inside out they might find a solution for this problem. Also, interrupting a thread that runs actor should be less troublesome than interrupting a thread in your run of the mill java program since a well-designed actor should not use locks or do blocking IO. And you could ensure this with a class loader.

Wouldn't help since the Actor could call into JDK code that uses monitors.

 

 

2) There is no way, in any language that I know of, on any platform that I know of, where "killing" a thread is actually supported.  There are remnants of this mistake out there but they are deprecated.

Well, in .NET you have the concept of an app-domain, which provides a level of isolation. And of course many scripting languages make using a process as a level of isolation easier because they don't have such a huge overhead for creating a new process. In low-level languages like C you have fork(), so you can also cheaply create a process at least on linux.

Look at the dthreads paper.

 

 

3) I argue that it is not as common as you think.  Smart companies that make good software don't let this situation occur.  Google, Twitter, etc… these guys ensure the libraries they use don't suck.  If they do, then they write better ones and displace the garbage.  Your company is making a very poor decision.

It's not up to us. We are a tiny company that have to work together with huge companies for some projects. These huge companies have software departments of their own, so they see us as a competitor and are thus not that interested in providing us with bug-free libraries. They just grudgingly provide us with a library that works most of the time. 

 

4) Edmondo had it right.  You're replacing QA with toolkit functionality - toolkit functionality that can't exist at this point in time.

5) A separate process is really the only way to go if you want to do this

This is where we want to go in the long term. We already do it for some interfaces. And akka should make this a bit easier. I think we should be OK.

With Akka it

s een simpler since you can just use Remote Actors for that.

 

 

Your situation is completely awful.  If the powers that be are forcing you into an awful situation and you can't find a good way out of it, then you have to find a not-so-good way out of it.  Using defective software in production software is just a wrong thing to do.

Well, as I said it is not up to us. But I am willing to bet that there are a lot of companies in a similar situation. 

The problem is not solvable on top of the JVM, it needs to be solved inside.

 

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Rüdiger Klaehn]

Thanks. I understand that you can not rely on non- recommended functionality unless you are really sure that it works. I was just thinking that if anybody can find a solution to this problem it would be you guys. You do use sun.misc.Unsafe after all :-) 

But maybe dealing with this properly would require some changes at the JVM level.

2012/2/3 √iktor Ҡlang <viktor...@gmail.com>

[√iktor Ҡlang]

On Fri, Feb 3, 2012 at 11:15 AM, Rüdiger Klaehn <rkl...@googlemail.com> wrote:

Thanks. I understand that you can not rely on non- recommended functionality unless you are really sure that it works. I was just thinking that if anybody can find a solution to this problem it would be you guys. You do use sun.misc.Unsafe after all :-) 

I am honored by your faith in us ;-)

 

But maybe dealing with this properly would require some changes at the JVM level.

Yup, something like dthreads for the JVM would be cool.

 

2012/2/3 √iktor Ҡlang <viktor...@gmail.com>

You can always create your own Dispatcher that tracks misbehaving actors and kills their current worker thread. But since this is not supported or recommended on the JVM (Thread.stop/destroy), it means I cannot add it to Akka and then have to support it for our customers.

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Derek Wyatt]

I feel your pain :)  But everyone has already said it… you want a new version of the JVM, not Akka.  Once the JVM can do it, I have 100% faith that these guys will incorporate and you won't even know it's there… Hell, they'll probably use it to fix the defective code at runtime :)

[Rüdiger Klaehn]

If I remember correctly, Thread.Interrupt only interrupts blocking IO operations. But it won't interrupt a thread that is stuck in a loop like while(true) {}. You need to use the (deprecated) Thread.stop() for that:

scala> def run = new Runnable { def run { while(true) {} } }

run: java.lang.Object with java.lang.Runnable

scala> val t=new Thread(run)

t: java.lang.Thread = Thread[Thread-20,5,main]

scala> t.start

scala> t.isAlive

res9: Boolean = true

scala> t.interrupt

scala> t.isAlive

res11: Boolean = true

scala> t.stop

warning: there were 1 deprecation warnings; re-run with -deprecation for details

scala> t.isAlive

res13: Boolean = false

}

[√iktor Ҡlang]

On Fri, Feb 3, 2012 at 11:20 AM, Derek Wyatt <de...@derekwyatt.org> wrote:

I feel your pain :)  But everyone has already said it… you want a new version of the JVM, not Akka.  Once the JVM can do it, I have 100% faith that these guys will incorporate and you won't even know it's there… Hell, they'll probably use it to fix the defective code at runtime :)

We just hired on of the JRockit founders for my team ;)

[Derek Wyatt]

Then I expect to see that feature in the roadmap! :)  Lotsa good news from across the sea.  It makes me wish I was Swedish.

[√iktor Ҡlang]

On Fri, Feb 3, 2012 at 11:25 AM, Derek Wyatt <de...@derekwyatt.org> wrote:

Then I expect to see that feature in the roadmap! :)

Lol!

 

 Lotsa good news from across the sea.  It makes me wish I was Swedish.

Just stay awesome :-)

[Derek Wyatt]

It's probably just as well, I could never get used to pronouncing "J" as "Y" :)  

(Alright, I've completely destroyed this thread now… sorry)

[Rüdiger Klaehn]

On Fri, Feb 3, 2012 at 11:13 AM, rkuhn <goo...@rkuhn.info> wrote:

Hi Rüdiger,

there was a ticket enabling something which would probably cover your use case: http://www.assembla.com/spaces/akka/tickets/1014
(this is of course no coincidence since it was created following a discussion we had last year ;-) )

The reason why Viktor closed it as invalid is plausible, because it would indeed be hard (in the sense that we would be re-implementing JBOSS or something within Akka); I am not yet convinced that it is impossible, though, by waving the dark magician’s wand and conjuring the powers of ClassLoaders with (possibly) SecurityManagers.

Well, as a brute force (but slow) solution you could inject code to check an abort flag into all loops and method calls. That would also cover tail-recursive methods since they get translated to loops by scalac. Blocking calls into operating system code would have to be dealt with by interrupt, which is not deprecated. Of course this would slow down everything tremendously, since you would have to apply this byte code transformation not just to the user code but also to the code used by the user code, like scala.collection._

By the way: what exactly happens if I use jni to call fork() in a JVM that has been running for a while and therefore has most of the scala library already JIT-compiled? Do you have two independent JVMs or just two broken processes???

Anyway, we will just use processes and eat the overhead of multiple JVMs for now.

[Oliver Plow]

> Even better, let the actor be a subscriber of events off of an EventBus,
> and chunk your work so you're not hogging your thread.
> Think "reactive" instead of "active".

Yes, I see. That's why I would like the STM-based transactional
distributed maps, I want to develop, that are shared by (remote)
actors to coordinate themselves, have an API so that the user can
register for asynchronous event notification on put and remove.

-- Oliver

[Roman Levenstein]

Hi

On Friday, February 3, 2012 12:15:25 PM UTC+1, rklaehn wrote:

On Fri, Feb 3, 2012 at 11:13 AM, rkuhn wrote:

Hi Rüdiger,

there was a ticket enabling something which would probably cover your use case: http://www.assembla.com/spaces/akka/tickets/1014
(this is of course no coincidence since it was created following a discussion we had last year ;-) )

The reason why Viktor closed it as invalid is plausible, because it would indeed be hard (in the sense that we would be re-implementing JBOSS or something within Akka); I am not yet convinced that it is impossible, though, by waving the dark magician’s wand and conjuring the powers of ClassLoaders with (possibly) SecurityManagers.

Well, as a brute force (but slow) solution you could inject code to check an abort flag into all loops and method calls. That would also cover tail-recursive methods since they get translated to loops by scalac. Blocking calls into operating system code would have to be dealt with by interrupt, which is not deprecated. Of course this would slow down everything tremendously, since you would have to apply this byte code transformation not just to the user code but also to the code used by the user code, like scala.collection._

I've experimented with byte-code instrumentation for similar purposes. The goal was to limit a share of a CPU time spent for a specific tenant in our multi-tenant application. As part of the solution it was possible to kill or put on hold any specific thread. In principle, it worked, but it introduced quite some overhead, which was still below what we have expected, i.e it was well below 100%, IIRC. But as indicated in this thread, it is hard to imagine any really efficient solution for this problem without changing the internals of the JVM.

Regards,
  Roman

[Derek Williams]

On Fri, Feb 3, 2012 at 3:20 AM, Rüdiger Klaehn <rkl...@googlemail.com> wrote:

If I remember correctly, Thread.Interrupt only interrupts blocking IO operations. But it won't interrupt a thread that is stuck in a loop like while(true) {}. You need to use the (deprecated) Thread.stop() for that:

It's perfectly possible to interrupt non blocking code, but the code has to check Thread.interrupted, so it wont help you for misbehaving code.

Also, according to this page:

http://docs.oracle.com/javase/7/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html

A thread that doesn't respond to Thread.interrupt wouldn't have responded to Thread.stop either. I haven't tested to verify this though.

 

--

Derek Williams

[Rüdiger Klaehn]

On Fri, Feb 3, 2012 at 4:50 PM, Derek Williams <de...@fyrie.net> wrote:

Also, according to this page:

http://docs.oracle.com/javase/7/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html

A thread that doesn't respond to Thread.interrupt wouldn't have responded to Thread.stop either. I haven't tested to verify this though.

 

Strange. I was able to stop a while(true) {} loop using Thread.stop(), but not using Thread.interrupt(). See console session in a previous post.

[Derek Williams]

Yeah, I thought that was the case to. Like I said, I didn't test it... not the first time there would be wrong/misleading info out there.

--

Derek Williams

[Oliver Plow]

> Strange. I was able to stop a while(true) {} loop using Thread.stop(), but
> not using Thread.interrupt(). See console session in a previous post.

Thread.stop is deadlock-prone as the javadocs say. So in many cases
you will be lucky and it works, but somewhen things run into a
deadlock and then you are really stuck.

-- Oliver

[√iktor Ҡlang]

And then I don't want to have to be the support guy

[edmond...@gmail.com]

LOL. I agree with Viktor. Unless you want the Gods of JVM to get angry with you, please avoid working on Threads directly.

If Java community has striven since java 5 to propose better ways to do multithreading there are probably good reason.

Nevertheless, you can use Object.wait and Object.notify but don't ask help :)

Best

Inviato da BlackBerry(R) Wireless Handheld

---

From: iktor lang viktor...@gmail.com

Sender: akka...@googlegroups.com

Date: Sat, 4 Feb 2012 14:23:46 +0100

To: <akka...@googlegroups.com>

ReplyTo: akka...@googlegroups.com

Subject: Re: [akka-user] Re: Are actors in Akka interruptible?