[JBoss JIRA] Created: (JBAS-9246) Create test to verify messages are not delivered to MDBs before EJB container is started.
by Dimitris Andreadis (JIRA)
Create test to verify messages are not delivered to MDBs before EJB container is started.
-----------------------------------------------------------------------------------------
Key: JBAS-9246
URL: https://issues.jboss.org/browse/JBAS-9246
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB
Affects Versions: JBossAS-5.1.0.GA
Environment: Version info:
JBoss 5.1.0 GA (we use a local build, and have updated JBoss Cache to 3.2.1.GA, JBossTS to 4.6.1.GA_CP03 and JGroups to 2.6.13.GA to pick up bug fixes for issues we have encountered in production)
ActiveMQ 5.3.0 GA
HornetQ 2.0.0 GA
Java 1.6.0_17
Mac OS 10.6.2
Reporter: Robert West
Assignee: Carlo de Wolf
Priority: Critical
Fix For: No Release
Testing scenario:
Deployed JBoss 5.1.0.GA (with tweaks to the pom during build, see Environment) with a JCA adapter for an external JMS broker, used both ActiveMQ 5.3.0 and HornetQ 2.0.0, both clustered and standalone. Also tried an embedded HornetQ broker with the same results. Deployed an ear that has a simple MDB requiring container managed transactions listening to a queue with max sessions set to 2 and a simple jsp to publish an arbitrary number of text messages to that queue. The MDB simply prints the text information provided by the message, but also has a hard-coded 1 second pause for every even numbered message.
When I shut down JBoss while messages are still being consumed, the BlockContainerShutdownInterceptor starts throwing DispatcherConnectExceptions, as the EJB container has been stopped or is in the process of being stopped. However, it doesn't mark the transaction for rollback itself, and MessageInflowLocalProxy.delivery() only marks the transaction for rollback if the invocation chain throws an Error or RuntimeException. Thus, in this case, JBoss failed to deliver the message to the MDB, but committed the transaction. According to the spec, for an MDB with a container managed transaction, the message should be ACK'd to the broker if the transaction successfully commits, and both the ActiveMQ and HornetQ JCA implementations dutifully do this, resulting in all messages that were attempted to be delivered after the EJB container shutdown being lost.
When the BlockContainerShutdownInterceptor detects that the EJB container has been shutdown, it needs to take an action that will ensure the transaction is marked for rollback. After parsing through the code involved in the interceptor chain, I can see a few potential solutions:
* Have BlockContainerShutdownInterceptor.invoke() call TxUtil.getTransactionManager().setRollbackOnly() before it would throw a DispatcherConnectException. Probably need to consume any exception thrown from setRollbackOnly() and log it first I suppose, although it's always a bit odd when you get an exception thrown when you intend to throw an exception anyway for a different reason.
* Have BlockContainerShutdownInterceptor.invoke() put some state on the Invocation to indicate that delivery is being blocked. MessagingContainer.localInvoke() could then take some action based on this state to ensure the transaction is rolled back, either rolling it back itself or notifying its caller that the transaction should be rolled back. A bit odd here if BlockContainerShutdownInterceptor.invoke() continues to throw an exception, as there would be data about the exception being passed back outside the exception though.
* Have MessageInflowLocalProxy handle DispatcherConnectExceptions. It might be better to introduce an additional class, say InvocationInterruptedException that DispatcherConnectException could extend, to allow for the possibility that invocations may be interrupted for other reasons, allowing MessageInflowLocalProxy to not care as much about the particular reason invocation was halted, but still be able to roll back the transaction whenever it is.
I slightly favor the third approach based on what I've seen of that portion of the code so far, so I will probably work to put together a patch file along those lines. This is the first time I've delved deeply into the JBoss source code though. If I can find some examples of test cases in this part of the code base, I'll attempt to put together a verifying test case as well.
I marked the priority as Critical, based on the guidelines, as this is resulting in data loss and as far as I best understand the spec is a violation of the spec.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (JBLOGGING-77) FileHandler which rolls the file when a system property changes.
by Ondrej Zizka (Created) (JIRA)
FileHandler which rolls the file when a system property changes.
----------------------------------------------------------------
Key: JBLOGGING-77
URL: https://issues.jboss.org/browse/JBLOGGING-77
Project: JBoss Logging
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: jboss-logging-jdk
Reporter: Ondrej Zizka
Assignee: David Lloyd
I'd make use of a FileHandler which would roll the file when a system property changes.
For use case, see ARQ-710.
The handler would have a property called, say, fileNameFormat, which would be a string like:
{code}
my-server-log-${arq.currentTest}-${arq.containerId}.txt
{code}
The handler would replace the string every time and compare with previous; when different, it would roll the file.
It would not be super efficient but good enough for the purposes of testing.
(It would not be the default handler, only configured on demand.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (AS7-3369) CLONE - jboss-admin tool doesn't return non zero code when command fails to execute
by Rostislav Svoboda (JIRA)
Rostislav Svoboda created AS7-3369:
--------------------------------------
Summary: CLONE - jboss-admin tool doesn't return non zero code when command fails to execute
Key: AS7-3369
URL: https://issues.jboss.org/browse/AS7-3369
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management, Scripts
Affects Versions: 7.1.0.CR1b
Reporter: Rostislav Svoboda
Assignee: Brian Stansberry
Priority: Critical
Fix For: 7.1.0.Final
Jboss-admin tool doesn't return non zero code when command fails to execute.
It's necessary for us to know if command was executed properly or not. Parsing output is unacceptable.
{code}
[rsvoboda@rosta-ntb ~]$ TESTING/jboss-as7/bin/jboss-admin.sh --connect command=:shutdown
The controller is not available at localhost:9999
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[rsvoboda@rosta-ntb ~]$ echo $?
0
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (AS7-3340) NPE during stop of service jboss.jacorb.poa-service.rootpoa
by Pavel Janousek (JIRA)
[ https://issues.jboss.org/browse/AS7-3340?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek commented on AS7-3340:
-------------------------------------
Stefan,
if I'm not wrong now, it seems that DR10 is using jacorb-2.3.1jboss-patch-05.jar.
> NPE during stop of service jboss.jacorb.poa-service.rootpoa
> -----------------------------------------------------------
>
> Key: AS7-3340
> URL: https://issues.jboss.org/browse/AS7-3340
> Project: Application Server 7
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Stefan Guilhen
> Priority: Critical
> Fix For: 7.1.0.Final
>
>
> There is randomly occured NPE when stopping EAP a bit quickly after it started.
> {code}
> 15:55:17,151 ERROR [org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started (with errors) in 8066ms - Started 132 of 222 services (20 services failed or missing dependencies, 68 services are passive or on-demand)
> ^C15:55:19,867 INFO [org.jboss.as.messaging] (MSC service thread 1-1) JBAS011605: Unbound messaging object to jndi name java:/queue/test
> 15:55:19,870 INFO [org.jboss.as.osgi] (MSC service thread 1-8) JBAS011921: Stopping OSGi Framework
> 15:55:19,876 INFO [org.jboss.as.messaging] (MSC service thread 1-7) JBAS011605: Unbound messaging object to jndi name java:/RemoteConnectionFactory
> 15:55:19,878 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) JBAS010409: Unbound data source [java:jboss/datasources/ExampleDS]
> 15:55:19,888 INFO [org.jboss.as.logging] JBAS011503: Restored bootstrap log handlers
> 15:55:19,897 INFO [jacorb.poa] POA IRPOA destroyed
> 15:55:19,898 INFO [jacorb.poa] POA Naming destroyed
> 15:55:19,906 WARN [org.jboss.msc.service.fail] MSC000004: Failure during stop of service jboss.jacorb.poa-service.rootpoa: java.lang.NullPointerException
> at org.jacorb.poa.POA.destroy(Unknown Source)
> at org.jboss.as.jacorb.service.CorbaPOAService.stop(CorbaPOAService.java:187)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1909) [jboss-msc-1.0.1.GA-redhat-1.jar:1.0.1.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1872) [jboss-msc-1.0.1.GA-redhat-1.jar:1.0.1.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_27]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_27]
> at java.lang.Thread.run(Thread.java:662) [:1.6.0_27]
> 15:55:19,910 INFO [jacorb.orb] prepare ORB for shutdown...
> {code}
> As you can see above, I hit Ctrl-C in two seconds after start is done. NPE isn't occurred every time and I didn't see it anytime when EAP was running for a longer time (let say 10 seconds and more).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months