[JBoss JIRA] Created: (EJBTHREE-710) Cleanup E-EJB3 package/code/logging
by Christian Bauer (JIRA)
Cleanup E-EJB3 package/code/logging
-----------------------------------
Key: EJBTHREE-710
URL: http://jira.jboss.com/jira/browse/EJBTHREE-710
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC9 - FD
Reporter: Christian Bauer
Priority: Blocker
This is E-EJB3 RC9. The following issues are not minor, they would make me feel uneasy if I was a user:
1. The bundled embedded-jboss-beans.xml uses xmlns="urn:jboss:bean-deployer" and everybody gets a nice WARN on startup that xmlns="urn:jboss:bean-deployer:2.0" should be used. Change that in the distributed configuration file.
2. [java] 13:40:10,676 WARN Ejb3Configuration:104 - Persistence provider caller does not implements the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null. It's OK to warn users that something is not right, but if something is not right in our distribution there should be a note in the README or something that tells me as a user that this is OK for the moment. Like a link to a JIRA issue.
3. [java] 13:44:59,381 WARN JBossTimerServiceFactory:112 - TIMER SERVICE IS NOT INSTALLED -- Uh, yes, because I don't want it. Find a way for users to disable this warning. I don't see any way to disable the timer service in embedded-jboss-beans.xml and I don't want the .rar and .jar in my libs.
4. In RC9 there is code that prints debugging stuff on STDOUT:
[java] lookup
[java] UserTransaction: org.jboss.ejb3.embedded.UserTransactionImpl
[java] MessageHandlerBean: org.jnp.interfaces.NamingContext
This is triggered by EJB3StandaloneBootstrap.scanClasspath("helloworld-ejb3/build"), please remove from code...
--
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: (JBCACHE-814) Concurrency issue with passivation
by Brian Stansberry (JIRA)
Concurrency issue with passivation
----------------------------------
Key: JBCACHE-814
URL: http://jira.jboss.com/jira/browse/JBCACHE-814
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0.SP1
Reporter: Brian Stansberry
Assigned To: Manik Surtani
If the eviction thread attempts to passivate a node roughly concurrently with a get() call, it is quite easy for the get() to return null even though the passivated node has data.
Test org.jboss.cache.passivation.ConcurrentPassivationTest shows the problem.
I believe the problem results from having the PessimisticLockInterceptor in the chain after the Activation and Passivation interceptors. Potential cause is a race to the PessimisticLockInterceptor between the eviction thread and an application thread doing a get().
1) Eviction thread wins race, acquires a WL on a node.
2) Application thread is trailing in the race but proceeds through the Activation/Passivation interceptors w/o loading data, because the desired node is still in the cache.
3) Application thread blocks waiting for eviction thread's WL to be released.
4) Eviction thread removes the node from the tree structure.
5) Eviction thread releases the WL. Application thread acquires a RL (it already had a ref to the node).
6) Application thread gets to the cache _get method, which can't find the node in the tree structure, and thus returns null.
Another variation on the same theme:
1) Eviction thread wins race, acquires a WL on a node.
2) Application thread is trailing in the race but proceeds through the Activation/Passivation interceptors w/o loading data, because the desired node is still in the cache.
3) Eviction thread removes the node from the tree structure.
4) Application thread gets to PessimisticLockInterceptor, which can't find the node. No need to acquire lock on non-existent node, so thread proceeds.
5) Application thread gets to the cache _get method, which can't find the node in the tree structure, and thus returns 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: (JBPM-714) packaging just the webapp takes way to long
by Ronald van Kuijk (JIRA)
packaging just the webapp takes way to long
-------------------------------------------
Key: JBPM-714
URL: http://jira.jboss.com/jira/browse/JBPM-714
Project: JBoss jBPM
Issue Type: Feature Request
Affects Versions: jBPM 3.2 alpha 1
Environment: Eclipse 3.2, gpd 3.0.11, jdk 1.5 windhoos
Reporter: Ronald van Kuijk
Assigned To: Tom Baeyens
Fix For: jBPM 3.2
Packaging just the webapp takes 13 seconds. In this time the 'global' compile is used. This results in packaging jbpm-jpdl.jar twice and copying it to the repository twice.
This should be optimised in combination with a 'deploy' target which deploys it to a configured location.
Even better would be if it is a real WTP web (sub?) project which can have things like 'auto deployment' small updates to .xhtml files available immediately, etc....
--
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: (JBMESSAGING-437) Non durable subscription optimization
by Tim Fox (JIRA)
Non durable subscription optimization
-------------------------------------
Key: JBMESSAGING-437
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-437
Project: JBoss Messaging
Issue Type: Task
Affects Versions: 1.0.1.CR3
Reporter: Tim Fox
Assigned To: Tim Fox
Fix For: 1.0.2
Since non durable subscriptions only live for the life-time of the consumer the it's struck me that we don't actually need to send any acks from the client to the server as messages are acknowledged for non durable subs.
Basically I think we can acknowledge them before they are sent from server to client.
This is because there's no case where messages will be redelivered from the server to the non durable sub, therefore no need for acks.
On session recovery and session rollback messages are redelivered locally (i.e. they are already on the client) so no need for the server to redeliver.
This also means we don't need to maintain a delivery list in the server consumer endpoint in this case, and the server consumer endpoint can return a done delivery every time.
--
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-3597) Test error org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
by Dimitris Andreadis (JIRA)
Test error org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
-------------------------------------------------------------------------------
Key: JBAS-3597
URL: http://jira.jboss.com/jira/browse/JBAS-3597
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: JMS service
Environment: Java Version 1.4.2_09
Java Vendor Sun Microsystems Inc.
Java VM Name Java HotSpot(TM) Client VM
Java VM Version 1.4.2_09-b05
Java VM Info mixed mode
OS Name Linux
OS Version 2.6.9-34.0.2.ELsmp
OS Arch i386
Reporter: Dimitris Andreadis
Fix For: JBossAS-4.0.5.GA
Test org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange fails with
Error The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:92)
at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:541)
at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:312)
at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:784)
at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:312)
at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:182)
at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396)
at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
at java.lang.Thread.run(Thread.java:534)
For
MatrixTestContainer(jms_4_0_4_GA)
MatrixTestContainer(jms_4_0_x)
--
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-3612) failing org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
by Dimitris Andreadis (JIRA)
failing org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
----------------------------------------------------------------------
Key: JBAS-3612
URL: http://jira.jboss.com/jira/browse/JBAS-3612
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Test Suite
Reporter: Dimitris Andreadis
Fix For: JBossAS-4.0.5.GA
test402Compatibility Failure
Failures on SerialVersionComparisson:org.jboss.aspects.versioned.StateManager, org.jboss.console.manager.PluginManager$1, org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset, org.jboss.console.plugins.helpers.BasePluginWrapper, org.jboss.console.plugins.helpers.servlet.TabTag, org.jboss.console.remote.InvokerServlet, org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor, org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator, org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator, org.jboss.invocation.jrmp.server.JRMPInvoker, org.jboss.proxy.ClientContainerEx, org.jboss.proxy.ejb.DynamicIIOPStub, org.jboss.proxy.ejb.HomeHandleImplIIOP, org.jboss.tm.iiop._CoordinatorExtStub, org.jboss.tm.iiop._TransactionFactoryExtStub, org.jboss.tm.iiop._TransactionServiceStub
junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:org.jboss.aspects.versioned.StateManager,
org.jboss.console.manager.PluginManager$1,
org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset,
org.jboss.console.plugins.helpers.BasePluginWrapper,
org.jboss.console.plugins.helpers.servlet.TabTag,
org.jboss.console.remote.InvokerServlet,
org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor,
org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator,
org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator,
org.jboss.invocation.jrmp.server.JRMPInvoker,
org.jboss.proxy.ClientContainerEx,
org.jboss.proxy.ejb.DynamicIIOPStub,
org.jboss.proxy.ejb.HomeHandleImplIIOP,
org.jboss.tm.iiop._CoordinatorExtStub,
org.jboss.tm.iiop._TransactionFactoryExtStub,
org.jboss.tm.iiop._TransactionServiceStub
at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
test401Compatibility Failure Failures on SerialVersionComparisson:javax.management.loading.MLet, org.jboss.aspects.versioned.StateManager, org.jboss.console.manager.PluginManager$1, org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset, org.jboss.console.plugins.helpers.BasePluginWrapper, org.jboss.console.plugins.helpers.servlet.TabTag, org.jboss.console.remote.InvokerServlet, org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor, org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator, org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator, org.jboss.invocation.jrmp.server.JRMPInvoker, org.jboss.monitor.alarm.AlarmNotification, org.jboss.monitor.alarm.AlarmTableNotification, org.jboss.proxy.ejb.DynamicIIOPStub, org.jboss.proxy.ejb.HomeHandleImplIIOP, org.jboss.tm.iiop._CoordinatorExtStub, org.jboss.tm.iiop._TransactionFactoryExtStub, org.jboss.tm.iiop._TransactionServiceStub
junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.management.loading.MLet,
org.jboss.aspects.versioned.StateManager,
org.jboss.console.manager.PluginManager$1,
org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset,
org.jboss.console.plugins.helpers.BasePluginWrapper,
org.jboss.console.plugins.helpers.servlet.TabTag,
org.jboss.console.remote.InvokerServlet,
org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor,
org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator,
org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator,
org.jboss.invocation.jrmp.server.JRMPInvoker,
org.jboss.monitor.alarm.AlarmNotification,
org.jboss.monitor.alarm.AlarmTableNotification,
org.jboss.proxy.ejb.DynamicIIOPStub,
org.jboss.proxy.ejb.HomeHandleImplIIOP,
org.jboss.tm.iiop._CoordinatorExtStub,
org.jboss.tm.iiop._TransactionFactoryExtStub,
org.jboss.tm.iiop._TransactionServiceStub
--
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