I need to pass information from a shell script (called from a linux based app) to a java application.
Named pipes are a pain because I can't start/stop either service without considering complex repercussions to the read/write ends of the pipes.
Sockets are tough because if the listening process is restarted there's no queuing mechanism, and simple implementations require new sockets be constantly created (else the shell script will get very complex with check-and-restart-socket, and queuing code).
I was recently reading about these System V/POSIX linux message queues. I'm running Fedora 12, and wonder if there's a good way to configure these message queues and interact with them from Java.
You can't use them directly, you'd have to do some JNI wizardry to interface them together.
What problems are you having with Pipes? Java sees those as just generic files. I haven't used them extensively, but I didn't have any real problems with Pipes. The only detail there was the pipe reader needs to continually reopen the pipe if the producers can't keep up.
But if either side fails, the other side just blocks waiting for the other to recover.
You just have to be careful with buffer reads from the pipe. If you read from the pipe in to a buffer, and then fail, that data is lost.
Related
main aim = minimize time of execution process.
Want to create system process with running some programm, and reuse it.
For example
command = "/client.exe -ip=127.0.0.1 -port=1234" + somecommand
execute it
Process(command).lineStream.mkString
Result of execution is very slow.
How can I run client.exe once, and reuse this process. Just send some new commands every time to the existing process client.exe.
Any ideas how to increase speed of execution ?
Thanks.
What you want is actually interprocess communication and/or remote procedure call. You can use several methods to achieve this. Some of them are:
Using REST/HTTP, spray is probably simplest and best solution for this.
Using Akka, Akka supports remote actors, this means you can spawn an actor on the main process and access it from other processes and send/receive messages.
If you are on a *nix system you can use raw sockets.
Use a message queue, check RabbitMQ
if client.exe has sequential execution and it is designed to quit after work done, then You can't do much. Executable should be written to handle interprocess communication.
I've written a Java application that is launched as a daemon (I daemonize redirecting stderr and stdout and closing stdin though bash). However, occasionally I would like to be able to message this application and inform it to change certain parts of its behavior. I need to be able to message the application from a terminal, so anything that requires a graphical utility is a no-go.
The change in behaviour is fairly simple. I need a toggle for the state of one thread in my application, and a way to gracefully close the application.
What are my options in achieving this? I know I could have a thread in the process that listens on a socket of some sort for messages, but this seems like overkill for the needs I have.
I'm not too familiar with Signals on Linux/Unix, so I'd like to ask if I could simply set up a custom handler for some signals, and have my code execute when the process receives a signal.
Are there any other options that I simply don't know about or haven't thought about?
Signals may be the easiest. You have SIGUSR1 and SIGUSR2 available for application use and you can write a handler for them to manage your toggle. Generally you don't want to do much in a handler so you can set a switch and your main loop (or whatever) needs to check the switch and act accordingly. Similarly the receipt of the signal could be programmed to read a config file that you changed.
Beyond that you can use any available IPC (fifos, sockets, MQs) but you are going to either have thread blocking on them or somehow incorporate them a select statement (or whatever the java equivalent of that is).
You basically need a small client that communicates with your application (server). So the default solution should be to use some IPC mechanism. Putting an IPC mechanism is a one time effort and is worth the trouble because it scales well with the requirements. Using signals for IPC is not recommended. I think sockets is a good way to go.
Personally, I like to use OS signals for this.
Use java.lang.Runtime.addShutdownHook and send a SIGTERM, SIGINT or SIGHUP.
Be aware that some signals are reserved for internal use, check out the docs for the JVM you are using.
The SignalHandler is not part of the supported, public interface, so your mileage may vary.
If you are instantiating a JVM from C code, simply set signal handlers (in C) before the JVM and you will be fine.
This could probably be the strangest question every asked here. I'll try to explain it the best I can.
I need to rapidly develop a network application in Java, integrating a bunch of old network applications (I already have the code for them) and making everything work together. Each old application will become a sub-function of the new one; the new one is fundamentally a "wrapper".
Obviously, each of these applications (which have been developed by different people in different times) work in different way, with different protocols, with radically different syntax for the messages (i.e. some protocols use binary messages, some other use HTTP like messages, some other use XML) and different message order strategies (pipelining, stop and wait, etc...).
Fortunately, they are all TCP.
The wrapper application should work opening something like 6-7 different sockets at different ports, and this is not good for our network administrators. They only want one socket on one port. So all the protocols have to crush on the same pipe.
Is there any pure Java, out-of-the-box solution to multiplex and demultiplex many independent full-duplex streams on the very same TCP socket, in a transparent and hassle-free manner?
Or is there a simpler solution I'm forgetting about?
EDIT: the sub-streams are independent, i.e. there's no deadlock possibility caused by one sub-stream waiting for some stuff coming from another.
You can't do it in a transparent manner over TCP.
Consider for example what will happen if your application sends a request over one of the "channels" that depends on data it needs to get on another "channel". If a network conditions drops enough packets of one of the "channels" to cause your TCP connection to stall (due to TCP window) waiting for response you would in effect be stalling all the other "channels" in the same TCP connection since they share the same window and you can get into a deadlock
This would not have happen before with each channel in the same window.
This may or may not affect your specific application - but it might, so this technique is not transparent. You can try using SCTP to overcome this, if possible
Alright, so I'm writing this program that essentially batch runs other java programs for me (multiple times, varying parameters, parallel executions, etc).
So far the running part works great. Using ProcessBuilder's .start() method (equivalent to the Runtime.exec() I believe), it creates a separate java process and off it goes.
Problem is I would like to be able to pause/stop these processes once they've been started. With simple threads this is generally easy to do, however the external process doesn't seem to have any inbuilt functionality for waiting/sleeping, at least not from an external point of view.
My question(s) is this: Is there a way to pause a java.lang.Process object? If not, does anyone know of any related exec libraries that do contain this ability? Barring all of that, is extending Process a more viable alternative?
My question(s) is this: Is there a way to pause a java.lang.Process object?
As you've probably discovered, there's no support for this in the standard API. Process for instance provides no suspend() / resume() methods.
If not, does anyone know of any related exec libraries that do contain this ability?
On POSIX compliant operating systems such as GNU/Linux or Mac OS you could use another system call (using Runtime.exec, ProcessBuilder or some natively implemented library) to issue a kill command.
Using the kill command you can send signals such as SIGSTOP (to suspend a process) and SIGCONT (to resume it).
(You will need to get hold of the process id of the external program. There are plenty of questions and answers around that answers this.)
You will need to create a system for sending messages between processes. You might do this by:
Sending signals, depending on OS. (As aioobe notes.)
Having one process occasionally check for presence/absence of a file that another process can create/delete. (If the file is being read/written, you will need to use file locking.)
Have your "main" process listen on a port, and when it launches the children it tells them (via a comamnd-line argument) how to "phone home" as they start up. Both programs alternate between doing work and checking for handling messages.
From what you have described (all Java programs in a complex batch environment) I would suggest #3, TCP/IP communication.
While it certainly involves extra work, it also gives you the flexibility to send commands or information of whatever kind you want between different processes.
A Process represents a separate process running on the machine. Java definitely does not allow you to pause them through java.lang.Process. You can forcibly stop them using Process.destroy(). For pausing, you will need the co-operation of the spawned process.
What sorts of processes are these? Did you write them?
I'm trying to develop an application that just before quit has to run a new daemon process to execute the main method of a class.
I require that after the main application quits the daemon process must still be in execution.
It is a Java Stored Procedure running on Oracle DB so I can't use Runtime.exec because I can't locate the java class from the Operating System Shell because it's defined in database structures instead of file system files.
In particular the desired behavior should be that during a remote database session I should be able to
call the first java method that runs the daemon process and quits leaving the daemon process in execution state
and then (having the daemon process up and the session control, because the last call terminated) consequentially
call a method that communicates with the daemon process (that finally quits at the end of the communication)
Is this possible?
Thanks
Update
My exact need is to create and load (reaching the best performances) a big text file into the database supposing that the host doesn't have file transfer services from a Java JDK6 client application connecting to Oracle 11gR1 DB using JDBC-11G oci driver.
I already developed a working solution by calling a procedure that stores into a file the LOB(large database object) given as input, but such a method uses too many intermediate structures that I want to avoid.
So I thought about creating a ServerSocket on the DB with a first call and later connect to it and establish the data transfer with a direct and fast communication.
The problem I encountered comes out because the java procedure that creates the ServerSocket can't quit and leave an executing Thread/Process listening on that Socket and the client, to be sure that the ServerSocket has been created, can't run a separate Thread to handle the rest of the job.
Hope to be clear
I'd be surprised if this was possible. In effect you'd be able to saturate the DB Server machine with an indefinite number of daemon processes.
If such a thing is possible the technique is likely to be Oracle-specific.
Perhaps you could achieve your desired effect using database triggers, or other such event driven Database capabilities.
I'd recommend explaining the exact problem you are trying to solve, why do you need a daemon? My instict is that trying to manage your daemon's life is going to get horribly complex. You may well need to deal with problems such as preventing two instances being launched, unexpected termination of the daemon, taking daemon down when maintenance is needed. This sort of stuff can get really messy.
If, for example, you want to run some Java code every hour then almost certanly there are simpler ways to achieve that effect. Operating systems and databases tend to have nice methods for initiating work at desired times. So having a stored procedure called when you need it is probably a capability already present in your environment. Hence all you need to do is put your desired code in the stored procedure. No need for you to hand craft the shceduling, initiation and management. One quite significant advantage of this approach is that you end up using a tehcnique that other folks in your environment already understand.
Writing the kind of code you're considering is very intersting and great fun, but in commercial environments is often a waste of effort.
Make another jar for your other Main class and within your main application call the jar using the Runtime.getRuntime().exec() method which should run an external program (another JVM) running your other Main class.
The way you start subprocesses in Java is Runtime.exec() (or its more convenient wrapper, ProcessBuilder). If that doesn't work, you're SOL unless you can use native code to implement equivalent functionality (ask another question here to learn how to start subprocesses at the C++ level) but that would be at least as error-prone as using the standard methods.
I'd be startled if an application server like Oracle allowed you access to either the functionality of starting subprocesses or of loading native code; both can cause tremendous mischief so untrusted code is barred from them. Looking over your edit, your best approach is going to be to rethink how you tackle your real problem, e.g., by using NIO to manage the sockets in a more efficient fashion (and try to not create extra files on disk; you'll just have to put in extra elaborate code to clean them up…)