[JBoss Seam] - Problem with leaked connections from passivated/activated SF
by kahliburke
OK, here we go with a first post to the JBoss forums...
I've searched through the forums and JIRA and can't find anything about this. Forgive me if this problem is due to my own lack of understanding. This may be more appropriate for the EJB 3 forum, just let me know.
I am using the following:
JBoss 4.0.5 with EJB profile
Seam 1.1CR1
Basically, the problem I'm having occurs when I have an EntityManger with persistence type PersistenceContextType.EXTENDED, in a stateful session bean, which has been passivated and then activated again. When the entity manager is used again, JBoss complains about a leaked connection, assuming the debug connection monitoring is turned on in the JBoss JCA configuration (it is on by default). I get the following exception:
| [CachedConnectionManager] Closing a connection for you. Please close them yourself: org.jboss.resource.adapter.jdbc.WrappedConnection@65d4c6
| java.lang.Throwable: STACKTRACE
| at org.jboss.resource.connectionmanager.CachedConnectionManager.registerConnection(CachedConnectionManager.java:290)
| at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:417)
| at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
| at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
| at org.hibernate.connection.DatasourceConnectionProvider.getConnection(DatasourceConnectionProvider.java:69)
| at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:417)
| at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
| at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
| at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1560)
| at org.hibernate.loader.Loader.doQuery(Loader.java:661)
| at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
| at org.hibernate.loader.Loader.loadEntity(Loader.java:1784)
| at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
| at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
| at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2977)
| at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:393)
| at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:374)
| at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:137)
| at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:193)
| at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:101)
| at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
| at org.hibernate.impl.SessionImpl.get(SessionImpl.java:815)
| at org.hibernate.impl.SessionImpl.get(SessionImpl.java:808)
| at org.hibernate.ejb.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:174)
| at org.jboss.ejb3.entity.ExtendedEntityManager.find(ExtendedEntityManager.java:119)
| at test.StatefulImpl.doSomething(StatefulImpl.java:52)
|
If I try to use the component after that, I'll get another exception because the connection has been closed:
| 00:27:49,328 INFO [STDOUT] Hibernate: select testentity0_.id as id10_0_ from TestEntity testentity0_ where testentity0_.id=?
| 00:27:49,351 WARN [JDBCExceptionReporter] SQL Error: 0, SQLState: null
| 00:27:49,351 ERROR [JDBCExceptionReporter] Connection handle has been closed and is unusable
| 00:27:49,351 INFO [DefaultLoadEventListener] Error performing load command
| org.hibernate.exception.GenericJDBCException: could not load an entity: [test.TestEntity#1]
| at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
| at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
| at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
| at org.hibernate.loader.Loader.loadEntity(Loader.java:1798)
| at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
| at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
| at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2977)
| at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:393)
| at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:374)
| at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:137)
| at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:193)
| at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:101)
| at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
| at org.hibernate.impl.SessionImpl.get(SessionImpl.java:815)
| at org.hibernate.impl.SessionImpl.get(SessionImpl.java:808)
| at org.hibernate.ejb.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:174)
| at org.jboss.ejb3.entity.ExtendedEntityManager.find(ExtendedEntityManager.java:119)
| at test.StatefulImpl.doSomething(StatefulImpl.java:52)
|
I've tried changing configuration to get around this. I tried turning off the debug connection monitoring, based on a page I read somewhere that indicated Hibernate could confuse the debug monitoring and lead to spurious connection closed warnings. If I turn this off I don't get these exceptions, but I do see connections really leaking. I'm not sure if a connection is leaked every request but it is definitely occurring. Eventually I run out and get an exception that a connection could not be obtained from the pool.
I tried to simplify the case as much as I could to make sure it wasn't something in my code. Eventually I tried a fresh clean JBoss installation, modified the booking example and changed the HotelSearchingAction to use an extended persistence context and also configured the passivation timeout with @CacheConfig(idleTimeoutSeconds=2). I can see this with the default timeout, but I can see the problem much more quickly this way. I'm using MySQL for my app, but I was able to reproduce on Hypersonic as well. So if I make those changes, log in and hit the search page, I can see this problem readily.
My understanding is that there is not anything special I need to do when passivating a session bean with an extended persistence context. Is this incorrect? Is there a requirement that the entity manager be flushed or otherwise modified in a @PrePassivate method? Is there some configuration I've missed?
I can post example code but I thought since only 2 small changes are needed in the booking example it might be easier to look at that way. Hopefully I've provided enough information in case this is a JBoss bug. If not please let me know and I will provide more.
Any direction on whether this is a bug or my own fault would be greatly appreciated.
Thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989949#3989949
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989949
19Â years, 5Â months
[JBossCache] - Working with TreeSet / checkSetRecursion bug? [v2.0 alpha]
by chasta
Hi,
This regards a bug (?) in v2.0 alpha that'll affect only the case of storing a sorted set (e.g. TreeSet) in PojoCache. Now, the documentation specifies that "The Set interface maps to java.util.HashSet implementation", but does that mean the user should never store i.e. TreeSets (e.g., as a data member) in the PojoCache ?
If not, this probably is a bug:
CollectionClassHandler.checkSetRecursion() does a remove() to the Set with itslef. However, since a SortedSet looks for a member using comparisons and will cast the given key (for removal) to Comparable. and a SortedSet does not implement Comparable, a ClassCastException will occur and escape the Cache code.
Using a custom "ComparableSortedSet" which inherits from SortedSet and adds an implementation for Comaprable, everything seems to work.
I think this can be pretty easily handled in the PojoCache code. Do you agree? Should I file a bug?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989948#3989948
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989948
19Â years, 5Â months
[JBoss jBPM] - Re: Action ; Token.signal( ... ) ; Exception: locked tokens
by JimKnopf
I know, but the Problem i have is that this ruleresults only give true or false and later it should be possible to create a new workflow with out the capacity to create a new decision- or action-class (my english isn't good so i am sorry if it is not well explaint). That is the reason, why need the ability to activate more then one decision but that in a single node. Like this:
| <decision name="SGA">
| <event type="node-enter">
| <action name="checkTakeT_sgaA" class="actions.DefaultRuleAction">
| <ruleFile>etr1.drl</ruleFile>
| <transitionName>t_sgaA</transitionName>
| </action>
| <action name="checkTakeT_sgaBOrT_sgaC" class="actions.DefaultRuleAction">
| <ruleFile>etr1.drl</ruleFile>
| <transitionName>t_sgaB</transitionName>
| <transitionName_False>t_sgaC</transitionName_False>
| </action>
| </event>
| <transition name="t_sgaC" to="SGAC"></transition>
| <transition name="t_sgaB" to="SGAB"></transition>
| <transition name="t_sgaA" to="SGAA"></transition>
| </decision>
|
If i use a decision-Handler i must use two desicions to realise the same because it is only possible to call one (what is ok and logical) decision-Handler in a decision (or did i think in a wrong way?).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989945#3989945
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989945
19Â years, 5Â months
[JBoss Portal] - Re: Portal 2.4 as a windows service
by bvogt
"schuffr" wrote : You did with JBoss portal? any chance I can see your wrapper.conf file? I keep getting a java.lang.NoClassDefFoundError: org/tanukisoftware/wrapper/WrapperSimpleApp
|
| error.
|
| thanks
|
| rob
I used 2.4 CR1, but that should not be the reason as the error is a classpath error.
My configuration needs an env var named JBOSS_PORTAL_JAVA_HOME, which defines the JAVA_HOME for the JBOSS portal (service) to be used.
Doing this preserves the flexibility to have a different location on another box, while the wrapper.conf remains the same.
I created the following directory/file structure before copying its content into $JBOSS_HOME (the parent directory):
| Verzeichnis von D:\jBoss\jboss-4.0.5.GA\wrapper
|
| 29.11.2006 14:05 <DIR> .
| 29.11.2006 14:05 <DIR> ..
| 29.11.2006 14:07 <DIR> bin
| 29.11.2006 13:29 <DIR> conf
| 29.11.2006 13:29 <DIR> lib
| 29.11.2006 14:05 <DIR> logs
| 0 Datei(en) 0 Bytes
|
| Verzeichnis von D:\jBoss\jboss-4.0.5.GA\wrapper\bin
|
| 29.11.2006 14:07 <DIR> .
| 29.11.2006 14:07 <DIR> ..
| 17.10.2006 23:22 1.271 InstallWrapper-NT.bat
| 17.10.2006 23:22 1.275 UninstallWrapper-NT.bat
| 17.10.2006 23:22 1.423 Wrapper.bat
| 17.10.2006 23:22 204.800 wrapper.exe
| 4 Datei(en) 208.769 Bytes
|
| Verzeichnis von D:\jBoss\jboss-4.0.5.GA\wrapper\conf
|
| 29.11.2006 13:29 <DIR> .
| 29.11.2006 13:29 <DIR> ..
| 29.11.2006 14:09 3.737 wrapper.conf
| 1 Datei(en) 3.737 Bytes
|
| Verzeichnis von D:\jBoss\jboss-4.0.5.GA\wrapper\lib
|
| 29.11.2006 13:29 <DIR> .
| 29.11.2006 13:29 <DIR> ..
| 17.10.2006 23:22 81.920 wrapper.dll
| 17.10.2006 23:22 83.820 wrapper.jar
| 2 Datei(en) 165.740 Bytes
|
| Verzeichnis von D:\jBoss\jboss-4.0.5.GA\wrapper\logs
|
| 29.11.2006 14:05 <DIR> .
| 29.11.2006 14:05 <DIR> ..
| 0 Datei(en) 0 Bytes
|
The wrapper.conf itself contains:
| #********************************************************************
| # Wrapper Properties
| #********************************************************************
| # Java Application
| wrapper.java.command=%JBOSS_PORTAL_JAVA_HOME%/bin/java
|
| # Java Main class. This class must implement the WrapperListener interface
| # or guarantee that the WrapperManager class is initialized. Helper
| # classes are provided to do this for you. See the Integration section
| # of the documentation for details.
| wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
|
| # Java Classpath (include wrapper.jar) Add class path elements as
| # needed starting from 1
| wrapper.java.classpath.1=../lib/wrapper.jar
| wrapper.java.classpath.2=%JBOSS_PORTAL_JAVA_HOME%/lib/tools.jar
| wrapper.java.classpath.3=../bin/run.jar
|
| # Java Library Path (location of Wrapper.DLL or libwrapper.so)
| wrapper.java.library.path.1=../lib
|
| # Java Additional Parameters
| wrapper.java.additional.1=-Dprogram.name=run.bat
|
| # Initial Java Heap Size (in MB)
| wrapper.java.initmemory=64
|
| # Maximum Java Heap Size (in MB)
| wrapper.java.maxmemory=512
|
| # Application parameters. Add parameters as needed starting from 1
| wrapper.app.parameter.1=org.jboss.Main
|
| #********************************************************************
| # Wrapper Logging Properties
| #********************************************************************
| # Format of output for the console. (See docs for formats)
| wrapper.console.format=PM
|
| # Log Level for console output. (See docs for log levels)
| wrapper.console.loglevel=INFO
|
| # Log file to use for wrapper output logging.
| wrapper.logfile=../logs/wrapper.log
|
| # Format of output for the log file. (See docs for formats)
| wrapper.logfile.format=LPTM
|
| # Log Level for log file output. (See docs for log levels)
| wrapper.logfile.loglevel=INFO
|
| # Maximum size that the log file will be allowed to grow to before
| # the log is rolled. Size is specified in bytes. The default value
| # of 0, disables log rolling. May abbreviate with the 'k' (kb) or
| # 'm' (mb) suffix. For example: 10m = 10 megabytes.
| wrapper.logfile.maxsize=10m
|
| # Maximum number of rolled log files which will be allowed before old
| # files are deleted. The default value of 0 implies no limit.
| wrapper.logfile.maxfiles=10
|
| # Log Level for sys/event log output. (See docs for log levels)
| wrapper.syslog.loglevel=NONE
|
| #********************************************************************
| # Wrapper Windows Properties
| #********************************************************************
| # Title to use when running as a console
| wrapper.console.title=JBOSS-Portal
|
| #********************************************************************
| # Wrapper Windows NT/2000/XP Service Properties
| #********************************************************************
| # WARNING - Do not modify any of these properties when an application
| # using this configuration file has been installed as a service.
| # Please uninstall the service before modifying this section. The
| # service can then be reinstalled.
|
| # Name of the service
| wrapper.ntservice.name=JBOSS-Portal
|
| # Display name of the service
| wrapper.ntservice.displayname=JBOSS-Portal
|
| # Description of the service
| wrapper.ntservice.description=JBOSS-Portal
|
| # Service dependencies. Add dependencies as needed starting from 1
| wrapper.ntservice.dependency.1=
|
| # Mode in which the service is installed. AUTO_START or DEMAND_START
| wrapper.ntservice.starttype=AUTO_START
|
| # Allow the service to interact with the desktop.
| wrapper.ntservice.interactive=false
|
| # BV: valid values are: LOW | NORMAL | HIGH | REALTIME
| wrapper.ntservice.process_priority=HIGH
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989943#3989943
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989943
19Â years, 5Â months
[Remoting] - Re: Client timeouts while waiting for response from server
by tomerc
Hi,
First of all thank you for the quick reply.
We are working directly with jboss remoting (without any ejb), we currently have 4 clients machines talking to one server. the client machines are under a heavy load and are constantly quering the server.
The configuration for the connector is :
<mbean code="org.jboss.remoting.transport.Connector" xmbean-dd="org/jboss/remoting/transport/Connector.xml"
| name="jboss.remoting:service=Connector,transport=Socket"
| display-name="Socket Transport Connector">
| <depends>jboss.remoting:service=MulticastDetector,transport=multicast</depends>
| <depends>SIM:service=Storage</depends>
| <!--attribute name="InvokerLocator"><![CDATA[socket://storage:8084]]></attribute-->
| <!--attribute name="InvokerLocator"><![CDATA[socket://${bind.addrres}:8084]]></attribute-->
| <attribute name="InvokerLocator"><![CDATA[socket://${bind.addrres}:8084/?simStorageMode=${storage.mode}]]></attribute>
| <attribute name="Configuration">
| <config>
| <handlers>
| <handler subsystem="get">com.flash.storage.handlers.server.GetServerInvocationHandler</handler>
| <handler subsystem="remove">com.flash.storage.handlers.server.RemoveServerInvocationHandler</handler>
| <handler subsystem="set">com.flash.storage.handlers.server.SetServerInvocationHandler</handler>
| <handler subsystem="exists">com.flash.storage.handlers.server.ExistsServerInvocationHandler</handler>
| </handlers>
| </config>
| </attribute>
| </mbean>
Thank you.
Tomer
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989941#3989941
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989941
19Â years, 5Â months