Could anybody give idea on how to create thread pool without using java built-in api (without Executor Class) and will be better if you could take example of Servlet's and write sample code explaining how multiple request's are handled through code.
Just to inform i'v tried many article on Google but most of them talk either theory or Executor framework.
Thanks
If writing a real application I would strongly recommend using the standard Java classes. These ideas are apparently simple on the surface but the fine details of error handling and efficiency are hard to get right.
The Servlet Engine itself is effectively a thread-dispatcher, so in a Servlet we do not need to consider the processing of multiple requests, our servlet Get or Post method sees one request at a time.
So for your example I would simply use the Executor framework. If your intention is to understand the intricacies of how this could be implemented then I'd suggest looking at the source of the Executor Framwork.
Related
I am developing a project and In this project I need calling multiple concurent web services ( least 5 webservice) asynchrously.
For that , whcih framework can be used Vertx , node , or Play
thanks
In play there is too much working out of the box. Node js will be nice if you can lose some time for writing your own tools.
All of these frameworks can be used.
Disclaimer: I work on the Play framework.
Given Play's Scala heritage, even if you're using Java, we provide Promises so that you can reason the flow of making async calls without suffering from what is known as "callback-hell". You may want to consider using promises for Node also... I believe they are available. I think Vert.x may offer something there too. I'm unsure but I don't believe Node and vert.x provide promises out of the box.
You may find this page useful: http://www.playframework.com/documentation/2.2.x/ScalaWS
Play documentation is not so good. If you are thinking to implement in scala play can be good option, but for java you may not find it so great as few things are not supported in Java (Eg to write a body parser of your own you need to use scala)
Nodejs can be a good choice however, in nodejs utilizing all the cpu cores is hard. There is a framework jxcore which claims to have a solution for this, but, I have not used it.
Vert.X IMO can be a good framework, it makes good use of all cpu cores, provides N event loops. Optionally, you can use worker thread pool if you really need to do cpu intensive operation and be responsive.
You can use vertx with RxJava module ( https://github.com/vert-x/mod-rxvertx ). You can combine your async results in anyway you want. rxvertx module supports wrappers for EventBus, HttpServer, HttpClient, NetServer, NetClient and Timer.
I am working on a server side java application, that converts HL7 messages to Java objects using JavaScript. We chose JavaScript for this, because it was easy to deploy in the production system, without down time.
However, we now have the problem that the 30.000 daily executions of the JavaScript's seems to generate a lot of class garbage in the VM's PermSpace. This results in some unattractive stop-the-world garbage collections.
Do any of you know of a way to avoid generating a lot of class objects, when executing JavaScript?
Any other advice is also welcome.
We are running on an IBM WebSpere 6.1 appserver with java 1.5. The JavaScript engine is SJP-1.0 (Mozilla Rhino).
Regards
Søren
We are creating a web app where we need to have concurrency for a few business cases. This application would be deployed in a tomcat container. I know that creating user defined threads in the web container is a bad idea and am trying to explore options that i have.
Have my multi-threaded library used as a JCA component. We are averse to using this approach because of the learning curve that might be involved.
I know that there's WorkManager API's available but i guess thats not implemented by tomcat so this option goes out.
I did some research and found out that CommonJ library is recommended for Tomcat. Has anyone used it?
Also, I see that there are ManagedExecutorService available but I am not sure how to use it and is it different from WorkManager API's (and the commonJ library)?
Any help on this appreciated. By the way, using JMS is out of question because of deployment environment. I am inclining towards points 3 and 4 but i do not have much knowledge on it. Could someone guide pls.
Since you're using Tomcat, don't worry about it and do whatever you want. The Servlet section of Java EE makes no mention of threads etc. That's mostly under the EJB section.
Tomcat itself doesn't do much at all in terms of worrying about managing threads, it's a pretty non-invasive container.
Its best to tie your threads to a ServletContextListener so that you can pay attention to the application lifecycle, and shutdown your stuff when you app shuts down, but beyond that, don't overly concern yourself about it and use whatever you're happy with.
Addenda -
The simple truth is Tomcat does not care, and it's not that sophisticated. Tomcat has a thread pool for each of the HTTP listeners and that's about the end of its level of management. Tomcat is not going to take threads from a quiet HTTP listener and dedicate them to a busy one, for example. If Tomcat was truly interested in how you create threads, it would prevent you from doing so -- and it doesn't.
That means that thread management outside of the HTTP context falls squarely on your shoulders as an implementor. Java EE exposes these kinds of facilities, and the interfaces make great reads. But the simple truth is that the theoretical capabilities espoused by the Java EE API docs, and the reality of modern implementations is far different, particularly on low end systems such as Tomcat.
Not to disparage Tomcat. Tomcat is a great piece of software. But for most of its use cases, the extra management capability simply is not necessary.
Setting up your own thread pool (using the JDK provided facilities) and working with your own thread lifecycle model will likely see you successfully through whatever project you're working on. It's really not a big deal.
There are a couple of options. Regardless container restrictions that might or might not be in place, spawning individual threads on demand is nearly always a bad idea. It's not that this wouldn't work in a Servlet environment, but the number of threads you can potentially create might get completely out of hand.
The simplest solution to go with is a plain old Java SE thread pool via a normal executer service. Start the pool in a Servlet listener and provide access to it via some static variable. Not overly pretty, but it gets the job done. Depending on your exact use case this might actually be the best solution (if your use case is pretty low-level).
Another option is to add OpenEJB to your war, and then take advantage of the #Asynchronous annotation.
Yet another option, is to realize that one typically uses Tomcat if the business requirements are extremely simple or low-level. That's pretty much the entire point of using something as bare bone a Tomcat. As soon as you find yourself in need of adding (tons of) libraries, you might have outgrown Tomcat and might be better of using a server that already has the functionality you need (in this case asynchronous execution). Examples are TomEE, GlassFish, Resin, JBoss AS, Geronimo, etc.
Every Servlet -Java EE base component for HTTP request processing- in your Web Application is a Singleton, and each request runs in its own independent thread so there is no need to start/stop user generated threads on your own. Your Web Container -in this case Tomcat- manages all that stuff.
Besides that, you need to have in mind some considerations for multi-threaded processing in your code. For example, since Servlets are singletons and many threads are spawned for this class is a bad idea to have instance attributes in this components.
I have used CommonJ many times and it works very well. It can be initialized and destroyed from a ServletContextListener.
I am confused if we should make our own threads in servlet or not,as they have threading mechanism
internally?. If yes how can we make sure if the program thread safe? How to implement thread safe mechanism in servlets.
You are asking two different questions:
I am confused if we should make our own threads in servlet or not,as
they have threading mechanism internally?.
Normally, you should not start threads in a Java EE application. If you need seperate threads, make sure you use a Scheduler Service that your application knows about, so that it has the chance to shut down the threads when the application is shut down. Quartz is what's used most of the time.
If yes how can we make sure if the program thread safe? How to
implement thread safe mechanism in servlets.
Servlets are just like any other Java class. Find a tutorial on thread safety or read Java Concurrency in Practice.
From what you write in the comment, I understand that you have a set of threads continuusly monitoring log-files and sending email if something interresting is found in the log.
First question: why is this a servlet? Is there a web-gui? What is this used for?
For the log-scanning part, I would have implemented that as a separate process outside of the servlet-container. For everything this process found which it needs to send somewhere, I would add a message to a JMS-queue. Then I would create a messagedriven bean to recieve messages from this queue and send them as email. (This is really an integration problem, transforming messages from JMS to email, you might want to look into something like Mule to solve this).
As for how to integrate this with your servlet, it depends on what your servlet does in addition to scanning logs (I suppose it presents the user with some kind of interface)
With this design, you can chose to re-write the programs generating the log in the future. Instead of having one program writing log and another program parsing the log, the first program might as well put the interresting message directly on the JMS-queue. In other words, you can change the log-generation part of your architecture in the future, without having to re-write the mail-sending part.
I also had a similar concern.
Only EJB specification disallows the creation of threads from the application.
It is ok to start a thread from a servlet.
I have done it many times with no problems but to be honest I am not 100% sure:
that this is allowed by container but is violating a standard
or
it is allowed by all containers.
But in Tomcat I never had an issue starting threads from a servlet.
You can make it thread safe the same way you do in every multithreading program.
You will use all the available constructs offered by Java for synchronization.
I am curious about how the following concepts typically execute inside a Java EE container, is one instance created per request, or does one instance serve all requests?
Servlets
Tags
I want to know this because lately i have been using a lot of StringBuffers in my custom tags, avoiding StringBuilder because it is not thread safe. Id like to know for sure how this stuff works so i can write better code
Both are correct. The container may reuse old instances for new requests and even create new instances if more requests are to be served.
Using StringBuilder should be safe as long as its usage does not cross the instances boundaries (by static usage, returning StringBuilders etc.).
So if you're using it whithin a function/method to create your String-output, your're safe to do so.
Some app servers implement thread-pooling, which will execute a certain number of requests per thread, switching load between them as necessary. Simpler engines will spool a thread per request. However, if you never access your StringBuilder from multiple-threads at the same time, you should never have an issue with regards to thread-safety.