News: Hyperactive JSP acceleration library released
The Hyperactive JSP tag library has been released, in alpha stage. This tag library attempts to speed up JSP response, by using threads to generate blocks of content.
- Posted by: Sethu Raman
- Posted on: July 31 2005 03:21 EDT
With the page being enclosed in a <hyperactive:page/> tag, the <hyperactive:include/> tag processes content in a new thread, without blocking the main JSP thread. Each section's content is collected by the close of the <hyperactive:page/> tag, and included. Therefore, four sections of content, each enclosed with this tag, would conceivably execute in parallel, which might perform better than sequential generation of content.
Note, however, that creation and use of threads inside of a servlet is discouraged without being outright disallowed (see SRV.184.108.40.206, SRV.9.11, and SRV.1.2 in the Servlet 2.4 specification), so some uses may be disallowed at the container level, in particular with some implementations of JNDI. That said, however, the library might be very useful for some situations.
It's been released under the Apache 2.0 license.
The author has also set up a blog for Hyperactive, to collect feedback on the library. What do you think of it?
- Hyperactive JSP acceleration library released by Nebojsa Vasiljevic on August 01 2005 04:15 EDT
- Multithreading in a servlet container by Juergen Hoeller on August 01 2005 05:51 EDT
- Multithreading in a servlet container by Cameron Purdy on August 01 2005 06:21 EDT
- Multithreading in a servlet container by Sethu Raman on August 02 2005 12:48 EDT
- Multithreading in a servlet container by Juergen Hoeller on August 01 2005 05:51 EDT
- Doesnt the spec... by Lyndon Samson on August 01 2005 07:13 EDT
- Creative! by Sethu Raman on August 01 2005 10:11 EDT
- Hyperactive JSP acceleration library released by Corby Page on August 01 2005 10:12 EDT
- Hyperactive JSP acceleration library released by Juozas Baliuka on August 01 2005 11:38 EDT
- Sure you want to add optimization to *this* layer? by Scott McCrory on August 01 2005 12:28 EDT
- It addresses a niche but valuable requirements by Angsuman Chakraborty on August 02 2005 11:30 EDT
- Sure you want to add optimization to *this* layer? by Sethu Raman on August 02 2005 12:41 EDT
- JSP is doing something but presentation? by Serge Libotte on August 03 2005 08:55 EDT
- Hyperactive JSP acceleration library released by krishnaprasad padmanaban on August 03 2005 15:13 EDT
- JSP is doing something but presentation? by Serge Libotte on August 05 2005 10:44 EDT
Do we need multithreading in application code in a standard servlet container?
I think we need it sometimes, both for multithreaded request processing and to launch thread that will continue to run after request processing is finished.
I am considering JMS asynchronous messaging as a regular way to parallelize processing in some my Web applications, but I am trying not to upgrade from Tomcat to a full J2EE server.
A common solution for asynchronous processing in a servlet container is the Quartz scheduler. With Quartz, the application can schedule repeated or one-shot tasks for asynchronous processing, executed under central control by the Quartz Scheduler (which maintains its own thread pool).
Even if the creation of threads is discouraged within a J2EE environment, it is not feasible to adopt complex mechanisms just for some minimal asynchronous processing. Let's stay pragmatic: If you want to open a thread, do so where appropriate, but do so in a controlled manner (with a minimal number of threads opened, reusing threads, etc).
Building on scheduler products such as Quartz is a best practice. You don't need to manually control your threads then, but rather let Quartz handle a thread pool for you. This is a particularly compelling choice for servlet containers, but will also work in any other environment.
Take a look at JSR237 (or drop me an email for more info).
Tangosol Coherence: Clustered Shared Memory for Java
Building on scheduler products such as Quartz is a best practice. You don't need to manually control your threads then, but rather let Quartz handle a thread pool for you. This is a particularly compelling choice for servlet containers, but will also work in any other environment.Juergen
Juergen: Nice point. But in my opinion, what hyperactive is trying to do is completely different from Quartz scheduler. Can you kindly explain for benifit of comunity?
Sethu, I was referring to the general point raised about multithreading in a servlet container, in particular for custom parallel processing (as raised by the first poster in this thread). And after all, both Hyperactive and Quartz are creating extra threads in such an environment.
This threading stuff in the presentation layer is useful when we are pulling information from the persistence layer. When I say pull, I mean when we use jsp custom tag libraries.
But when we use command object to pull all the information from the persistence layer and have the response in the form of java objects. We don't require these threading to optimize the rendering part of it.
It may be an extra overhead in some scenario, but its innovative. Great work.
prohibit threads in servlets. User managed threads could mess up the containers thread handling.
Keeping aside standards, I admire the creativity - good thinking and implementation! Keep up the good work! I had a quick look at the website - looks like the implementation is also non-invasive. Has this been really tested?
Certainly, it is sometimes necessary to use multithreading to respond to user requests.
I just can't imagine that a JSP is ever the correct place to coordinate this sort of behavior.
Therefore, four sections of content, each enclosed with this tag, would conceivably execute in parallel, which might perform better than sequential generation of content.How is it better ? It conflicts with JTA and JAAS thread local stuff too, doe's not it ?
How is it better ? It conflicts with JTA and JAAS thread local stuff too, doe's not it ?
Can you explain: what does it have to do anything with JAAS?
Here's my 5-minute take. Along the layered architecture theme, threading in the Servlet (presentation/controller layer) should only try to address rendering and pathing concurrency/performance issues - it shouldn't try to improve service or data access bottlenecks. The services and DAOs should handle those kinds, because you certainly don't want to tie your optimizations to a single presentation technology.
That said, how many of you have logic in the presentation/controller layer that needs its performance boosted? In my experience, database lookups, SOAP calls and MQ exchanges take far more time than presentation/controller code does.
It's an innovative approach, but it sounds more like a solution looking for a problem to me.
It is very much valuable in special cases where speed is the main concern and yet lots of data churning needs to be done, maybe even IO.
In my experience, database lookups, SOAP calls and MQ exchanges take far more time than presentation/controller code doesScott, if different sections of the page have DB lookup, MQ calls to retreive data, etc hyperactive would be very efficient - it is made for that scenario. Also programatically, it is very non-invasive: all you have to do is replace your jsp:include tag with hyperactive:include.
But your question "Sure you want to add optimization to *this* layer?", is a valid one, and I don't have an answer - but I do think it serves a niche scenario.
I don't get it.
JSP (the view) is just a template where we fills some holes from data already prepared (the model).
It's small work, no?
What am I missing?
I don't get it.JSP (the view) is just a template where we fills some holes from data already prepared (the model).It's small work, no?What am I missing?Serge: Consider a scenario where the page is made of independent sections, one pulling data from DB and other from another source like middleware. One way of implementing this is as you said, fetch, process and assemble all data to be displayed in a servlet and the JSP just displays the data. There are other ways to do it, for e.g. fetch the data to be displayed using a tag library. If you can define your page in terms of independent JSP includes, then hyperactive could be useful. All you need to do is make your "jsp:include" to "hyperactive:include". Now both your sections - DB and middleware related- would be processed in paralell thus eleminating delay involved in sequential processing.
...There are other ways to do it, for e.g. fetch the data to be displayed using a tag library.
I'm involved with an application that gets data from Action classes as well as Tags. I wouldn't mind the Tags so much if they were just gathering application data, but they are not. The Tags are gathering user-specific data. I think this is foolish. Now when the user updates records (updates are done through the Action classes) communication between the Tags and Action classes is required so that the Tag knows to refresh its data.
It makes much more sense to me to access data only from Servlets/Action classes. When I write a Tag it only displays the data that has been attached to the request.
to access data from Tags.
I have some questions for you ,
1. Application servers are designed to alienate its users from doing complex operations like spawning own threads etc. It has its own container managed services so that user can focus only on application logic. What is the justification of spawning so many threads, how would the system behave in a scenario where 100s of parallel users hitting the site and what is the after effect.
Can we see some description on what is the impact of using multiple user threads with respect to your initiative in terms of IO, JVM, CPU etc.
2. What way it overrides application server's container services capability to handle user request, Servlet container has its way of allocating threads to user request which application server vendor implement with their custom implementations too. Does it adhere to latest Sun's Servlet specification. what is the impact and benefit.
In my humble opinion, If we are to innovate/experiment , we should come up with our own application server and/or do our custom implementation services. If we use a J2ee complaint app server of a vendor, we have to use their service and not override anything as we never know the after effect. Companies spend dollars of money to invest on application servers because of its capability to manage system level services(servlet/ejb containers , Transaction managers, persistency, manage threading etc etc), load balancing capability etc and developer without worrying on them, can code only application logic.
I agree with you Sethu but a prefer what Race said, everything is already prepared and JSP just read from beans.
Presentation layer should have clear borders.
This is also why I like the AJAX way... (some borders cleared at client side)
In order to avoid side effect like Krishnaprasad suggest, I rather go to messaging if the legacy is (are) slow.