if i write the comet push with php but use this code on a java server via quercus, will that solve the one process per request problem that apache had and scale well with lot of users using my chat?
Yes, Quercus solves the one process per request Apache bottleneck. However, you need to understand the possible bottlenecks of the JVM. In my opinion, though, you should write the service or app in C/C++ using something like libevent, in Erlang, in Google Go, or simply as a Java servlet simply for portability's sake.
Well, Quercus runs on the (J)VM so it can run with other code that can start threads. But why do you need threads to do chat? You simply set the timeout on a vanilla PHP request to 0 (no timeout) and wait for there to be something to send back to the user.
That something else will be in response to someone else's request (ie A says "hello" which interrupts B's wait for something to happen). That doesn't require multithreading.
Also you could keep using Apache/PHP and do the above and instead connect to a Java (or other) service via something like XML RPC, which could wait forever. That server could do run multiple threads or do whatever it needs to.
Related
Maybe I'm overthinking this but I'd like some advice. Customers can place an order inside my GWT application and on a secondary computer I want to monitor those submittals inside th eGWT application and flash an alarm every time an order is submitted, provided the user has OK'd this. I cant figure out the best way to do this. Orders are submitted to a mysql database if that makes any difference. Does anyone have a suggestion on what to do or try?
There are two options: 1) polling or 2) pushing which would allow your server (in the servlet handling the GWT request) to notify you (after the order is successfully placed).
In 1) polling, the client (meaning the browser you are using to monitor the app) will periodically call the server to see if there is data waiting. It may be more resource intensive as many calls are made for infrequent data. It may also be slower due to the delay between calls. If only your monitoring client is calling though it wouldn't be so resource intensive.
In 2) pushing, the client will make a request and the request will be held open until there is data. It is less resource intensive and can be faster. Once data is returned, the client sends another request (this is long polling). Alternatively, streaming is an option where the server doesn't sent a complete request and just keeps sending data. This streaming option requires a specific client-/browser-specific implementation though. If it's just you monitoring though, you should know the client and could set it up specifically for that.
See the demo project in GWT Event Service
Here is the documentation (user manual) for it.
Also see GWT Server Push FAQ
There are other ways of doing it other than GWT Event Service of course. Just google "GWT server push" and you'll find comet, DWR, etc., and if you are using Google's App Engine the Channel API
I'm looking for a way to execute "jobs" on a remote server. Normally RMI would do just fine but as far as I know, that requires an actual implementation of the logic on the server. My problem is that I can't predefine the jobs on the server because I want them to be as generic as possible.
So what I have in mind is the following: the client has the implementation of a specific job he wants to have executed. This implementation would obviously have to follow a set of rules in order for the server to be able to work with it. The client packs it into an object of some kind, sends it to the server for execution, and waits for the result of whatever computation he asked for.
Is this possible with RMI? If not, is there something else that allows me to work this way?
Thank you for your time and insight.
You can use Dynamic code downloading using Java RMI but you will have to setup a server to holds clients task classes
As I unterstand your question the server does not 'know' the code to be executed in advance.
So what you could try is sending some runtime-interpretable code like groovy, javascript or python and use one of the many interpreters out there on the serverside.
For simpler executions UEL and the concrete JUEL might be worth a look
Any object that is serializable can be passed over RMI. You could wrap the logic in a serializable object, pass that to the server, and the server executes it (it could have an execute method for example that the server calls).
As mentioned in the comments here, the class you pass from the client to the server would need to be known to both the client and the server.
I have a shell script which I'd like to trigger from a J2EE web app.
The script does lots of things - processing, FTPing, etc - it's a legacy thing.
It takes a long time to run.
I'm wondering what is the best approach to this. I want a user to be able to click on a link, trigger the script, and display a message to the user saying that the script has started. I'd like the HTTP request/response cycle to be instantaneous, irrespective of the fact that my script takes a long time to run.
I can think of three options:
Spawn a new thread during the processing of the user's click. However, I don't think this is compliant with the J2EE spec.
Send some output down the HTTP response stream and commit it before triggering the script. This gives the illusion that the HTTP request/response cycle has finished, but actually the thread processing the request is still sat there waiting for the shell script to finish. So I've basically hijacked the containers HTTP processing thread for my own purpose.
Create a wrapper script which starts my main script in the background. This would let the request/response cycle to finish normally in the container.
All the above would be using a servlet and Runtime.getRuntime().exec().
This is running on Solaris using Oracle's OC4J app server, on Java 1.4.2.
Please does anyone have any opinions on which is the least hacky solution and why?
Or does anyone have a better approach? We've got Quartz available, but we don't want to have to reimplement the shell script as a Java process.
Thanks.
You mentioned Quartz so let's go for an option #4 (which is IMO the best of course):
Use Quartz Scheduler and a org.quartz.jobs.NativeJob
PS: The biggest problem may be to find documentation and this is the best source I've been able to find: How to use NativeJob?
I'd go with option 3, especially if you don't actually need to know when the script finishes (or have some other way of finding out other than waiting for the process to end).
Option 1 wastes a thread that's just going to be sitting around waiting for the script to finish. Option 2 seems like a bad idea. I wouldn't hijack servlet container threads.
Is it necessary for your application to evaluate output from the script you are starting, or is this a simple fire-and-forget job? If it's not required, you can 'abuse' the fact that Runtime.getRuntime().exec() will return immediately with the process continuing to run in the background. If you actually wanted to wait for the script/process to finish, you would have to invoke waitFor() on the Process object returned by exec().
If the process you are starting writes anything to stdout or stderr, be sure to redirect these to either log files or /dev/null, otherwise the process will block after a while, since stdout and stderr are available as InputStreams with limited buffering capabilites through the Process object.
My approach to this would probably be something like the following:
Set up an ExecutorService within the servlet to perform the actual execution.
Create an implementation of Callable with an appropriate return type, that wraps the actual script execution (using Runtime.exec()) to translate Java input variables to shell script arguments, and the script output to an appropriate Java object.
When a request comes in, create an appropriate Callable object, submit it to the executor service and put the resulting Future somewhere persistent (e.g. user's session, or UID-keyed map returning the key to the user for later lookups, depending on requirements). Then immediately send an HTTP response to the user implying that the script was started OK (including the lookup key if required).
Add some mechanism for the user to poll the progress of their task, returning either a "still running" response, a "failed" response or a "succeeded + result" response depending on the state of the Future that you just looked up.
It's a bit handwavy but depending on how your webapp is structured you can probably fit these general components in somewhere.
If your HTTP response / the user does not need to see the output of the script, or be aware of when the script completes, then your best option is to launch the thread in some sort of wrapper script as you mention so that it can run outside of the servlet container environment as a whole. This means you can absolve yourself from needing to manage threads within the container, or hijacking a thread as you mention, etc.
Only if the user needs to be informed of when the script completes and/or monitor the script's output would I consider options 1 or 2.
For the second option, you can use a servlet, and after you've responded to the HTTP request, you can use java.lang.Runtime.exec() to execute your script. I'd also recommend that you look here : http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html
... for some of the problems and pitfalls of using it.
The most robust solution for asynchronous backend processes is using a message queue IMO. Recently I implemented this using a Spring-embedded ActiveMQ broker, and rigging up a producing and consuming bean. When a job needs to be started, my code calls the producer which puts a message on the queue. The consumer is subscribed to the queue and get kicked into action by the message in a separate thread. This approach neatly separates the UI from the queueing mechanism (via the producer), and from the asynchronous process (handled by the consumer).
Note this was a Java 5, Spring-configured environment running on a Tomcat server on developer machines, and deployed to Weblogic on the test/production machines.
Your problem stems from the fact that you are trying to go against the 'single response per request' model in J2EE, and have the end-user's page dynamically update as the backend task executes.
Unless you want to go down the introducing an Ajax-based solution, you will have to force the rendered page on the user's browser to 'poll' the server for information periodically, until the back-end task completes.
This can be achieved by:
When the J2EE container receives the request, spawn a thread which takes a reference to the session object (which will be used to write the output of your script)
Initialize the response servlet to write an html page which will contain a Javascript function to reload the page from the server at regular intervals (every 10 seconds or so).
On each request, poll the session object to display the output stored by the spawned thread in step 1
[clean-up logic can be added to delete the stored content from the session once the thread completes if needed, also you can set any additional flags in the session for mark state transitions of the execution of your script]
This is one way to achieve what you want - it isn't the most elegant of all approaches, but it is essentially due to needing to asynchronously update your page content from the server , with a request/response model.
There are other ways to achieve this, but it really depends on how inflexible your constraints are. I have heard of Direct Web Remoting (although I haven't played with it yet), might be worth taking a look at Developing Applications using Reverse-Ajax
We have a php setup for our web pages that is secure with HTTPS. The web app talks to a DB but we also want it to talk to a java server we have.
The java server is a standalone java application (not web). We simply want a callback action after the PHP page finished writing to the DB done in the java server. What is a good way for this php page to talk to the java program to get something done?
I usually recommend against quick and dirty but here :
You can dump data in a file if it can be asynchronous. Then a cron job from java, checking for that kind of file at a regular interval, do the specified command.
For example, you can dump the word ExecuteCmd1 in a file. The java thread reads it, interprets it and choose that he must execute the method or class with the same name.
You can do the same thing over to go back to php.
Probably via a TCP/IP connection. If your Java application runs a server, then the PHP script can connect and send a message informing the Java app that the DB has been written to.
Do a quick and dirty JSON RPC from PHP to Java. You could probably get it up and running in one cup of coffee.
Use CURL on php (http://php.net/curl) and json_encode() to POST a json string to your Java server. (scroll down and find the curl wrapper class that someone wrote in the comments. It's easy.)
Use JSON (http://www.json.org/java/) in Java to decode it and use it immediately. Send your response back in JSON too.
I had a similar XML RPC system running in production for years. PHP -> IP -> Java works great.
Google Protocol Buffers Not so much dirty, but works, and works well, regardless of which launguage you use.
You can try the PHP/Java bridge. I used it a while ago to use Java logic inside Typo3, a PHP CMS.
My advice, whether you use the bridge or not: make sure you know where the errors come from if something doesn't work. Check both PHP and Java logs. Be verbose if an exception occurs.
How much data do you need to transfer?
How many requests per second?
Does the Java application have to handle the request immediately, or is it enough to handle the request in a few minutes?
Does the Java application need to return data to the user's browser?
If the answers to questions 3 and 4 are no and no, you could just create a database table for the jobs, have the PHP app insert a new job, and have the Java app poll the job table every minute or so.
We have a string processing service (c++, uses stdin/out for in/output) that has different layouts, each layout runs separately (eventually will run on separate machines), each layout takes time to load, thats why it must keep running after first run.
I must implement a system with client that will ask the master server to connect it to a relevant slave server which actually runs the relevant layout service. The slave server will communicate the data passed from the client to the service, and when finished will become available on the master server for other clients.
The question is what is the best way to go about implementing the servers? Should I keep an open connection between slave/master until the process is complete to notify the master that the connection is over or keep some sort of var in a synchronized function to check that?
Any other important inputs (or other designs) I have overlooked are also very welcomed, Thanx!
Assuming you can't replace the C++ stuff, here is how I would do it off the top of my head.
I would setup one master server. That server would run a process that accepts requests (probably by HTTP, so it'd be a webservice) and I would have it read the request, parse out what it is, and then call the correct slave. Basically it acts as a proxy. Once it receives the response from the slave it forwards it back to the caller. The simplicity here means that if you start getting more of one type of request, you can set up additional servers for that and round-robin requests to them.
The slaves would be webservices that open the C++ program and forward input and retrieve output. That's all it would do.
I wouldn't bother keeping open connections (except between the slave and the C++ program based on your description). Just using a web request for this stuff will keep the connection between the master and the slave open during the process, but it shouldn't be a problem. This way you don't need to worry about this detail.
Now if I were you I would seriously look at reimplementing the C++ code in Java or calling it via JNI or something. If you can avoid it, I think avoiding the Java wrapper around C++ thing would be a good design goal. The Java could do whatever expensive process it is during start up once, and then hold things ready in memory like the C++ code does.
I hope this helps.
Depending on your scalability needs, you may want to take a look at the Java NIO package. This will give you a starting point to build a scalable, non-blocking server implementation.