cojen/dirmi

Dirmi is a replacement for Java RMI which supports bidirectional remote objects.

Dirmi is a replacement for Java RMI which supports bidirectional remote objects.

• Javadocs
• Wiki

dirmi's Issues

Support lenient restorable methods

Add an optional Restorable.lenient field which defaults to false. When true, invoking a method on a broken connection doesn't throw an exception, but instead it returns an object which is in a broken state. When the session reconnects, the broken object is restored.

Improved support for OSGi

The bridge class loader is one component of this, but is this enough?

Automatic Remote Classloading

Hi, I just stumbled across your project today and I have to say I am really impressed. One thing that's missing for me, though, is the automatic remote classloading that standard RMI offers.

Do you have any plans to implement this feature? I noticed the environment classloader itself is now configurable, and I saw some interesting bits in the DirmiMobileCode directory.

I'm trying to put together a sort of generic 'compute' RMI grid, along the same lines of what Oracle outlines in their RMI Trail, but without the complexity of standard RMI's registry and port madness. If Dirmi could transfer unresolved classes transparently, that would make it a perfect fit.

Maven repo central and project status

Hi,
Does project Dirmi is still active? Do you plan to deploy the last version it to central maven repo ?
Thanks,

Marek

Support session creation from a given Input/Output stream pair

I'm trying to use dirmi over an already-established tunnel where both ends have an InputStream and OutputStream connected to the other side. I'm blocked trying to get the session established in this scenario. I saw the PipedChannelBroker code, but it doesn't look applicable (or I'm just being dense).

Do you have any implementation pointers here? I'm going to keep digging on my end, but any advice would be appreciated. I will gladly contribute back the implementation code as a PR.

Alternative Pipe/Stream Implementation

Hi, I hope you don't get sick of me. :)

I'm thinking through the Pipe/Stream support and it's pretty cool. I love the idea of being able to stream large binary blobs without using a side-channel or sending a huge byte array. However, the current Pipe implementation requires interface adaptations that change the semantics of the 'Server' code so that it no longer behaves the same if you run it locally outside of Dirmi. Or so it looks, please correct me if I'm wrong.

Have you thought about adding direct support for InputStream/OutputStream method params/return types? I'm envisioning proxy/stub objects that buffer and automatically pump data across the link as the other end is read/written.

So in code terms, supporting something like:

public interface FileService extends Remote {
    void uploadFile(String name, InputStream content) throws RemoteException; 
}

Then a client could do something like:

FileService service = (FileService) session.receive();
String name = "huge.zip";
service.uploadFile(name, new FileInputStream(name));

The client stub would recognize the InputStream type and pump it to the service side, which would be delivered some sort of DirmiRemoteInputStream class that behaved appropriately as an InputStream. Then the FileService implementation would behave the same whether invoked locally or via RMI.

Anyway, I would put it in the nice-to-have column. I would gladly send you a patch, but I'm still learning the framework and have a lot of my own implementation to take care of first.

Recognize the session associated with a request

Hi mates, how can I recognize the session associated with a request?

Regards

Connection fails on high latency networks

I've been experimenting with dirmi, hoping to use it for a new project I'm starting. Everything works very well under normal network conditions however the network that I will be deploying the finished project on is very high latency. Typically about 800 to 1200 milliseconds. I'm unable to establish a connection to a dirmi server under those conditions.

The problem is easily reproducible, I use the tc command on my CentOS6 server to create high latency in the network adapter. For example I use the command 'tc qdisc add dev eth0 root netem delay 5000ms' to create 5 seconds of latency. That value will certainly guarantee the connect failure. Use 'tc qdisc del dev eth0 root netem' to cancel the effect.

I was using the basic RemoteExample code from the website but I added longer timeouts wherever I could. Unfortunately the problem occurs during the initial connection and we never actually make it to the user definable timeouts. Here's my test code for reference:

@timeout(120)
@TimeoutUnit(TimeUnit.SECONDS)
public interface RemoteExample extends Remote {
@timeout(120)
@TimeoutUnit(TimeUnit.SECONDS)
String talk(String name) throws RemoteException;
}

public class RemoteExampleClient {
public static void main(String[] args) throws Exception {
Environment env = new Environment();
String host = "192.168.56.101";
System.out.println("Connecting...");
Session session = env.newSessionConnector(host, 30000).connect();
RemoteExample example = (RemoteExample) session.receive(60, TimeUnit.SECONDS);
String response = example.talk("Dirmi");
System.out.println(response);
env.close();
}
}

public class RemoteExampleServer implements RemoteExample {
public static void main(String[] args) throws Exception {
Environment env = new Environment();
RemoteExample server = new RemoteExampleServer();
env.newSessionAcceptor(30000).acceptAll(server);
System.out.println("Server ready...");
}

 public String talk(String name) {
     return "Hello " + name;
 }

}

When I run the client I receive the following error:

run:
Connecting...
Exception in thread "main" org.cojen.dirmi.ClosedException: Closed
at org.cojen.dirmi.io.PacketOutputStream.out(PacketOutputStream.java:413)
at org.cojen.dirmi.io.PacketOutputStream.write(PacketOutputStream.java:91)
at java.io.ObjectOutputStream$BlockDataOutputStream.writeBlockHeader(ObjectOutputStream.java:1889)
at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1874)
at java.io.ObjectOutputStream$BlockDataOutputStream.flush(ObjectOutputStream.java:1821)
at java.io.ObjectOutputStream.flush(ObjectOutputStream.java:718)
at org.cojen.dirmi.core.InvocationOutputStream.flush(InvocationOutputStream.java:276)
at org.cojen.dirmi.core.StandardSession.(StandardSession.java:380)
at org.cojen.dirmi.core.StandardSession.create(StandardSession.java:215)
at org.cojen.dirmi.core.StandardSession.create(StandardSession.java:202)
at org.cojen.dirmi.Environment.newSession(Environment.java:334)
at org.cojen.dirmi.Environment$SocketConnector.connect(Environment.java:560)
at dtsimple.RemoteExampleClient.main(RemoteExampleClient.java:12)
Java Result: 1

I've tried poking around in the source to see why that stream is being closed but haven't tracked down the problem yet. Is there some setting I should tweak or something else I'm missing? Any help or insights would be greatly appreciated. If I can get this to work, I think this library is going to be perfect for my project.

Thanks!

RemoteException should include the remote address

Customizable ClassLoader for Sessions

As a convenience, a default ClassLoader should be an Environment option for use by new sessions. This facilitates using Dirmi with frameworks that rely heavily on custom class loading.