anonymous wrote : | Enabling the Tracing would overwhelm us, in a test machine for a simple scenario we had over 1.000 lines of output. I can't even imagine in production (thousands of users per day). Could we go without this? |
The trace is used only to evaluate what the issue might be, this is not recommended for production. I assume that you have a dev/test/qa environment that should be *fairly* close to what you run in production. You would want to do your tracing in one of these areas. anonymous wrote : | We don't have any warnings from JBoss stating that it closed the connection for us, but if you would not mind to explain to me, how does JBoss check this? I mean if we do have a connection leak, in a class that is hold in memory and not collected by the GC, would JBoss still claim that connection and close it? | The CacheConnectionManager is the component that handles the automatic connection close. This is actually JCA spec mandated behavior. Use of this in JBoss depends on a few things 1) The debug flag needs to be set in the CachedConnectionManager. This is on by default, so typically you don't need to do anything to enable this. 2) You are accessing a DataSource from an EJB By default all container configuration in standardjboss.xml and the EJB3 equivalent (ejb3-interceptors-aop.xml) are set to use the CacheConnectionInterceptor. Again, this is on by default and typically does not required explicit changes to enable. 3)You are accessing the DataSource from a Servlet/JSP For Servlets and JSP this behavior does have to be explicity enabled. Information on how to do this can be found here http://wiki.jboss.org/wiki/Wiki.jsp?page=CanJBossTellMeWhenIDontCloseAConnection Note, this has nothing to do with the GC but rather the connection management system of JCA. If you use connections and do not appropriately close these connections (along with it's sub objects PreparedStatements, ResultSet etc) you will get leaks. As a result, the ManagedConnectionPool will run out of connections and you will not be able to aquire any further resources. anonymous wrote : | Regarding the JTDS, that's our next shot, do you know if it has a better performance than jconnect (which according to Sybase is the best around ;) ) | Of course :-). I always recommend testing with multiple drivers for RDMS systems that have this option. Sybase/MSSQL Server are two that do. JTDS has been known to perform better and handle certain transactional sistuations much better than the close source counterpart. anonymous wrote : | As you can see there's no connection idle timeout (our mistake) we are fixing it. But what's the behavior of this property, would jboss close the physical connection between it and the DB after the number of minutes informed? If so, why during low access periods (late evenings for instance) I still get 50 connections available, wouldn't the expected number be something like 10 (the minimum)? | If an idle timeout is not specified, a default of 30 minutes is used so, whether you specify one or not, this behavior is always on. The behavior is that after a period of time the IdleRemover thread in JBoss evaluates the connection pool to determine if any connections have been idle for the period of time. If so, it automatically closes the connection and, depending upon your minumum setting, brings the pool back to the minimum connection allotment if necessary. Based upon what you are seeing, yes, the connection pool *should* be reduced to the minimum number of connections during periods of low activity. This is why a standalone test case would be useful. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993513#3993513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993513 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
