spring:bind causing performance issue

[abhiraj]

There is a JSP which has 100 spring:bind and the page takes 3 minutes to load on websphere 6.0. If i remove the spring bind and replace with equivalent scriplets the page is loaded in 5 Seconds. Both these timing are first time load. Can something be done for improving this with spring bind or is scriplet the only solution.
Thanks in advance,
- abhiraj

[Marten Deinum]

If you want to bind and get feedback with error messages etc. yuo will need the spring bind tags or form tags.

We did however notice a performance issue when we had PropertyEditors on collections and also with PropertyEditors which where quering the database. Do you have those property editors?

[RobertGloverJr]

I have spent that past four days tracking down why a very large Spring JSP was unable to compile. Even letting it compile overnight was to no avail.
The solution turned out to be to use jsp:forward statements to break up the 2,200 line jsp into chunks with an average size of about 240 lines. Even that didn't completely work because one of the "chunks" was in turn using jsp:forward to an 850 line jsp. When I also broke that jsp into chunks, at last the jsp compiled in about twenty seconds, which is fine because once it compiles it's very quick.
The problem in my case only appeared when I converted a Spring web application from IBM WSADS 5.12 and Websphere 5.1, to IBM RAD7 and Websphere 6.1. I also upgraded Spring from 1.2.8 to 2.0.5, upgraded JSP from 1.2 to 2.0, and upgraded Servlet 2.3 to 2.4, but those changes had nothing to do with solving or causing the problem. The problem (I think) was IBM Rational Applications Developer 7 and Websphere 6.1 not being able to compile a large JSP that has a lot of Spring tags in it.
Now that I know about this, it's easy to work around it by using jsp:include to break up a large JSP that has a lot of Spring tags in it. Here's the chunkified jsp:

<%@ taglib prefix="spring" uri="/WEB-INF/spring.tld" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>

<jsp:include page="/WEB-INF/jsp/ChunkerNetworkTelForm/chunk01_networkTelForm.jsp" flush="true" />
<jsp:include page="/WEB-INF/jsp/ChunkerNetworkTelForm/chunk02_networkTelForm.jsp" flush="true" />
<jsp:include page="/WEB-INF/jsp/ChunkerNetworkTelForm/chunk03_networkTelForm.jsp" flush="true" />
<jsp:include page="/WEB-INF/jsp/ChunkerNetworkTelForm/chunk04_networkTelForm.jsp" flush="true" />
<jsp:include page="/WEB-INF/jsp/ChunkerNetworkTelForm/chunk04_networkTelForm.jsp" flush="true" />

[Paul Newport]

I have spent that past four days tracking down why a very large Spring JSP was unable to compile. Even letting it compile overnight was to no avail.
The problem in my case only appeared when I converted a Spring web application from IBM WSADS 5.12 and Websphere 5.1, to IBM RAD7 and Websphere 6.1.

The problem seems to be RAD 7 specific as our app with large jsps and many spring tags in works fine under a development environment of RAD 6 (WAS 6.0) and a live environment of WAS 6.1.

It seems that the internal WAS server shipped with RAD 7 has serious problems compiling some large JSPs. On a very fast multi-core PC with 4 gigs of RAM some JSPs are taking hours and hours to compile, and some are never compiling (well within a reasonable timeframe that I am prepared to wait over).

I am going to try upgrading to RAD fix pack 1.0.0.4 and see what happens.

[Paul Newport]

PS this is a question for the Interface 21 guys really - what is it in the Spring taglibs (specifically nestedPaths and form input tags) that could be troubling the RAD 7/WAS 6.1 jsp compiler ?

Large JSPs without these tags seem to be fine.

[Paul Newport]

An update - you still get the problem with Spring 2.07, and RAD 7 completely patched to the latest levels (Fix pack 1.0.4, and the interim fix on top of there).

This is a SERIOUS problem - it means RAD 7 developers cannot develop any Spring applications that use large JSPs with Spring tags in them. That is going to knock out a large section of Spring development as it stands.

Is there any debug code with in the tag libs that can be turned on to see what is happening when you try and run these JSPs ?

Does anyone who supports the codebase have contacts with IBM to resolve this ?

[RobertGloverJr]

The corporation I am consulting at has a support contract with IBM. An employee I work with can call IBM using the corporation's support ID to report this problem if I ask him to. However our experience in the past with reporting RAD 7 problems is that an IBM support person will simply respond that they have no information about it in their database.
With that caveat, I will (when the weekend ends) email this thread to that employee and ask him to contact IBM support and forward the thread to them.
By the way, I will be flying to Hollywood, Florida to attend the Spring Conference Dec 12 through Dec 15. Since Spring Framework on Websphere is an IBM certified platform, it seems likely there will be someone from IBM at that conference who could be spoken to directly by a more senior Spring member.

[Paul Newport]

Ta

December is too late for us unfortunately. Strange thing is, our app works fine if compiled under Java 1.4 with RAD 6 and then deployed to WAS 6.1, it just does not work if compiled within RAD 7 and deployed to the local WAS 6.1 test environment. I don't understand this, as in both cases it is a WAS 6.1 JDK 1.5 environment compiling the JSPs.

By the way I put a break point on the offending JSP's first breakable line, and it never got there, so it seems that the JSP compile is going into some sort of loop, with one of my PC's core's maxed out on CPU, which also has the consequence of making the local WAS 6.1 server completely unresponsive.

[Paul Newport]

It turns out that despite being ont he latest fix packs for RAD 7, the integrated version of WAS is way down on the current level. For instance, our production servers are on 6.1.0.7 but RAD has version 6.1.0.2. There is a similar discrepancy in JDK levels.

Hopefully there is a separate fix pack that will bump the levels up to that of a normal WAS 6.1 server.

[Paul Newport]

OK, it all works if you patch WAS and the WAS JDK to the latest fix pack levels - the trouble is you can patch RAD as much as you want but it does not patch the shipped version of WAS that it comes with.