river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Towards Internet Jini Services (trust)
Date Wed, 06 Oct 2010 11:35:32 GMT
Sim IJskes - QCG wrote:
> On 10/06/2010 02:58 AM, Peter Firmstone wrote:
>>> I want this trust system to be dynamic. I want to be able to change my
>>> mind.
>> Once you've loaded the class files, that's it, the ClassLoader will only
>> become garbage collected when no strong references to objects and class
>> files remain. You've only got one shot at that decision.
> Thats too much black and white for me. I was talking about multiple 
> invocations of a VM. So that means remembering trust decisions.

That makes sense, perhaps you can share the trust decision and the 
result of that decision by submitting it to a feedback service, your VM 
could send this information before shutting down.

> I we have misbehaving code, we cannot stop it easily. So that means 
> changing the trustlevel, and restarting the VM (no specific order).

Have you got any thoughts on trust levels?

> Or are you willing to use Thread.stop()?
No, first implement an UncaughtExceptionHandler, use it with a Single 
threaded ExecutorService, also create a ThreadFactory that creates a 
Thread utilising the UncaughtExceptionHandler.

This catches a StackOverflowError, we still need strategies for other 
Errors.  Instead of using Runnable, Callable is used so that the method 
calls from the reflective proxy return any Exceptions, these can be 
wrapped in an IOException for the client to handle.

Since the thread is a low priority the impact of it running will be low, 
so we can set the interrupt status of the Thread.  Thread.sleep and 
Object.wait methods will respond to the interrupted state, so eventually 
the thread will be interrupted and the smart proxy reference will be set 
to null, which causes all method calls to throw an IOException.  The 
thread will eventually terminate, without taking out the JVM.

Furthermore all objects created during unmarshalling are not shared, no 
blocking methods that ignore interruption will prevent the thread from 
being interrupted.  If it's caught in an endless loop, the 
StackOverflowError will eventually be thrown and caught by the 
UncaughtExceptionHandler, which deletes the smart proxy reference and 
sets the correct state of the reflection proxy's InvocationHandler 
before it shuts down, causing all client calls to receive an IOException.

MarshalledInstance contains the byte array for the objects already, so 
the thread won't block waiting on a Socket, ignoring the interrupt.

Authentication doesn't utilise the proxy code, only local code, so if we 
can't authenticate, shut it down.

I've got some sample code up on Pepe, have a look, time permitting, I'll 
expand it further, we can get some test cases going, if there's a show 
stopping issue we can't solve, then I'll drop the idea.  So far I 
haven't discovered that show stopper.

If you don't like the eventual solution, you can still vote against it 
before it gets merged, it may never get that far, you or I might 
discover that show stopper.


View raw message