Author Archive
25 February 2009
2 Comments
We did performance tests on several methods of paging implementation and found the fastest one:
DECLARE @PageNumber INT DECLARE @PageSize INT SET @PageNumber = 2 SET @PageSize = 10 SELECT TOP (@PageSize) * FROM ( SELECT ROW_NUMBER() OVER (ORDER BY FieldA) As RowID, FieldB,FieldC, TotalRows=COUNT(*) OVER() FROM TheTable ) TmpTable WHERE TmpTable.RowID > ((@PageNumber-1)*@PageSize)
One significant advantage of this implementation approach is that there is no need for a second query that returns the total count of the paged data. The total record count is returned as a column in the result set. This minimizes the number of queries that are needed to return a paged result set. If not needed, the “TotalRows” column can be removed from the query.
11 February 2009
3 Comments
We started the usual things like upgrading the core components and making more logs that the Tomcat can output. After all these we got rows in the localhost log saying “java.lang.OutOfMemoryError: Java heap space” but with no other information like rows of code, etc. We continued to optimize the memory usage by flushing the input and output streams in the code and others. After that we received this log:
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.OutOfMemoryError: Java heap space
at java.lang.StringCoding$StringDecoder.decode(StringCoding.java:133)
at java.lang.StringCoding.decode(StringCoding.java:173)
at java.lang.String.(String.java:444)
at org.postgresql.core.Encoding.decode(Encoding.java:193)
at org.postgresql.core.Encoding.decode(Encoding.java:205)
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getString(AbstractJdbc2ResultSet.java:1892)
at org.apache.tomcat.dbcp.dbcp.DelegatingResultSet.getString(DelegatingResultSet.java:175)
This was the first time when we had a log where there was a specific row number indicating the error. After looking at the code, we found that the row was in logic, where we assign a field from the database to a string variable. It was nothing unusual, so we decided to check the field in the database table. It was a “text” field in a PostgreSQL database that we access using JDBC driver. After a SELECT length(‘field’) command, we estimated that the biggest field data is about 1 MB! So, if we wanted to take the whole table that would be about 400 MB data fetched in a single click that invoked this method. After that we were able to finally reproduce the server crash, clicking several times on the button that invoked the method fetching this abnormally large amount of data. We had to revise the code so that we take only one field when needed. This solved the crashing issue.
The lesson is that we need to make sure we are not requesting too much data using the SQL statements. Even if we are getting a small amount of columns like in this case, we need to have in mind that one of them could contain a lot of information and make the system crash – especially with lots of concurrent users.
05 February 2009
6 Comments
If you “view source” on the page that Woodstock generates, you will see the following line:
</span><code><script type="text/javascript" src="/app/theme/com/sun/webui/jsf/suntheme4_2-080320/javascript/bootstrap.js"></code><span style="font-family: Georgia,'Times New Roman','Bitstream Charter',Times,serif; font-size: 13px; line-height: 19px;">
Now if you change that line to:
</span><code><script type="text/javascript" src="https://www.yourserver.com:8443/ app/theme/com/sun/webui/jsf/suntheme4_2-080320/javascript/bootstrap.js"></code><span style="font-family: Georgia,'Times New Roman','Bitstream Charter',Times,serif; font-size: 13px; line-height: 19px;">
The site will now work under HTTPS without any security warnings. Obviously, this cannot be done straightforward because this piece of HTML code is generated by the Woodstock library. The solution we have implemented to resolve this problem is to change the code in the Woodstock library that generates the HTML header of the pages. The following solution is not the most elegant solution; it’s more of a simple workaround to solve this problem in production environment:
- Open the Woodstock project web site, https://woodstock.dev.java.net/index.html, and go to “Build it Yourself.”
- Follow the instructions on the “Build it Yourself” page to register and get a CVS access to download the framework source code. The CVS URL will be something like: :pserver:username@cvs.dev.java.net:/cvs. You don’t need NetBeans 5.5, as it is written in the compile instructions.
- Open the CVS repository with NetBeans and check out the module “woodstock/webui” and branch “Release42″ as a new project.
- Open the project and edit the “JavaScriptUtilities.java” file in package com.sun.webui.jsf.util in “src/runtime” folder.
- In method “renderJavaScriptInclude” change line 578 from:
</span><code>String jsFile = getTheme().getPathToJSFile(file);</code><span style="font-family: Georgia,'Times New Roman','Bitstream Charter',Times,serif; font-size: 13px; line-height: 19px;">
To:
</span><code>String jsFile = "https://www.yourserver.com:8443" + getTheme().getPathToJSFile(file);</code><span style="font-family: Georgia,'Times New Roman','Bitstream Charter',Times,serif; font-size: 13px; line-height: 19px;">
- Save the file and rebuild the project. During compile, you might notice a lot of warnings, etc – just ignore them.
- Copy and overwrite the newly compiled webui-jsf.jar and webui-jsf-dt.jar from the Woodstock source code folder “woodstockwebuidist” to the NetBeans subfolder. “visualweb2modulesext”. Keep a copy of the original jar files (see below).
- Rebuild your WAR file and deploy it on the HTTPS server.
There you go. You should now have your website working under IE with no security warnings. Note that the newly compiled .jar files will work only on the server URL you define in Step 5. They won’t work in localhost development environment, so you might want to change with original .jar files during development phase. Cheers.