[JBoss JIRA] Created: (EJBTHREE-659) SFSB throws exception with second passivation
by Ben Wang (JIRA)
SFSB throws exception with second passivation
---------------------------------------------
Key: EJBTHREE-659
URL: http://jira.jboss.com/jira/browse/EJBTHREE-659
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC8 - FD
Reporter: Ben Wang
Assigned To: Ben Wang
Fix For: EJB 3.0 RC9 - FD
I have created a test case to illustrate this for both SimpleStatefulCache and StatefulTreeCache, NestedBeanUnitTestCase (cache and clusteredsession). Basically, if we do this:
bean.getXXX
sleep(10000); // to passivate
bean.getXXX; // to acitvate
sleep(10000); // to passivate again
This will produce:
2006-07-24 04:46:59,358 ERROR [org.jboss.ejb3.cache.simple.SimpleStatefulCache] problem passivation thread^M
javax.ejb.EJBException: Could not passivate; failed to save state^M
at org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.java:363)^M
at org.jboss.ejb3.cache.simple.SimpleStatefulCache.passivate(SimpleStatefulCache.java:196)^M
at org.jboss.ejb3.cache.simple.SimpleStatefulCache$SessionTimeoutTask.run(SimpleStatefulCache.java:129)^M
Caused by: java.lang.NullPointerException^M
at org.jboss.serial.util.StringUtil.calculateUTFSize(StringUtil.java:319)^M
at org.jboss.serial.util.StringUtil.saveString(StringUtil.java:63)^M
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeUTF(DataContainer.java:265)^M
at org.jboss.ejb3.stateful.StatefulBeanContextReference.writeExternal(StatefulBeanContextReference.java:65)^M
at org.jboss.serial.persister.ExternalizePersister.writeData(ExternalizePersister.java:58)^M
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:275)^M
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:197)^M
at org.jboss.serial.io.JBossObjectOutputStream.writeObjectOverride(JBossObjectOutputStream.java:181)^M
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:287)^M
at org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.java:347)^M
... 2 more^M
This is caused by a bug from ProxiedStatefuleBeanContext serialization where we dont serialiaze parentRef if it is not null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (EJBTHREE-653) No pooling for stateless session beans
by Guido Bening (JIRA)
No pooling for stateless session beans
--------------------------------------
Key: EJBTHREE-653
URL: http://jira.jboss.com/jira/browse/EJBTHREE-653
Project: EJB 3.0
Issue Type: Bug
Components: EJB3 Extensions
Affects Versions: EJB 3.0 RC8 - FD
Environment: OS: Windows XP SP2
JDK 1.5.0_06_b05
JBoss AS 4.0.4 GA
Reporter: Guido Bening
Scenario:
Client VM calls a method on a EJB 2 Stateful Session Bean (SFSB) via the remote interface in a loop for 1000 times.Transaction starts on the application server. The SFSB method calls a method on a EJB3 Stateless Session Bean (SLSB) - via the remote interface (local interface makes no difference).
The print out in the PostConstruct callback method of the EJB3 SLSB shows us, that a new bean instance was created for each of the 1000 method calls. Because of ThreadLocal pooling approach, we print out the Thread id too to show, that we always have the same Thread for each method call.
CallBack method:
/**
* EJBCreate method.
*/
@PostConstruct
public void ejb3Create() {
System.out.println("New SessionBean " + this);
System.out.println("Thread " + Thread.currentThread().getId());
setupBean();
}
And the log for a few of the 1000 calls:
...
09:17:51,119 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@231ae2
09:17:51,129 INFO [STDOUT] Thread 97
09:17:51,139 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1662174
09:17:51,139 INFO [STDOUT] Thread 97
09:17:51,219 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@189f155
09:17:51,219 INFO [STDOUT] Thread 97
09:17:51,239 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1a82dfb
09:17:51,239 INFO [STDOUT] Thread 97
09:17:51,289 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@198813a
09:17:51,289 INFO [STDOUT] Thread 97
09:17:51,309 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@59eefd
09:17:51,309 INFO [STDOUT] Thread 97
09:17:51,359 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@2e3520
09:17:51,369 INFO [STDOUT] Thread 97
09:17:51,379 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1ed457
09:17:51,379 INFO [STDOUT] Thread 97
09:17:51,439 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1e1c7f3
09:17:51,439 INFO [STDOUT] Thread 97
09:17:51,449 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@15cb8ed
09:17:51,449 INFO [STDOUT] Thread 97
09:17:51,519 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1a4a949
09:17:51,519 INFO [STDOUT] Thread 97
09:17:51,529 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@19ae0a
09:17:51,529 INFO [STDOUT] Thread 97
09:17:51,589 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@567fa0
09:17:51,599 INFO [STDOUT] Thread 97
09:17:51,609 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@19956fe
09:17:51,609 INFO [STDOUT] Thread 97
09:17:51,659 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@150e574
09:17:51,669 INFO [STDOUT] Thread 97
09:17:51,679 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@aa46ad
09:17:51,679 INFO [STDOUT] Thread 97
...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBAS-3537) Add a startup switch to configure a multicast port
by Brian Stansberry (JIRA)
Add a startup switch to configure a multicast port
--------------------------------------------------
Key: JBAS-3537
URL: http://jira.jboss.com/jira/browse/JBAS-3537
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.0.0.CR1
Proper cluster isolation with UDP requires use of a different cluster name, different multicast address and different multicast port. (See http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic for why the latter is important.)
The -g and -u switches allow easy configuration of the cluster name and multicast address. But, configuring the port that way wasn't practical, as an AS instance may have many different JChannels.
With the JGroups multiplexer, a switch is a possibility, as by default there will only be one JChannel per server instance. (If a user wanted to use more than one JChannel, they would need to manually configure the second one to use a different port.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBAS-3550) JBAS 4.0.4GA Test suite Error on Java 1.5 - org.jboss.test.classloader.test.CircularityUnitTestCase (testRecursiveLoadMT)
by Vivek Lakshmanan (JIRA)
JBAS 4.0.4GA Test suite Error on Java 1.5 - org.jboss.test.classloader.test.CircularityUnitTestCase (testRecursiveLoadMT)
-------------------------------------------------------------------------------------------------------------------------
Key: JBAS-3550
URL: http://jira.jboss.com/jira/browse/JBAS-3550
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Test Suite
Affects Versions: JBossAS-4.0.4.GA
Environment: Sun 1.5.0_08, Java VM Version 1.5.0_08-b03
OS: Linux RHEL 4 U3 2.6.9-34.EL
Arch: i386
Reporter: Vivek Lakshmanan
The above test case seems to produce an error frequently on Sun 1.5 JVM. From a cursory search through JIRA, it seems this could be related
to JIRA issue JBAS-760.
The stacktrace produced in the test reports follows:
javax.management.MBeanException
at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:180)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:163)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.Exception: Thread1 failed to load HARMIServerImpl_Stub, class=null
at org.jboss.test.classloader.circularity.test.RecursiveCCETests.testRecursiveLoadMT(RecursiveCCETests.java:99)
at org.jboss.test.classloader.circularity.Starter.testRecursiveLoadMT(Starter.java:154)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
... 40 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBAS-3548) RMIAdaptorUnitTestCase testMBeanInfoMarshalling failures
by Matt Wringe (JIRA)
RMIAdaptorUnitTestCase testMBeanInfoMarshalling failures
--------------------------------------------------------
Key: JBAS-3548
URL: http://jira.jboss.com/jira/browse/JBAS-3548
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Test Suite
Affects Versions: JBossAS-4.0.4.GA
Environment: Sun 1.5.0_08 JVM
RHEL 4, Linux Kernel 2.6.9
Reporter: Matt Wringe
The org.jboss.test.jmx.test.RMIAdaptorUnitTestCase testMBeanInfoMarshalling test fails on the Sun 1.5.0 JVM.
>From the test report:
"Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL
junit.framework.AssertionFailedError: Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL
at org.jboss.test.jmx.test.RMIAdaptorUnitTestCase.testMBeanInfoMarshalling(RMIAdaptorUnitTestCase.java:72)"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBPM-742) Reimplement JbpmThreadsServlet as a ServletContextListener
by Alejandro Guizar (JIRA)
Reimplement JbpmThreadsServlet as a ServletContextListener
----------------------------------------------------------
Key: JBPM-742
URL: http://jira.jboss.com/jira/browse/JBPM-742
Project: JBoss jBPM
Issue Type: Feature Request
Components: Core Engine
Affects Versions: jBPM 3.1.1
Reporter: Alejandro Guizar
ServletContextListeners are a viable alternative to servlets for management of the jBPM scheduler/command threads. From the Servlet 2.4 spec, section 10.2:
>>>
Servlet event listeners support event notifications for state changes in the ServletContext, HttpSession and ServletRequest objects.
Servlet context listeners are used to **manage resources** or state held at a JVM level for the application.
<<<
Their intent definitely seems to match our purposes.
Further below:
>>>
There may be multiple listener classes listening to each event type.
<<<
We could have separate listeners for the scheduler and command executor so that applications may remove either of them in case the related service is not used.
Section 10.2.2 provides an example. When the application starts up, the listener creates a connection to the database and stores it in the servlet context. Servlets access the connection from the context as needed. When the application shuts down, the listener closes the connection.
Our listener could start the thread and store it in the servlet context, then stop it using the mechanisms provided by JBPM-741.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months