I have been able to setup an rmi server and call it successfully with no problem in my debugging but when I am trying to use it in a 'real case' it hangs. My real case is a plugin for a 3rd party application where it makes calls to my server application. My client actually starts the server side by starting a new process which puts the object in the registry. My client then calls the stub and calls a method in it but it only gets so far then stops. If I then kill my client the server will continue. Its as if the client side is holding onto something that the server side needs but they are running in separate jvm's so I can't work out what it would be. I wouldnt have thought what the client was doing would have any affect?
As I said the debugging of this works, ie the client starts the server process and then calls to the server are ok. I'm not running it with a security policy as its only a demo for now but not sure if thats an issue? Its all running on one machine, not distributed in any way.
The client is in 1.6 whereas the server is 1.7, again, is that a problem?
I was wondering if anybody has had similar problems or can recommend another way to do what I'm trying to besides RMI. Any guidance appreciated.
Related
I premise that I don't know a lot about DataStage.
I just know that somebody else has created an "ETL job" and I need to launch it from my Java program, that acts as a client.
How should I do?
Edit:
The DataStage server is phisically different from the client where the Java program runs. I am not allowed running commans on the DataStage server. I need to connect via network. I imagined that DataStage provides some kind of network protocol, or webservice, or something so.
You can use the dsjob command - details see the Knowledge Center
Edit:
dsjob needs to be executed at the server.
You could use a insert into a database table from remote and trigger something (i.e. a UDF) that executes the dsjob on the server.
Alternatively use the WaitForFile stage and transfera file to the server.
I have been trying to figure out how to implement a simple xml rpc server and client with apache xml-rpc (http://ws.apache.org/xmlrpc/) but i haven't been successfull. I implemented a server and a client as specified here in the section Webserver: http://ws.apache.org/xmlrpc/server.html
The only thing i did differently was this "phm.addHandler("Calculator",org.apache.xmlrpc.demo.Calculator.class);" instead of this "phm.load(Thread.currentThread().getContextClassLoader(), "MyHandlers.properties");". When i start the server it start properly but I can't see the service when running netstat. Then when I run a request from the client it fails because it cannot find the class to call (i.e. the client doesn't really connect to the server). I have also observed that the client can start (not sending any requests) without any errors even when the server is not running.
Anyone have any ideas. I'm really lost.
Are you trying to run both client and server on the same computer? ...that may be the reason for netstat not working. (It cannot sniff packets on the loopback address.)
If you're still interested I can post a working example.
Some background information.
- Running a java server on localhost
- Running a webserver on localhost
I would like a webpage to have a 'server status' feature which lets me know whether the server is running or not. My question, what is the best way to do this?
When I launch the java server, I write a flag in the database to signify that it is running.
Javascript/PHP sockets to try and bind on the same port. (Not sure if possible yet)
Shell script to locate the program in the task list.
Thanks!
When I launch the java server, I write
a flag in the database to signify that
it is running.
would not be of much help if the server should segfault.
Maybe have a look at http://mmonit.com/monit/
what is pretty much what you are looking for
I suspect the simplest method is simply for your web service (backend) to try and connect to the port that your server is running on, and provide an automatically refreshing page that reports this status. If your server goes down then you'll get an faster notification than if you're polling (say) the process table.
Of course the fact that you can connect to the port doesn't really give you an indication of whether it's working other than it's opened a port (e.g. it may have no resources etc. to service requests) but it's a start.
I'm new to Java and RMI, but I'm trying to write my app in such a way that there are many clients connecting to a single server. So far, so good....
But when I close the server (simulating a crash or communication issue) my clients remain unaware until I make my next call to the server. It is a requirement that my clients continue to work without the server in an 'offline mode' and the sooner I know that I'm offline the better the user-experience will be.
Is there an active connection that remains open that the client can detect a problem with or something similar - or will I simply have to wait until the next call fails? I figured I could have a 'health-check' ping the server but it seemed like it might not be the best approach.
Thanks for any help
actually i'm just trying to learn more about RMI and CORBA but i'm not that far as you are. all i know is that those systems are also built to be less expensive, and as far as i know an active conneciton is an expensive thing.
i would suggest you use a multicast address to which your server sends somehow "i'm still here" but without using TCP connections, UDP should be enough for that purpose and more efficient.
I looked into this a bit when I was writing an RMI app (uni assignment) but I didn't come across any inbuilt functionality for testing whether a remote system is alive. I would just use a UDP heartbeat mechanism for this.
(Untested). Having a separate RMI call repeatedly into the server, which just does a "wait X seconds" and then return, should be told that the execution has failed when the server is brought down.
I've written a very simple server that accepts socket connections on a specific port
and communicates with clients over that socket.
Now I have a client lib which works perfectly fine in J2SE apps.
However, if I try to use that lib in a Servlet (the Servlet being the client) to communicate with the server it doesn't work.
Unfortunately there is no Exception or something that could help me.
Instead when using the lib simply nothing happens.
That is the call to the method within which the socket is opened just blocks indefinitely
while no connection is made to the server.
I reckon this could be a general problem.
Maybe things like that are not allowed from within a Servlet?
But even if not I would at least expect that some Exception to be thrown.
The Servlet Container is Tomcat by the way.
Has anyone got an idea as to why this doesn't work?
Ok here is there actual problem:
It seems to be a difference in behaviour between Windows and Linux.
I developed the server + lib under Linux while Tomcat runs on a Windows machine.
Among other things the server I told you about executes a command
via ProcessBuilder.
What actually blocked indefinitely was the Process#waitFor.
That is under Windows. Under Linux it works just fine and returns as soon as the process is finished.
Under Windows however Process#waitFor only returns when I read the Process's InputStream for some reason.
Sorry!