I'm working on porting a desktop application (WinForm) to a web application (Java/Spring/JPA). The problems are many and I'm struggling a bit...
Now the problem is threading!
In the original application, that performs the export of certain data from the DB, there is a progress-bar indicating the progress of the process.
I want to port this progress-bar in the new web application. To do this I thought of using AJAX and use a separate thread to run the data export.
The main concerns are:
Am I following the right approach? Are there problems using multi-threading in web applications?
If during the export process F5 or refresh button are pressed what exactly happens? How can I stop the process?
How do I update the progress bar periodically? Do I have to make calls via ajax to the server?
I'm primarily an ASP.Net developer but from what I know of the HTTP protocol this just isn't the way to go about it. I've seen a lot of fairly clever solutions for this but in the end what becomes clear is that the HTTP protocol simply isn't designed to work like this.
Obviously you're aware that a flash or silverlight app would be able to do this but that comes with it's own set of issues.
Myself I prefer to keep all the weirdness on the server. In the past I've had to come up with a way to deliver several thousand emails through a web application and update the user on how it's coming along. I designed a set of tables to act as a queue. The web application would simply place any delivery requests in this queue and the progress bar would be determined by a request that checks the status of the items in the queue. Running in the background was a windows service which would also check this queue and was actually responsible for delivering the mail and setting the status of each item as it completed or failed.
It was a bit difficult to develop since windows services can be tricky but once it was up and running it was extremely smooth and reliable. Depending on your circumstances perhaps a simple scheduled task set to run every few minutes would do the trick for you.
I wouldn't necessarily jump straight to running a separate thread explicitly for the export. While it would be ideal to do this, the capability of the web container to do this is going to be a limiting factor. Your traditional Java EE app server generally discourages spawning threads for this (though you can hook up to a thread pool for this). Some containers are great at freeing up the threads from blocking until the work is done (Karaf with Jetty and Camel, for instance) so that they can service other web requests while the export is occurring. But my guess is that you're probably okay with the "start export" thread blocking until it receives a response.
How long does this export take? A couple of seconds, or are we talking closer to minutes here? If it's shorter, I'd think that just putting a little "Waiting" icon with the little circular spinner on it (using your favorite Ajax library, whatever that is) would be sufficient.
If you really want a true status bar that periodically refreshes itself, then yes you'd have to poll for it at some frequency. Presumably that could be a simple request that would load some kind of progress for the job from a database table for that job ID.
Find my answers Inline
I am following the right approach? Are there problem in using multi-threading in web applications?
-Yes you are on correct path. No there is no such problem in multi-threading in web application and its as easy as you do it in WinForm. Instead of using Dispatcher to update the UI, you would be making AJAX calls and with javascript DOM manipulation would take place.
If during the export process F5 or refresh button are pressed what exactly happens? How an I stop the process?
-Unfortunately there is no easy way. The standard way is, when such kind of processing is done and the user hits F5, you would show a dialog(with help of javascript) and inform user that the job is still running. If the user still wants to refresh then you have make another request to the server for cancelling the task.(You need to store thread id or cancellation token some where to cancel the task)
How do I update the progress bar periodically? Do I have to make calls via ajax to the server?
-The standard way is, generally you show show a loading image. IF you want to show a context senstive progress bar, it would mean you have to do polling. Here is an example by Dino Espito. Though its in ASP.NET, you could understand the underlying principle
Dino Espito
Related
Today I'm using an applet to modify client-side information, considering the new browsers i have to found out a new workaround to continue modifying file and execute windows command at client-side because some browser are suspending the applet execution.
Any ideia for solution that has allow windows command execution and access file at client side like Activex ?
Applets have always been sitting between webapps and desktop apps. In that sense, what you want to achieve is exactly what every hacker in the world wants to achieve, that is gain access to your computer from a browser. And I think it would fair to say that for that reason, applets are dying and are not coming back from the dead anytime soon.
But unfortunatly some functionalities need applets to run, and what you can do really depends on those functionalities.
Statu-quo
They are still working in IE (not Edge), Firefox and Safari. If you control your clients environment you can maybe still use them as is. But for how long ?
Move to Server
You move your functionalities on the server. In your case, it would probably mean upload files on the server, execute your commands there and send the file back on the client. Javascript and HTML 5 can certainly help here improve the overall user experience.
Move to Desktop
If you are doing some pretty intensive stuff on the client (processing multiple files, accessing resources that cannot be used from a browser, etc), you should consider regrouping this into a desktop app. You can even launch your app from a browser and sends some parameters to it by registering a Custom Protocol Handler, a la iTunes. Again, this is certainly not an easy replacement, as functionalities will often be spread out between the desktop app and the web app, which makes for some interesting scratch head moments trying to link the 2.
We have a a Java app that takes a few registers off a database and sends them back and forth to a web service, nothing too complicated. This java app has a GUI that informs the user about what's going on with the operations it performs, as well as providing means for configuring certain aspects of its execution and giving the user the opportunity to deal with errors that may happen.
The thing is, this application needs to run all the time, even if the user isn't logged on. I tried setting a windows task to make it run when the computer starts, but if that happens the program runs on the background and the interface never comes up.
We could break the interface away from the main project and make them run separately, so the service runs on the background quietly and the user is free to open and close the interface to their heart's content, but unfortunately we suffer from coupling problems in our project which makes that road a little more arduous than it should be.
So the question is: Is there a way to set a service up so that it runs even when the user isn't logged in, but once he does, the interface also comes up?
Our only target platform is, for now, Windows.
to your question : "Is there a way to set a service up so that it runs even when the user isn't logged in, but once he does, the interface also comes up?" the response is Yes and called JavaExe.
look its examples in JavaExe.zip, in particular example8 or 23
Only separation of UI is an answer here. Downgrading to XP doesn't make sense. You can also simply build that as a webapp and try to leverage esbeetle.com for interfaceing and doing all the logic.
I have a requirement to update my view while my GWT application doing GWT RPC. Here is my case, I have to send some data to my GWT servlet, then in my servlet, I feed it to a server side component (optaplanner solver), and it will run for some time. This component have a event handler for every un-final result released. Now what I want is to get those un-final result and populate it in my view until the final result was released from the optaplanner solver component. These requirement very similar to upload file and track the progress. Please kindly give me your suggestions how to achieve this.
Thanks & Regards.
You have two options:
Start a timer in your GWT code which will periodically ask the server "Do you have something for me?" The server may respond with null or with the intermediate results that you can show to your user.
Use a server-push technology.
The timer option is much simpler - it requires only a few lines of code and no external libraries. It is also a standard solution when the timing of an event is not critical (unlike games and some other applications).
I'm currently adapting a desktop swing application for the web.
I'm migrating the front end to an Angular.js app, and leaving the majority of the back end business logic as is (the goal is to be minimally invasive and keep things working for our first iteration). I will interact with the back end service primarily through REST calls. In theory, this should work.
However, I have one little hiccup. The application in its current form relies on numerous prompts to the user before continuing or adjusting the processing of its task. These being done through a desktop swing app, are handled through synchronous alerts (all isolated in a single class, thankfully), the resulting response affecting the application flow.
For example, something like parsing field strings to numbers might be handled through an alert:
if (Alert.convertStringsToNumbers()) { // blocking call. Response is boolean value
// continue processing
} else {
// abort
}
In order to keep the web-app version performant, and without resorting to long-polling, the idea is to swap out the synchronous alerts with websocket communications. However, with sockets being asynchronous, I'm not sure how to pause processing of the task until the user responds to the dialog.
Note, I've spent my last 5 years doing primarily JS work, so I'm assuming there's some extremely simple way I can do this which I'm just not familiar with in Java.
If it helps, I'll be using Tomcat 7 with their catalina implementation of websockets, rather than the standard Java EE 7 version (finally supported in Tomcat 8).
Is it something as simple as wrapping an alert in a runnable, and waiting for a response before returning control to the rest of the application? Or is something more complex required?
Update Per the comment below, and to clarify:
The point of the exercise is to push the majority of the app to the server as a service. The front end will be entirely browser based, using Angular.js. To get this version out the door quickly, I want to make the minimally invasive changes to the synchronous api to allow for wrapped, asynchronous communications over websockets.
I'm looking for a elegant way to create a queue for serving up batch compiled applets.
I have hacked together a SQL and PHP script to handle this but it chokes under mild loads.
is there an existing system that can handle taking a list in SQL and serve the applets in descending order each time it is requested. I'm also trying to handle this all server side as well.
The trick would be getting file001, then file002 ++ ect. to get served each time a web page is loaded. I'm batch creating applets that has a slightly modified background and I'm trying to serve a never been used applet waiting in the queue to load each time the a page is requested.
Is there a applet server I can tweak or does look like something that needs to be built?
No, I have never heard of a "batch compile applet server".
Could you maybe explain in more detail why you feel this is necessary?
Why don't you just use the same class and pass parameters to it?
That said, you can do compilation on demand quite well with e.g. ant and / or CruiseControl. You could put the pre-compiled applets into a directory. Then your PHP frontend just needs to keep track of what applet it delivered last, and fetch the next one the next time.
Still, this sounds rather complicated to me; so maybe you could explain your motivation.
In particular, why do you want a new applet on every reload? Would that not be rather confusing? Why not offer a link for each variant, so the user can choose?