No longer maintained. Instead, use Cojen/Maker for bytecode generation.
Java bytecode generation and disassembly tools
Dirmi is a replacement for Java RMI which supports bidirectional remote objects.
License: Apache License 2.0
No longer maintained. Instead, use Cojen/Maker for bytecode generation.
Java bytecode generation and disassembly tools
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.
Hi,
Does project Dirmi is still active? Do you plan to deploy the last version it to central maven repo ?
Thanks,
Marek
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.
The bridge class loader is one component of this, but is this enough?
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.
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.
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!
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.
Hi mates, how can I recognize the session associated with a request?
Regards
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.