[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, 3 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, 3 months
[JBoss JIRA] Created: (JGRP-415) Asynchronous dispatching of messages in Multiplexer
by Brian Stansberry (JIRA)
Asynchronous dispatching of messages in Multiplexer
---------------------------------------------------
Key: JGRP-415
URL: http://jira.jboss.com/jira/browse/JGRP-415
Project: JGroups
Issue Type: Feature Request
Reporter: Brian Stansberry
Assigned To: Bela Ban
Fix For: 2.5
With the multiplexer, it is fairly straightforward to have a situation where a problem one service is having handling a message prevents receipt by other services of messages from the problem message's sender.
E.g., 3 servers, {A, B, C} all running 3 services S1, S2, S3 that share a mux channel. S1 is an instance of JBoss Cache. A.S1 sends a replication message to the cluster. On B, the thread carrying the message blocks waiting to acquire a lock in JBoss Cache. The ordering protocols in B's channel will prevent B.S2 and B.S3 receiving any further messages from A until the lock is acquired on S1 or the attempt times out.
JGRP-176 could deal with this at the MessageDispatcher/RequestCorrelator level, but a simpler solution is to add asynchronous message handling in Multiplexer. A set of (bounded) queues is maintained in the Multiplexer, one per service. When messages arrive in Multiplexer.up(), the message is added to the queue, and the JGroups up thread returns. Multiplexer maintains a thread pool that reads messages off the queues and passes them up to the mux channel. The use of queues ensures the messages are received in FIFO order at the application level.
It is still possible that one service could block others, if it's queue is full. We need to determine exactly how to size the queues -- i.e. based on number of bytes of queued messages, or based on number of messages. An application could then configure the size of its queue such that the queue shouldn't fill under expected load during any normal events (e.g. a JBC queue should be configured not to fill during the normal lock acquisition timeout.)
--
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, 3 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, 3 months
[JBoss JIRA] Created: (JBPM-820) free choice of initial node type
by Tom Baeyens (JIRA)
free choice of initial node type
--------------------------------
Key: JBPM-820
URL: http://jira.jboss.com/jira/browse/JBPM-820
Project: JBoss jBPM
Issue Type: Feature Request
Components: Core Engine
Reporter: Tom Baeyens
Assigned To: Tom Baeyens
Fix For: jBPM 3.2
currently, you are forced to have a start-state to mark the initial node in your process-definition.
i think it is a good idea to expand this so that any type of node could be the first node in the process. we already did this with SEAM.
IMO, the most elegant way to achieve this is by adding an optional attribute 'initial' to the process-definition. the value must be a node name. when the initial node is specified as an attribute, the process should not have a start-state.
the result is that with the initial attribute on the process-definition, any node type can be used as the start state.
we would have to update the core engine new ProcessInstance(processDefinition) method. after creating the process instance and positioning the token in the initial node, the initial node has to be executed. now that is not the case. the initial node is not executed.
because the start-state now has an empty implementation, this will be backwards compatible.
--
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, 3 months