[JBoss JIRA] (JGRP-1733) UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1733?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1733:
--------------------------------
Can't do this for batches: if we successfully add a batch, this only means that at least 1 message was added. Therefore, we still have to check for each message whether it has the OOB_DELIVERED flag set and cannot set it in all messages of a batch up front.
So we can do this for single messages, but not for message batches.
> UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table
> ------------------------------------------------------------------------------------------------
>
> Key: JGRP-1733
> URL: https://issues.jboss.org/browse/JGRP-1733
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, OOB messages are added to the table, then passed up unless they're already marked as OOB_DELIVERED. This could happen if another thread removed messages from the table and passed them up before the current thread could pass the message up.
> However, this work stealing might be detrimental: if the stealing thread batched messages up and 'stole' OOB messages (and those messages blocked), then the rest of the batch would be blocked from delivery.
> This is the same though if a batch only contains regular messages...
> However, this would make things simpler as threads from the regular pool would never deliver OOB messages (but not the other way round, OOB thread could still deliver regular messages).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (DROOLS-326) Drools plugin Rete Tree viewer does not work with Conditional Named Consequence expressions
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-326?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated DROOLS-326:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1027765
> Drools plugin Rete Tree viewer does not work with Conditional Named Consequence expressions
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-326
> URL: https://issues.jboss.org/browse/DROOLS-326
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR5
> Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45
> Reporter: Duncan Doyle
> Assignee: Mark Proctor
> Labels: conditional, consequence, eclipse, named, plugin, rete, tree, view
>
> See this project, which is based on the standard Sample.drl of the Drools Eclipse plugin: https://github.com/DuncanDoyle/DroolsConditionalNamedConsequenceIssue
> The 'src/main/resources/rules/Sample.drl' contains a rule which uses a 'Conditional Named Consequence' construct. When clicking the Rete Tree tab in the DRL editor I receive this error:
> Rete Tree Build Error!
> Reason:
> org.drools.core.RuntimeDroolsException:
> java.lang.reflect.InvocationTargetException : [Rete(0)]
> And the Rete Tree is not displayed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1733) UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1733?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1733:
---------------------------
Fix Version/s: (was: 3.4.1)
> UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table
> ------------------------------------------------------------------------------------------------
>
> Key: JGRP-1733
> URL: https://issues.jboss.org/browse/JGRP-1733
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, OOB messages are added to the table, then passed up unless they're already marked as OOB_DELIVERED. This could happen if another thread removed messages from the table and passed them up before the current thread could pass the message up.
> However, this work stealing might be detrimental: if the stealing thread batched messages up and 'stole' OOB messages (and those messages blocked), then the rest of the batch would be blocked from delivery.
> This is the same though if a batch only contains regular messages...
> However, this would make things simpler as threads from the regular pool would never deliver OOB messages (but not the other way round, OOB thread could still deliver regular messages).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1733) UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table
by Bela Ban (JIRA)
Bela Ban created JGRP-1733:
------------------------------
Summary: UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table
Key: JGRP-1733
URL: https://issues.jboss.org/browse/JGRP-1733
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.4.1, 3.5
Currently, OOB messages are added to the table, then passed up unless they're already marked as OOB_DELIVERED. This could happen if another thread removed messages from the table and passed them up before the current thread could pass the message up.
However, this work stealing might be detrimental: if the stealing thread batched messages up and 'stole' OOB messages (and those messages blocked), then the rest of the batch would be blocked from delivery.
This is the same though if a batch only contains regular messages...
However, this would make things simpler as threads from the regular pool would never deliver OOB messages (but not the other way round, OOB thread could still deliver regular messages).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1732) UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
by Bela Ban (JIRA)
Bela Ban created JGRP-1732:
------------------------------
Summary: UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
Key: JGRP-1732
URL: https://issues.jboss.org/browse/JGRP-1732
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.4.1, 3.5
In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and internal) add messages to the table, then grab as many (ordered) messages as possible from the table and pass them up.
This could lead to the case where an internal thread passes up regular or OOB messages, which might block. There's a (small) chance that this exhausts the internal thread pool.
Internal threads should therefore never block, and never steal work from other thread pools.
SOLUTION:
* An internal thread only adds the message to the table and passes it up if in order
* If the internal message is OOB, it is passed up and then the thread returns
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (DROOLS-325) Conditional named consequences don't allow references to public fields
by Duncan Doyle (JIRA)
[ https://issues.jboss.org/browse/DROOLS-325?page=com.atlassian.jira.plugin... ]
Duncan Doyle reopened DROOLS-325:
---------------------------------
It is actually a problem when referencing the 'Message.HELLO' and 'Message.GOODBYE' fields when using the "java" dialect. It works when using "mvel". I've updated the reproducer in my GitHub. See Mario's last comment for an explanation of the actual problem.
> Conditional named consequences don't allow references to public fields
> ----------------------------------------------------------------------
>
> Key: DROOLS-325
> URL: https://issues.jboss.org/browse/DROOLS-325
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR5
> Environment: Mac OS-X 10.9, JBoss Developer Studio, Oracle Hotspot 1.7.0_45
> Reporter: Duncan Doyle
> Assignee: Mario Fusco
> Labels: conditional, consequences, named
>
> See this project, which is based on the standard Sample.drl of the Drools Eclipse plugin:
> https://github.com/DuncanDoyle/DroolsConditionalNamedConsequenceIssue
> As you can see in the 'src/main/resources/rules/Sample.drl', the first rule, which is commented out, references the public fields Message.HELLO and Message.GOODBYE in the conditional 'if' statement, i.e. "if (m.status == Message.HELLO) break [sayHello]". The compiler throws this error:
> Rule Compilation error HELLO cannot be resolved or is not a field.
> When I use the actual value of Message.HELLO and Message.GOODBYE, as shown in the second rule 'if (m.getStatus() == 0) break [sayHello]', everything works fine.
> Please note that there is also an issue with using MVEL expressions in Conditional named consequences (as you can see in my example rules). That issue is tracked in JIRA DROOLS-324.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2459) Serialization of java.time classes on EJB calls fails
by Steven Pessall (JIRA)
Steven Pessall created WFLY-2459:
------------------------------------
Summary: Serialization of java.time classes on EJB calls fails
Key: WFLY-2459
URL: https://issues.jboss.org/browse/WFLY-2459
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB
Affects Versions: 8.0.0.Beta1
Environment: JBoss AS 7.2
Reporter: Steven Pessall
Assignee: David Lloyd
First of all: We stumbled on the issue desribed here on JBoss AS 7.2, but the relevant source coude seems to be unchanged in WildFly.
In method org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation() a ClonerConfiguration object is programmatically created for the configuration of a org.jboss.marshalling.cloner.SerializingCloner instance.
The default configuration causes IllegalAccessExceptions when serializing classes of the new java.time package (Java 8) respectively for the org.threeten library (Java 7 backport of JSR-310).
Stacktrace:
java.lang.RuntimeException: JBAS014154: Failed to marshal EJB parameters
at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:270) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:259) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:170) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
at org.jboss.ejb.client.EJBHomeCreateInterceptor.handleInvocation(EJBHomeCreateInterceptor.java:79) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:177) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:161) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:124) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
at com.sun.proxy.$Proxy124.getList(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:267) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:52) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:105) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at kam.cmd.boundary.access.MDListService$431771952$Proxy$_$$_Weld$Proxy$.getList(MDListService$431771952$Proxy$_$$_Weld$Proxy$.java) [cmd-core-boundary-0.0.10-SNAPSHOT.jar:]
at kam.cmd.client.AbstractMasterDataClient.getData(AbstractMasterDataClient.java:57) [cmd-core-client-base-0.0.10-SNAPSHOT.jar:]
at kam.cmd.client.ejb.EJBMasterDataClient$Proxy$_$$_WeldClientProxy.getData(EJBMasterDataClient$Proxy$_$$_WeldClientProxy.java) [cmd-core-client-ejb-0.0.10-SNAPSHOT.jar:]
at kam.cmd.resourcebrowser.BackwareBrowser.getRes(BackwareBrowser.java:37) [classes:]
at kam.cmd.resourcebrowser.BackwareBrowser$Proxy$_$$_WeldClientProxy.getRes(BackwareBrowser$Proxy$_$$_WeldClientProxy.java) [classes:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.5.Final.jar:]
at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) [resteasy-jaxrs-2.3.5.Final.jar:]
at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) [resteasy-jaxrs-2.3.5.Final.jar:]
at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) [resteasy-jaxrs-2.3.5.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) [resteasy-jaxrs-2.3.5.Final.jar:]
... 19 more
Caused by: java.io.InvalidClassException: org.threeten.bp.Ser; Illegal access exception occurred accessing the constructor: java.lang.IllegalAccessException: Class org.jboss.marshalling.reflect.PublicReflectiveCreator can not access a member of class org.threeten.bp.Ser with modifiers "public"
at org.jboss.marshalling.reflect.PublicReflectiveCreator.create(PublicReflectiveCreator.java:43)
at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:240)
at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:174)
at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:134)
at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:268) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
... 57 more
The cause of the problem is, that the default configuration of the SerializingCloner uses the class org.jboss.marshalling.reflect.PublicReflectiveCreator for the instantiation of the serialized classes, which tries to directly call the default constructor. While the class org.threeten.bp.Ser does have a public constructor, the class itself only has package visibility, causing the IllegalAccessException.
There is another implementation org.jboss.marshalling.reflect.ReflectiveCreator, which actually forces the accessibility of the constructor to be true. If an instance of this class was configured as externalizedCreator in ClonerConfiguration, the problem would be solved. But currently there is no way to influence the ClonerConfiguration used by the class LocalEjbReceiver.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2458) Re-deployment of a clustered application fail due to race-condition with infinispan
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2458?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-2458:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1027738
> Re-deployment of a clustered application fail due to race-condition with infinispan
> -----------------------------------------------------------------------------------
>
> Key: WFLY-2458
> URL: https://issues.jboss.org/browse/WFLY-2458
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Server
> Affects Versions: 8.0.0.Beta1
> Environment: Clustered Standalone server with one clustered EAR
> Reporter: Wolf-Dieter Fink
> Assignee: Paul Ferraro
> Labels: deployer
> Attachments: appone.ear
>
>
> If a clustered application should be redeployed it looks like that infinispan is not able to stop complete until the deployer finish undeployment and start to deploy the new application. See the Exception below.
> The behaviour is the same for managed or unmanged deployments.
> If it is unmanaged the .failed marker file exists.
> After the failure the application is shown in the mgmt console without deployed Beans.
> A second deploy attempt will be successfull
> 11:22:36,397 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,shared=udp) ISPN000094: Received new cluster view: [home/ejb|1] (2) [home/ejb, node2/ejb]
> 11:22:52,746 INFO [org.jboss.weld.deployer] (MSC service thread 1-11) JBAS016009: Stopping weld service for deployment appone.ear
> 11:22:52,751 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 58) ISPN000029: Passivating all entries to disk
> 11:22:52,752 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 58) ISPN000030: Passivated 0 entries in 0 milliseconds
> 11:22:52,759 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 58) JBAS010282: Stopped repl cache from ejb container
> 11:22:52,765 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 60) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> 11:22:52,768 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting and closing JGroups Channel
> 11:22:52,771 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment null (runtime-name: ejb.jar) in 36ms
> 11:22:52,772 INFO [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015877: Stopped deployment appone.ear (runtime-name: appone.ear) in 39ms
> 11:22:52,773 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "appone.ear" (runtime-name: "appone.ear")
> 11:22:52,778 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "null" (runtime-name: "ejb.jar")
> 11:22:52,792 INFO [org.jboss.weld.deployer] (MSC service thread 1-12) JBAS016002: Processing weld deployment appone.ear
> 11:22:52,803 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016002: Processing weld deployment ejb.jar
> 11:22:52,805 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-5) JNDI bindings for session bean named AppOneBean in deployment unit subdeployment "ejb.jar" of deployment "appone.ear" are as follows:
> java:global/appone/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne
> java:app/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne
> java:module/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne
> java:jboss/exported/appone/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne
> java:global/appone/ejb/AppOneBean
> java:app/ejb/AppOneBean
> java:module/AppOneBean
> 11:22:52,807 INFO [org.jboss.weld.deployer] (MSC service thread 1-11) JBAS016005: Starting Services for CDI deployment: appone.ear
> 11:22:52,811 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016008: Starting weld service for deployment appone.ear
> 11:22:53,087 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher
> 11:22:53,118 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 60) ISPN000078: Starting JGroups Channel
> 11:22:53,119 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 60) MSC000001: Failed to start service jboss.infinispan.ejb.global-component-registry: org.jboss.msc.service.StartException in service jboss.infinispan.ejb.global-component-registry: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:241)
> at org.jboss.as.clustering.infinispan.subsystem.GlobalComponentRegistryService.start(GlobalComponentRegistryService.java:33)
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 4 more
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:219)
> ... 6 more
> Caused by: org.infinispan.commons.CacheException: Unable to start JGroups Channel
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:196)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:185)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> ... 11 more
> Caused by: java.lang.IllegalStateException: channel is closed
> at org.jgroups.JChannel.checkClosed(JChannel.java:902)
> at org.jgroups.JChannel._preConnect(JChannel.java:522)
> at org.jgroups.JChannel.connect(JChannel.java:284)
> at org.jgroups.JChannel.connect(JChannel.java:275)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:194)
> ... 17 more
> 11:22:53,128 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) JBAS016009: Stopping weld service for deployment appone.ear
> 11:22:53,137 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015877: Stopped deployment null (runtime-name: ejb.jar) in 11ms
> 11:22:53,138 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment appone.ear (runtime-name: appone.ear) in 12ms
> 11:22:53,143 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.CREATE (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformation, service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START, service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.VIEW."org.jboss.as.quickstarts.ejb.multi.server.app.AppOne".REMOTE]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".deploymentCompleteService, service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformationStart]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.VIEW."org.jboss.as.quickstarts.ejb.multi.server.app.AppOne".REMOTE (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformation, service jboss.naming.context.java.module.appone.ejb."AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne", service jboss.naming.context.java.global.appone.ejb.AppOneBean, service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START, JBAS014799: ... and 5 more ]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.WeldInstantiator (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".deploymentCompleteService (missing) dependents: [service jboss.deployment.unit."appone.ear".deploymentCompleteService]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START, service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformationStart]
> service jboss.naming.context.java.app.appone.ejb.AppOneBean (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.app.appone.ejb."AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne" (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.BeanManager (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultContextService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultDataSource (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultManagedExecutorService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultManagedScheduledExecutorService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultManagedThreadFactory (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.EJBContext (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.TimerService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.TransactionSynchronizationRegistry (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.UserTransaction (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.env (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.env."org.jboss.as.quickstarts.ejb.multi.server.app.AppOneBean".context (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService, service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.naming.context.java.global.appone.ejb.AppOneBean (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.global.appone.ejb."AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne" (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.module.appone.ejb.AppOneBean (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.module.appone.ejb."AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne" (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.module.appone.ejb.BeanManager (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.naming.context.java.module.appone.ejb.env (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> JBAS014777: Services which failed to start: service jboss.infinispan.ejb.global-component-registry
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months