[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 commented on WFLY-2458:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1027738|https://bugzilla.redhat.com/show_bug.cgi?id=1027738] from MODIFIED to ON_QA
> 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
12 years, 6 months
[JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1982?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1982:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1024862|https://bugzilla.redhat.com/show_bug.cgi?id=1024862] from MODIFIED to ON_QA
> NPE in ModelControllerLock
> --------------------------
>
> Key: WFLY-1982
> URL: https://issues.jboss.org/browse/WFLY-1982
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.CR1
>
>
> Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase:
> 22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException
> at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15]
> at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148)
> at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899)
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
--
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
12 years, 6 months
[JBoss JIRA] (WFLY-1924) An EJB on a WildFly server can't call another bean on a second server with remoting and SSL
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1924?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1924:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1025319|https://bugzilla.redhat.com/show_bug.cgi?id=1025319] from MODIFIED to ON_QA
> An EJB on a WildFly server can't call another bean on a second server with remoting and SSL
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-1924
> URL: https://issues.jboss.org/browse/WFLY-1924
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Remoting, Security
> Affects Versions: 8.0.0.Alpha4
> Environment: WildFly 8.0.0.Beta1-SNAPSHOT from Do 22. Aug 2013, 07:48 UTC
> on Linux with Java 1.7.0_25-b15
> Reporter: Bernd Koecke
> Assignee: jaikiran pai
> Fix For: 8.0.0.Beta1
>
>
> I configured two WildFly server, one is the service provider (server), the other one the consumer (client). An EJB on the consumer server tries to call an EJB on the provider server and the remoting connection is secured by SSL. But it doesn't work. I can see the negotiation of the cipher suites and then the communication stops. I get a
> {{javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?}}
> on the provider side. A JavaSE client can call the service provider, but only when SSL_SARTTLS is not set. My current setup is:
> subsystem undertow, default-server:
> {code:xml}
> <https-listener name="defaults" socket-binding="https" security-realm="HttpsRealm"/>
> {code}
> subsystem ejb3:
> {code:xml}
> <remote connector-ref="https-remoting-connector" thread-pool-name="default"/>
> {code}
> Output on the service provider side when the communication stops:
> {noformat}
> [stdout] (default I/O-3) Using SSLEngineImpl.
> [stdout] (default I/O-3) Ignoring unavailable cipher suite: ...
> *** 13 lines more ***
> [stdout] (default I/O-3) Allow unsafe renegotiation: false
> [stdout] (default I/O-3) Allow legacy hello messages: true
> [stdout] (default I/O-3) Is initial handshake: true
> [stdout] (default I/O-3) Is secure renegotiation: false
> [stdout] (default I/O-3) default I/O-3, fatal error: 80: problem unwrapping net record
> [stdout] (default I/O-3) javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> [stdout] (default I/O-3) default I/O-3, SEND TLSv1 ALERT: fatal, description = internal_error
> [stdout] (default I/O-3) default I/O-3, WRITE: TLSv1 Alert, length = 2
> [stdout] (default I/O-3) default I/O-3, called closeOutbound()
> [stdout] (default I/O-3) default I/O-3, closeOutboundInternal()
> [stdout] (default I/O-3) [Raw write]: length = 7
> [stdout] (default I/O-3) 0000: 15 03 01 00 02 02 50 ......P
> {noformat}
> WildFly consumer config
> subsystem remoting, outbound connections:
> {code:xml}
> <remote-outbound-connection name="provider-one-connection" outbound-socket-binding-ref="provider-ejb" security-realm="ProviderOneRealm" protocol="https-remoting">
> <properties>
> <property name="SASL_POLICY_NOANONYMOUS" value="false"/>
> </properties>
> </remote-outbound-connection>
> {code}
> The realms contain the key- and truststores and all passwords are configured.
> The reason for the communication problem comes from the following code.
> The service consumer (or client) WildFly has a remote-outbound-connection in the remoting subsystem config which results in an {{org.jboss.as.remoting.RemoteOutboundConnectionService}}. There is a {{connect()}} method which contains the lines:
> {code:java}
> OptionMap.Builder builder = OptionMap.builder();
> builder.addAll(this.connectionCreationOptions);
> builder.set(SASL_POLICY_NOANONYMOUS, Boolean.FALSE);
> builder.set(SASL_POLICY_NOPLAINTEXT, Boolean.FALSE);
> builder.set(Options.SASL_DISALLOWED_MECHANISMS, Sequence.of(JBOSS_LOCAL_USER));
> builder.set(Options.SSL_ENABLED, true);
> builder.set(Options.SSL_STARTTLS, true);
> return endpoint.connect(uri, builder.getMap(), callbackHandler, sslContext);
> {code}
> My configuration comes from {{this.connectionOptions}} and is overwritten by the defaults. The service consumer will open the connection with {{SSL_STARTTLS==true}}.
> The service provider (or server) WildFly uses an https-listener from the undertow subsystem. Which generates an {{org.wildfly.extension.undertow.HttpsListenerService}}. Method {{startListening(XnioWorker worker,...)}} has the following code:
> {code:java}
> protected void startListening(XnioWorker worker, InetSocketAddress socketAddress, ChannelListener<AcceptingChannel<StreamConnection>> acceptListener) throws IOException {
> SSLContext sslContext = securityRealm.getValue().getSSLContext();
> Builder builder = OptionMap.builder().addAll(SERVER_OPTIONS);
> builder.set(UndertowOptions.MAX_ENTITY_SIZE, maxUploadSize);
> if (securityRealm.getValue().getSupportedAuthenticationMechanisms().contains(AuthMechanism.CLIENT_CERT)) {
> builder.set(SSL_CLIENT_AUTH_MODE, REQUESTED);
> }
> builder.set(Options.USE_DIRECT_BUFFERS,true);
> OptionMap combined = builder.getMap();
> XnioSsl xnioSsl = new JsseXnioSsl(worker.getXnio(), combined, sslContext);
> sslServer = xnioSsl.createSslConnectionServer(worker, socketAddress, (ChannelListener) acceptListener, combined);
> sslServer.resumeAccepts();
> UndertowLogger.ROOT_LOGGER.listenerStarted("HTTPS", getName(), socketAddress);
> }
> {code}
> The OptionMap {{combined}} is used for the {{JsseXnioSsl}} and I can't see a way how to add my own configuration options. The result is that {{SSL_STARTTLS}} is undefined and in {{JsseXnioSsl}} has a method {{connectSsl}} which calls {{openSslConnection}}. There is an event handler build which calls:
> {code:java}
> new JsseSslStreamConnection(connection, JsseSslUtils.createSSLEngine(sslContext, optionMap, destination), socketBufferPool, applicationBufferPool, optionMap.get(Options.SSL_STARTTLS, false));
> {code}
> This sets the flag {{startTls}} of the constructor to false and the member variable {{tls}} in {{org.xnio.ssl.JsseSslStreamConnection}} to true. And when I understand it right, will then the consumer start unencrypted and will only switch to TLS when it is told todo so. But the service provider expectes, because of {{tls==true}}, an encrypted connection right from the beginning. And this generates the above error message/exception. I can reproduce this by using a JavaSE client to call the service provider. This works well when I don't set {{SSL_STARTTLS}} on the client side. But when I set it to {{true}} I get the same behavior like when the client is another WildFly instance.
> [~ctomc] said that on the consumer side in the {{connect()}} method the {{builder.addAll(...)}} should be moved to the end after setting the defaults. Thats the reason for this issue.
> With this solution I can switch off {{SSL_STARTTLS}} on the consumer(client) side.
> Another additional possibility could be to make the provider (server) side configurable that the hard coded options can be overwritten. But I don't know if this fits in the original design.
--
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
12 years, 6 months
[JBoss JIRA] (WFLY-258) mod_cluster schema 2.0
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-258?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar updated WFLY-258:
--------------------------------
Summary: mod_cluster schema 2.0 (was: mod_cluster schema 1.2)
Fix Version/s: 9.0.0.CR1
(was: 8.0.0.CR1)
Moving out to WF 9.
> mod_cluster schema 2.0
> ----------------------
>
> Key: WFLY-258
> URL: https://issues.jboss.org/browse/WFLY-258
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 9.0.0.CR1
>
>
> Changes to the schema
> * simplified names and sync in line with scheme recommendations
> * remove redundant <mod-cluster-config .. /> for good, everything should be element of the subsystem
> * fix load factor enum: no pool metric supported
> * make load-balancers configurable via socket-outbuound-group mechanism
> * add missing load-balancer properties to <proxies/>
--
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
12 years, 6 months
[JBoss JIRA] (DROOLS-333) PHREAK throws ClassCastException on rule with accumulate, temporal reasoning and conditional named consequence
by Duncan Doyle (JIRA)
Duncan Doyle created DROOLS-333:
-----------------------------------
Summary: PHREAK throws ClassCastException on rule with accumulate, temporal reasoning and conditional named consequence
Key: DROOLS-333
URL: https://issues.jboss.org/browse/DROOLS-333
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.CR5
Environment: Mac OS-X 10.9, Oracle Hotspot 1.7.0_45
Reporter: Duncan Doyle
Assignee: Mark Proctor
Reproducer at: https://github.com/DuncanDoyle/DroolsPhreakIssues
Clone the project in the given GitHub repository and run 'mvn -Pphreak clean test' (-Pphreak runs the test with PHREAK, -Preteoo runs the test with ReteOO).
Note that the 'testRG_FLT_03_Two' is intended to fail because, as you can see from the comments in the testcode and the .drl, the logic of the rule is actually wrong. However, it does force
the PHREAK engine to throw a ClassCastException every now and then. Note: not always (it might actually takes a number of test runs to reproduce the ClassCastException. It seems to depend on
how many events you enter into the system in one batch ....)!!
Sometimes 'testRG_FLT_03_Two' fails, with:
Failed tests: testRG_FLT_03_Two(org.jboss.ddoyle.drools.sample.PhreakyTest): Two last event must be in working memory expected:<12> but was:<1>
and sometimes it throws:
<error message="org.drools.core.reteoo.EvalNodeLeftTuple cannot be cast to org.drools.core.reteoo.RuleTerminalNodeLeftTuple" type="java.lang.ClassCastException">java.lang.ClassCastException: org.drools.core.reteoo.EvalNodeLeftTuple cannot be cast to org.drools.core.reteoo.RuleTerminalNodeLeftTuple
at org.drools.core.phreak.PhreakRuleTerminalNode.doLeftTupleUpdate(PhreakRuleTerminalNode.java:155)
at org.drools.core.phreak.PhreakBranchNode.doLeftUpdates(PhreakBranchNode.java:153)
at org.drools.core.phreak.PhreakBranchNode.doNode(PhreakBranchNode.java:31)
at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:364)
at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:162)
at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:117)
at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:199)
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:66)
at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:927)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1187)
at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:957)
at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:931)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233)
at org.jboss.ddoyle.drools.sample.PhreakyTest.testFrequencyTwo(PhreakyTest.java:91)
at org.jboss.ddoyle.drools.sample.PhreakyTest.testRG_FLT_03_Two(PhreakyTest.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
</error>
The behaviour seems a bit random (which concerns me as well, as ReteOO was deterministic and would produce the same results on every test). Note that if I remove the
conditional named consequence construct and split the rule into 2 rules, the behaviour of PHREAK seems deterministic and I get this, expected, error (which is the same error I get with ReteOO):
Failed tests: testRG_FLT_03_Two(org.jboss.ddoyle.drools.sample.PhreakyTest): Two last event must be in working memory expected:<12> but was:<30>
--
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
12 years, 6 months