Cameron Dalton

Good morning, everyone. I'm working with Struts 1.1, and I'd like to get 2 error message sections on a single page. To give you an idea of what I mean: I'd like one section above the form for adding a record (which might have validation errors for the form, or save errors, etc), and then another error message section underneath that but above a list of existing records (which might have errors or warnings that occurred while retrieving the records). Is this possible? From what I've seen so far, I can only figure out how to add errors to one error store, and then they're all displayed in the same place.

Thanks for your help.

Thanks for your response, Javid. Here's the interesting parts of my hibernate.cfg.xml:

<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"> <hibernate-configuration> <session-factory> <property name="hibernate.bytecode.use_reflection_optimizer">false</property> <property name="hibernate.connection.driver_class">com.ibm.db2.jcc.DB2Driver</property> <property name="hibernate.connection.password">xxxx</property> <property name="hibernate.connection.url">jdbc:db2://x.x.x.x:50000/energy1</property> <property name="hibernate.connection.username">xxxx</property> <property name="hibernate.current_session_context_class">thread</property> <property name="hibernate.dialect">org.hibernate.dialect.DB2Dialect</property> <mapping resource="a/b/c/Thing.hbm.xml" /> ...

This is not running in a J2EE container as it's a standalone Java app, so I didn't think I could use a datasource. Maybe I'm wrong though...

We have a long running stand-alone application which listens on a JMS queue for messages telling it to run. When a message comes in, a Hibernate session is opened, queries are performed, and then the session is closed using Session.close(). There is no transaction management because no writes are being performed.

Now I was under the impression that Session.close() closes the underlying JDBC connection with the database. However, something seems to remain open or aware of the database server because if the database is restarted before the next JMS message comes in, there is a SocketException thrown (with messages like "connection reset by peer", "socket write error", etc). The open session does not throw the exception; it is thrown by the first query.

What do I need to do to completely close the connection so that when a JMS message is received a brand new connection is made from scratch?

Thanks for your help with this problem.

I don't HAVE to use IBM's version (although IBM says I do), but the JAR downloads increase if I don't. When I tried that a couple days ago, it couldn't find some IBM classes that aren't bundled in the JARs I mentioned. I thought that when I have more time I'd do a jar search to find out which JAR contains these extra classes, add them to the JNLP, and then try it on Sun's 1.6. I once upon a time tried it on Sun's 1.5 and had the same memory footprint (although I'm not sure about the console thing since I didn't know about it back then to check).

When I do give that a shot I'll let you know what happened, since you're curious.

Yep, just the standard console that you can turn on and off from the Java Control Panel. It does seem that it's related to the JARs but I don't get how the console is related. Version is 1.5.0, but it's from IBM so who knows...

Anyway, thanks for your help. I imagine I'll give up on this now and head down a different path to reduce memory footprint.

Thanks for your response, Martijn. The application is a single JMS consumer. I understand that requires extra threading in the background, but I'm not sure why that would involve lots of memory usage. No data is loaded (other than small JMS messages), and logging is very minimal. The one thing that is exceptional is the amount of JARs downloaded by JWS and added to the classpath. This application loads IBM's app client JAR collection, which contains 60 JAR files in a total of 68.5MB. I wouldn't think JWS-loaded JAR files would be maintained in memory until a class is actually loaded by the class loader, but I guess you never know. But even still, why would the memory usage drop so significantly after something so unrelated as minimizing the Java Console?

Hello. I wrote an application which is currently invoked using Java Web Start. I'm not posting in that forum because I'm not sure this issue is related to JWS.

When looking at the Windows Task Manager, I can see that as my application starts up the memory usage quickly ramps up to around 130,000K. When I have the Java Console set to display, and I minimize the console, memory usage drops to around 4,000K. Restoring the console bumps memory usage up to around 12,000K.

If I run my application with Java set to NOT show the Java Console, memory usage is still around 130,000K after application startup.

I have a couple questions here. First, if minimizing the console cuts memory usage down to 4,000K, why doesn't my application have such low memory usage when the console is not displayed at all? Second, is there any way I can reduce the memory footprint without having to minimize the console? This application is supposed to run indefinitely and without human interaction on system startup, and shouldn't require a user to minimize the console. Does anyone have any ideas on these questions?

Thank you.

Balu, that's a great idea. I did that and was able to lookup the value, which means the web.xml change was picked up. I'm not sure what's going on here. But I'm plugging away and will hopefully make some progress soon. Any more ideas are certainly welcome!

Thanks.

The server seems to restart normally and I didn't notice any warning or error messages in the log. But you're right to wonder about that; I have occasionally had problems with applications not recognizing an update to the web.xml file but recognizing other file updates. Hmm...

I understand that welcomeMessage is null and that I haven't instantiated it. As I understand it, I shouldn't have to instantiate it because the @Resource annotation is supposed to locate the env-entry block in web.xml and inject the env-value into welcomeMessage. There are examples of this on Sun's site: http://java.sun.com/developer/technicalArticles/J2EE/injection/index.html under the heading "A Simple Servlet". I believe my code matches the example.

However this is not working as I'd expect it too. The idea is that I don't have to instantiate the object and it will be instantiated for me. This way I can use environment-specific properties (support email addresses, WSDLs, etc) without headache. I hope this clears up the situation.

Also, I know that the toString() is superfluous; I added it so that I'd get the stack trace you asked for.

Thanks for your response. I did throw it into a package, thanks for the reprimand. Laziness due to this being just a test project, but you're right.

Anyway, I changed the servlet so it would throw a NullPointerException instead of just printing null. Here's the new servlet code:

package test; import java.io.IOException; import javax.annotation.Resource; import javax.servlet.ServletException; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public class PrintResourceServlet extends javax.servlet.http.HttpServlet implements javax.servlet.Servlet { @Resource private String welcomeMessage; public PrintResourceServlet() { super(); } protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.getWriter().print("message: " + welcomeMessage.toString()); response.getWriter().flush(); } }

And here's the stack trace. It's pretty much what you'd expect.

[1/9/09 10:05:42:012 EST] 00000054 ServletWrappe E SRVE0068E: Uncaught exception thrown in one of the service methods of the servlet: PrintResourceServlet. Exception thrown : java.lang.NullPointerException at test.PrintResourceServlet.doGet(PrintResourceServlet.java:21) at javax.servlet.http.HttpServlet.service(HttpServlet.java:743) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1081) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:550) at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478) at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3391) at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:267) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:811) at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1455) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:115) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:458) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:387) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:267) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161) at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136) at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:195) at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:743) at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:873) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1473) [1/9/09 10:05:42:012 EST] 00000054 LocalTranCoor E WLTC0017E: Resources rolled back due to setRollbackOnly() being called. [1/9/09 10:05:42:012 EST] 00000054 WebApp E [Servlet Error]-[PrintResourceServlet]: java.lang.NullPointerException at test.PrintResourceServlet.doGet(PrintResourceServlet.java:21) at javax.servlet.http.HttpServlet.service(HttpServlet.java:743) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1081) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:550) at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478) at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3391) at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:267) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:811) at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1455) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:115) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:458) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:387) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:267) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161) at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136) at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:195) at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:743) at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:873) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1473)

I have an env-entry defined in my web.xml and when I attempt to print it from a simple servlet all I get is null. And of course if I attempt to invoke any methods on the object I get a NullPointerException.

I read somewhere that this can happen if you're using version 2.4 instead of 2.5, so I changed to 2.5 and I still have the same issue. Here's the web.xml:

<?xml version="1.0" encoding="UTF-8"?> <web-app id="WebApp_ID" version="2.5" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd"> <display-name>ResourceTest</display-name> <servlet> <description></description> <display-name>PrintResourceServlet</display-name> <servlet-name>PrintResourceServlet</servlet-name> <servlet-class>PrintResourceServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>PrintResourceServlet</servlet-name> <url-pattern>/PrintResource</url-pattern> </servlet-mapping> <env-entry> <env-entry-name>welcomeMessage</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>hello</env-entry-value> </env-entry> </web-app>

And here's the servlet. Displaying this env-entry is all it does:

import java.io.IOException; import javax.annotation.Resource; import javax.servlet.ServletException; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public class PrintResourceServlet extends javax.servlet.http.HttpServlet implements javax.servlet.Servlet { @Resource private String welcomeMessage; public PrintResourceServlet() { super(); } protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.getWriter().print("message: " + welcomeMessage); response.getWriter().flush(); } }

Thanks for your help.

I find myself writing a method that requires multiple synchronized() blocks within the method. I'm looking for some opinions here. Is it better to:

- synchronize the entire method (to have fewer synchronizations), or
- synchronize many times within the method (to have less code synchronized and reduce the scope of synchronization)

I believe performance will be better with just the single synchronization due to overhead involved with acquiring the lock, like flushing the memory cache. But it is also best practice to keep the scope of synchronization as small as possible to help guard against deadlock. I think I'm leaning one way more than the other, but what do you all think?

Thanks for your input.

I discovered a solution using wait() and notifyAll() that I overlooked originally.

Originally posted by Martijn Verburg:
Can I ask why you're staying away from JMS? It's designed to do exactly this

I'm hoping to avoid all the overhead of JMS connections and all the extra threading that goes along with them. This will only take place on a single server, not across multiple servers.