Yesterday I had a heck of a time trying to figure out my my JSPs weren’t passing validation since I upgraded Ganymede from 3.4.0 to 3.4.1. There was a consistent issue where the JSP Validation did not like my scriptlet code, even when I dumbed it down to try even the simplest scriptlet. The validation errors looked like:

Syntax error on token "}", delete this token
Syntax error on token "catch", Identifier expected
Syntax error, insert "Finally" to complete TryStatement

I actually found out what my problem was through the Eclipse Web Tools usergroup. The issue for me was the use of the Spring form custom tag library. If you self-close the tag…

<form:errors path="*" />

…then you get the goofy JSP validation error. If you close the tag as if there was body content…

<form:errors path="*"></form:errors>

Then the error goes away. I need to follow-up with a bug for the Ganymede team.

Some development teams I work with have been reporting an issue where the JVM runs out of memory during deployment of an application using our standard heap size settings (initial 2 GB and maximum 2 GB). When they changed the initial heap size from 2 GB to 512 MB, the no longer receive the OutOfMemory error. To understand what’s happening, continue on. (more…)

A colleague and I were having trouble tracking down the root cause of a production issue recently and we learned an interesting trick involving the JIT compiler. The issue was that after a certain period of time the JVM would go from 60 second GC intervals to less than 2 second intervals, coupled with a spike in CPU usage from 3% to 30% (light load). There was no correlation found in the application logs, but we could show that the reduction in interval was occurring at the same time as the increase in CPU usage.
(more…)

The Server Side reports that Ounce Labs discovered two vulnerabilities in the Spring Framework’s MVC component.

SpringSource, the company behind Spring, issued a security advisory as a result. The two issues are entitled Data Submission to Non-Editable Fields and ModelView Injection.

Pass along the word to your friends and co-workers.

This guy wrote his own MMO using ASP, JS and MySQL. Pretty cool!

For most of us who can’t afford the time (or expense) of attending technical conferences on even a semi-regular basis, Google was nice enough to post their sessions from the Google I/O conference online. I’ve really enjoyed each session I watched in the APIs & Tools section. There’s a lot about Google App Engine and developing with Python for that environment.

If you have any desire to try out GAE, start with this great introduction to developing on the GAE platform by Guido van Rossum, the creator of Python and current Googler.

I got my pet project up and running, the Boxscore Junkie website. Right now it’s simply a scoreboard, boxscore, play-by-play, and pitch-by-pitch site for the 2008 MLB season, but I am now to the point where I can work on the cool features like tracking pitch data and providing interesting real-time data during live feeds of the games.

Ping me if you have an idea for something to add to any portion of the site. I’m kind of winging it right now as there are many directions I could be taking this.

One of the most common operations in the JSTL framework is the <c:out> tag:

<c:out value="${name}" />

In applications that use this tag heavily, there is a high memory cost when you do not specifying the default attribute. The cost occurs when a NullAttributeException is thrown by the JSTL framework when an attribute is missing while evaluating the tag attributes. The creation and try/catch of the NullAttributeException uses 1,250 bytes of memory per tag instance, all of which can be avoided by simply providing an empty default:

<c:out value="${name}" default="" />

Although 1,250 bytes may seem fairly innocuous, imagine the costs magnified in the example of a multi-row, multi-cell table with potentially hundreds of renderings. Then you’re talking about serious memory churn for your transaction. So if you are using <c:out> tags in a exponential capacity (i.e. nested in a <c:foreach> tag), then be sure to implement a default, even if it is an empty space.

You might ask “But then why don’t I have to implement the escapeXml attribute?”

The answer is because the escapeXml attribute requires a boolean value. The evaluateExpressions() method of the OutTag code does not have to check for null because the when the value is evaluated it is converted to a Boolean object. The Boolean is then evaluated and cannot result in a NullAttributeException.

My colleague Phil gave me a simple but effective breakdown of the difference between these two settings in WebSphere Application Server. Here he describes the shared setting:

Shareable tells the WAS container, when a servlet transport thread closes a connection, don’t actually put that connection back in the pool. Instead, keep it in some local context so that the thread can get access to it when it asks again during the processing of this request. Then finally, when the request is completed, then put the connection back in the pool.

Shareable is an optimization. You would use this for connections which you know will be used many times during processing of a single request. WPS database connections are a good example. We always recommend the number of WPS portal database connections equal the number of web container thread pool size to avoid queuing for portal database connections. I’ve never seen an application database connection that would need to gain from using shareable connections.

The downside of shareable is that if you use it when you don’t need it, you need a larger pool of connections than you would with unshareable connections in order to avoid a connection bottleneck since each thread is holding a connection for a longer period of time.

He goes on to describe the unshared setting:

Unshareable has the opposite behavior. When a thread closes a connection, the thread puts the connection back in the pool.

As an aside if you don’t have a resource-ref defined with shareable/unshareable property and/or don’t use this ref name in the code - you will get shareable by default - with a warning in wps.err/out. In this circumstance your pool size may be causing queuing if the size of the connection pool is less than the size of the thread pool. We suggest to use a resource-ref and set this to unshareable for applications.

JSPs generally use the <jsp:useBean> tag to provide themselves with access to beans in various scopes, such as:

<jsp:useBean id="someResult" scope="session" class="com...SearchResult" />

This tag is particularly expensive when the bean in question does not exist in the referenced scope. In this case the Beans framework goes off looking for a serialized bean on the classpath before eventually instantiating a new object through reflection. For each bean instantiated in this way there is ~100KB of memory cycled.

Optimization options:

1) Use a scriptlet to grab a reference from the request and/or session, check for the presence of the bean, and instantiate manually if required.

2) Always ensure the referenced objects are present in scope. Risky, but if you are a devoted JSTL user, then you must track your references from page to page.