[JBoss JIRA] (AS7-5322) CLONE - Logging subsystem should not allow assigning an async-handler as a subhandler to itself
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/AS7-5322?page=com.atlassian.jira.plugin.s... ]
James Perkins moved JBPAPP-9663 to AS7-5322:
--------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-5322 (was: JBPAPP-9663)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: (was: EAP 6.0.0 (CR1))
Security: (was: Public)
Fix Version/s: (was: TBD EAP 6)
Docs QE Status: (was: NEW)
> CLONE - Logging subsystem should not allow assigning an async-handler as a subhandler to itself
> -----------------------------------------------------------------------------------------------
>
> Key: AS7-5322
> URL: https://issues.jboss.org/browse/AS7-5322
> Project: Application Server 7
> Issue Type: Bug
> Reporter: Jan Martiska
> Assignee: James Perkins
>
> {noformat}
> [standalone@localhost:9999 /] /subsystem=logging/async-handler=a/:add(queue-length=10)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=logging/async-handler=a/:assign-subhandler(name=a)
> {"outcome" => "success"}
> {noformat}
> The second command should fail. Assigning an async handler to itself leads to a circular dependency, which leads to a fatal error at server boot:
> {noformat}
> 15:00:28,118 ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([
> ("subsystem" => "logging"),
> ("async-handler" => "a")
> ]): org.jboss.msc.service.CircularDependencyException: Service jboss-as has a circular dependency
> at org.jboss.msc.service.ServiceContainerImpl.detectCircularity(ServiceContainerImpl.java:617) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceContainerImpl.detectCircularity(ServiceContainerImpl.java:588) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:562) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2228) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:955) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.logging.handlers.HandlerAddProperties.performRuntime(HandlerAddProperties.java:124)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:50) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.ParallelBootOperationStepHandler.execute(ParallelBootOperationStepHandler.java:161) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:175) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:191) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.server.ServerService.boot(ServerService.java:295)
> at org.jboss.as.server.ServerService.boot(ServerService.java:270)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:156) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
> {noformat}
--
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
11 years, 10 months
[JBoss JIRA] (AS7-5132) Connection timeout to local port 9999 with clustered AS 7.1.1.Final
by Jack Lund (JIRA)
Jack Lund created AS7-5132:
------------------------------
Summary: Connection timeout to local port 9999 with clustered AS 7.1.1.Final
Key: AS7-5132
URL: https://issues.jboss.org/browse/AS7-5132
Project: Application Server 7
Issue Type: Bug
Components: Clustering, Domain Management
Affects Versions: 7.1.1.Final
Environment: Fedora 17 on Amazon EC2
Reporter: Jack Lund
Assignee: Paul Ferraro
A clustered configuration of two AS 7 instances has an issue with the connection to port 9999 timing out when starting up. The instances are configured as per https://docs.jboss.org/author/display/AS71/AS7+Cluster+Howto. On startup, we get the following error randomly for one or more of the server instances:
{quote}
[Server:server-two] 16:36:03,492 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.host.controller.client: org.jboss.msc.service.StartException in service jboss.host.controller.client: java.net.ConnectException: JBAS012144: Could not connect to remote://10.108.25.156:9999. The connection timed out
[Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerServerClient.start(HostControllerServerClient.java:161) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
[Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
[Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
[Server:server-two] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_05]
[Server:server-two] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_05]
[Server:server-two] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_05]
[Server:server-two] Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://nephele-beta-jboss1:9999. The connection timed out
[Server:server-two] at org.jboss.as.protocol.ProtocolChannelClient.connectSync(ProtocolChannelClient.java:155) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
[Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerServerConnection.openChannel(HostControllerServerConnection.java:158) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
[Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerServerConnection.connect(HostControllerServerConnection.java:86) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
[Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerServerClient.start(HostControllerServerClient.java:135) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
[Server:server-two] ... 5 more
{quote}
We usually have to restart the master server instance 10-15 times before all server instances start up without this error, which suggests a race condition between the listening and connecting sockets. Note that this is running on the equivalent of a single-core, fairly slow machine currently, which may be exacerbating the effects.
--
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
11 years, 10 months
[JBoss JIRA] (AS7-4540) Exception thrown in JGroups subsystem when diagnostics address/port and udp address/port are distinct
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created AS7-4540:
----------------------------------------
Summary: Exception thrown in JGroups subsystem when diagnostics address/port and udp address/port are distinct
Key: AS7-4540
URL: https://issues.jboss.org/browse/AS7-4540
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.1.1.Final
Reporter: Richard Achmatowicz
Assignee: Bela Ban
When using JGroups as part of AS7 in the server configuration standalone-ha.xml, upon start up, we receive the exception:
{noformat}
09:52:36,831 ERROR [org.jboss.msc.service.fail] (pool-14-thread-1) MSC00001: Failed to start service jboss.jgroups.channel.web: org.jboss.msc.service.StartException in service jboss.jgroups.channel.web: java.lang.IllegalArgumentException: diagnostics_addr / diagnostics_port and mcast_addr / mcast_port have to be different
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:62) [jboss-as-clustering-common-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26]
Caused by: java.lang.IllegalArgumentException: diagnostics_addr / diagnostics_port and mcast_addr / mcast_port have to be different
at org.jgroups.protocols.UDP.createSockets(UDP.java:359) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.UDP.start(UDP.java:224) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:938) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.JChannel.startStack(JChannel.java:841) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.JChannel.connect(JChannel.java:277) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.JChannel.connect(JChannel.java:261) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:44) [jboss-as-clustering-jgroups-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:59) [jboss-as-clustering-common-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
{noformat}
even when the address / port combination for udp and the address / port combination for diagnostics are distinct:
{noformat}
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
...
<socket-binding name="jgroups-diagnostics" port="0" multicast-address="ff0e::1" multicast-port="7500"/>
<socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:ff0e::1}" multicast-port="45700"/>
<socket-binding name="jgroups-tcp" port="7600"/>
<socket-binding name="jgroups-tcp-fd" port="57600"/>
<socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:ff0e::1}" multicast-port="45688"/>
<socket-binding name="jgroups-udp-fd" port="54200"/>
<socket-binding name="modcluster" port="0" multicast-address="ff0e::1" multicast-port="23364"/>
...
</socket-binding-group>
{noformat}
The expected behaviour is that as long as the ports are distinct, we should be able to use the same mcast address for both udp and diagnostics.
--
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
11 years, 10 months
[JBoss JIRA] (JBRULES-3600) DroolsSpringTransactionManager throws NPE instead of handling JPA transaction state
by John Bize (JIRA)
John Bize created JBRULES-3600:
----------------------------------
Summary: DroolsSpringTransactionManager throws NPE instead of handling JPA transaction state
Key: JBRULES-3600
URL: https://issues.jboss.org/browse/JBRULES-3600
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-spring
Affects Versions: 5.3.1.Final
Environment: RHEL5, Weblogic 10.3.4
Reporter: John Bize
Assignee: Mark Proctor
I posted on this in the forums: https://community.jboss.org/message/751900#751900 but really didn't receive a useful reply.
Since there are clearly bugs in the DroolsSpringTransactionManager, I am posting this bug report too. I have covered them in the forum post, although I do not no if my mitigating solution is correct even though it seems to work.
The DroolsSpringTransactionManager has two inherent NullPointerExceptions.
First, (from my post): There is an obvious bug in the begin() method in that if the call to getStatus() returns STATUS_NO_TRANSACTION, which it will if the wrapped tm (ptm) is null, it immediately dereferences the null ptm. (this.ptm.getTransaction(td)). I'm not too woried about this one as it seems rather unlikely.
However, the problem I am seeing is a NPE masking an IllegalStateException which should probably be caught to return a valid or UNKNOWN state. The issue (in the getStatus() method) is that it's making the call "transaction = this.ptm.getTransaction(td);" which is occasionally throwing an "IllegalStateException: Transaction already active," wrapped in an outer RuntimeException and dropping down to the finally block. There, the still null transaction is committed, throwing an NPE that masks the original exception. To mitigate this, I added a catch RuntimeException and if the cause is an IllegalStateException, I return STATUS_UNKNOWN. In the finally block, I also ensure that I don't try to commit a null transaction.
A better description of the second bug and mitigation are in the referenced post.
--
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
11 years, 10 months
[JBoss JIRA] (AS7-4881) Remote EJB clients hanging after EJBClient.createSession when using DIST
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4881:
-----------------------------------
Summary: Remote EJB clients hanging after EJBClient.createSession when using DIST
Key: AS7-4881
URL: https://issues.jboss.org/browse/AS7-4881
Project: Application Server 7
Issue Type: Bug
Components: Clustering, EJB
Affects Versions: 7.1.2.Final (EAP)
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Critical
Fix For: 7.1.3.Final (EAP)
We are seeing that in stress tests (positive test, no failures), the clients hang when using DIST mode; both SYNC and ASYNC.
The clients hang in method [1]; there is nothing suspicious on the server side. [2]
The client has no knowledge about repl/dist topology, thus this should be a server-side issue.
As of filing, we are investigating the issue.
Job
https://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Performance-Cluste...
Client code
https://svn.devel.redhat.com/repos/jboss-qa/load-testing/sf-components/pr...
App code
https://github.com/rhusar/clusterbench
[1]
{noformat}
"Runner - 1279" daemon prio=10 tid=0x00007f4388950000 nid=0x73df in Object.wait() [0x00007f423ed29000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at org.xnio.AbstractIoFuture.awaitInterruptibly(AbstractIoFuture.java:123)
- locked <0x00000006c0285ad0> (a java.lang.Object)
at org.jboss.ejb.client.remoting.IoFutureHelper$1.get(IoFutureHelper.java:57)
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.openSession(RemotingConnectionEJBReceiver.java:236)
at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:163)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:135)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:113)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:96)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.initSession(StatefulSBProcessorFactoryImpl.java:148)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:58)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
[1]
{noformat}
"EJB default - 10" prio=10 tid=0x00007fefcc059000 nid=0x308b waiting on condition [0x00007fefa7a33000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000006bfe65cc8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
{noformat}
--
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
11 years, 10 months