[JBoss JIRA] (WFLY-5893) Standard way of checking if the request controller is available for extension usage is incorrect
by James Perkins (JIRA)
James Perkins created WFLY-5893:
-----------------------------------
Summary: Standard way of checking if the request controller is available for extension usage is incorrect
Key: WFLY-5893
URL: https://issues.jboss.org/browse/WFLY-5893
Project: WildFly
Issue Type: Bug
Components: Batch, EE
Reporter: James Perkins
Assignee: James Perkins
Both batch and EE check if the resource controller is present by checking the model {{context.getOriginalRootResource().hasChild(PathElement.pathElement(ModelDescriptionConstants.SUBSYSTEM, RequestControllerExtension.SUBSYSTEM_NAME));}}. It should {{context.readResourceFromRoot(PathAddress.EMPTY_ADDRESS)}} or better yet use the provided capability.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5892) JGroups throws UnknownHostException on processing IPv6 zone interface id with a subinterface
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5892?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek moved JBEAP-2510 to WFLY-5892:
--------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5892 (was: JBEAP-2510)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Clustering
(was: Clustering)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.CR5
(was: 7.0.0.ER3)
> JGroups throws UnknownHostException on processing IPv6 zone interface id with a subinterface
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5892
> URL: https://issues.jboss.org/browse/WFLY-5892
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Environment: Solaris 11 Sparc JDK8, IPv6
> Reporter: Michal Karm Babacek
> Assignee: Bela Ban
> Priority: Critical
>
> JGroups pick up IPv6 zone id index and it fails at translating it into an interface name:
> h3. Address
> * address used {{2620:52:0:105f:0:0:ffff:188%net0:2}}
> * {{Caused by: java.net.UnknownHostException: no such interface net0:2}}
> h3. Configuration
> {code}
> <interfaces>
> <interface name="management">
> <inet-address value="2620:52:0:105f::ffff:188"/>
> </interface>
> <interface name="public">
> <inet-address value="2620:52:0:105f::ffff:188"/>
> </interface>
> </interfaces>
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> <socket-binding name="https" port="${jboss.https.port:8443}"/>
> <socket-binding name="jgroups-mping" port="0" multicast-address="ff02::12" 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="ff02::12" multicast-port="45688"/>
> <socket-binding name="jgroups-udp-fd" port="54200"/>
> <socket-binding name="modcluster" port="0" multicast-address="ff02::a" multicast-port="32983"/>
> <socket-binding name="txn-recovery-environment" port="4712"/>
> <socket-binding name="txn-status-manager" port="4713"/>
> <outbound-socket-binding name="mail-smtp">
> <remote-destination host="localhost" port="25"/>
> </outbound-socket-binding>
> </socket-binding-group>
> {code}
> h3. Exception
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.jgroups.channel.ee: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> at org.wildfly.clustering.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:80)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:640)
> at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:98)
> at org.wildfly.clustering.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:78)
> ... 5 more
> Caused by: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1154)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:445)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:853)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:95)
> at org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:92)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> ... 7 more
> Caused by: java.lang.Exception: Conversion of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1148)
> ... 17 more
> Caused by: java.net.UnknownHostException: no such interface net0:2
> at java.net.Inet6Address.initstr(Inet6Address.java:487)
> at java.net.Inet6Address.<init>(Inet6Address.java:408)
> at java.net.InetAddress.getAllByName(InetAddress.java:1181)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at java.net.InetAddress.getByName(InetAddress.java:1076)
> at org.jgroups.conf.PropertyConverters$Default.convert(PropertyConverters.java:288)
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:81)
> ... 18 more
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "ee")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.jgroups.channel.ee" => "org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> Caused by: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> Caused by: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> Caused by: java.lang.Exception: Conversion of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 failed
> Caused by: java.net.UnknownHostException: no such interface net0:2"}}
> {code}
> h3. Interfaces on the Solaris 11 box
> See my undermentioned example:
> {code}
> [mbabacek@dev33 ~]$ groovy https://gist.githubusercontent.com/Karm/ec21b42b59f8889f976f/raw/951f01c6...
> Iface Display name: net4
> Iface Name: net4
> Iface Display name: net0
> Iface Name: net0
> Subiface Display name: net0:7
> Subiface Name: net0:7
> Subiface Display name: net0:6
> Subiface Name: net0:6
> Subiface Display name: net0:5
> Subiface Name: net0:5
> Subiface Display name: net0:4
> Subiface Name: net0:4
> Subiface Display name: net0:3
> Subiface Name: net0:3
> Subiface Display name: net0:2
> Subiface Name: net0:2
> Subiface Display name: net0:1
> Subiface Name: net0:1
> Iface Display name: lo0
> Iface Name: lo0
> {code}
> WDYT? Why should JGroups even try to do that?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5812) HA singleton service shortly unreachable after being started on a node
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5812?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned WFLY-5812:
----------------------------------
Assignee: Paul Ferraro (was: Radoslav Husar)
> HA singleton service shortly unreachable after being started on a node
> ----------------------------------------------------------------------
>
> Key: WFLY-5812
> URL: https://issues.jboss.org/browse/WFLY-5812
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
>
> Seen in our failover tests, jvmkill scenario with HA singleton service
> Timeline:
> - perf21 goes down (jvmkill)
> - perf18 receives new cluster view
> - perf18 is elected as the singleton provider of the service
> - the singleton service is started on perf18
> - EJB Invocation fails few times - see the stacktrace below
> Can you please check if the issue is in the [TestingSingletonService|https://github.com/Ladicek/SingletonServiceTest-e...] implementation or in the EAP server?
> {code}
> [JBossINF] [0m[0m22:28:23,791 INFO [org.wildfly.clustering.server] (notification-thread--p1-t1) WFLYCLSV0003: perf18 elected as the singleton provider of the jboss.test.myservice service
> [JBossINF] [0m[0m22:28:23,794 INFO [org.wildfly.clustering.server] (notification-thread--p1-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.test.myservice service
> [JBossINF] [0m[0m22:28:23,797 INFO [org.jboss.test.singletonservice.TestingSingletonService] (MSC service thread 1-7) Start service 'org.jboss.test.singletonservice.TestingSingletonService'
> [JBossINF] [0m[0m22:28:23,798 INFO [org.jboss.test.singletonservice.TestingSingletonService] (MSC service thread 1-7) Service started on perf18
> [JBossINF] [0m[31m22:28:23,824 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 2) WFLYEJB0034: EJB Invocation failed on component ServiceAccessBean for method public abstract java.lang.String org.jboss.test.singletonservice.ServiceAccess.getNodeNameOfService(): javax.ejb.EJBException: java.lang.IllegalStateException: java.util.concurrent.ExecutionException: java.lang.reflect.InvocationTargetException
> [JBossINF] at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
> [JBossINF] at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> [JBossINF] at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> [JBossINF] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> [JBossINF] at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> [JBossINF] at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> [JBossINF] at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> [JBossINF] at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:318)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201)
> [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [JBossINF] Caused by: java.lang.IllegalStateException: java.util.concurrent.ExecutionException: java.lang.reflect.InvocationTargetException
> [JBossINF] at org.wildfly.clustering.server.singleton.CacheSingletonServiceBuilder.getRemoteValueRef(CacheSingletonServiceBuilder.java:329)
> [JBossINF] at org.wildfly.clustering.server.singleton.CacheSingletonServiceBuilder.getValue(CacheSingletonServiceBuilder.java:281)
> [JBossINF] at org.wildfly.clustering.service.AsynchronousServiceBuilder.getValue(AsynchronousServiceBuilder.java:92)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
> [JBossINF] at org.jboss.test.singletonservice.ServiceAccessBean.getNodeNameOfService(ServiceAccessBean.java:20)
> [JBossINF] at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> [JBossINF] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [JBossINF] at java.lang.reflect.Method.invoke(Method.java:497)
> [JBossINF] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> [JBossINF] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> [JBossINF] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> [JBossINF] at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> [JBossINF] at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> [JBossINF] at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> [JBossINF] at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> [JBossINF] ... 41 more
> [JBossINF] Caused by: java.util.concurrent.ExecutionException: java.lang.reflect.InvocationTargetException
> [JBossINF] at org.wildfly.clustering.server.dispatcher.SimpleCommandResponse.<init>(SimpleCommandResponse.java:43)
> [JBossINF] at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcher.createCommandResponse(ChannelCommandDispatcher.java:206)
> [JBossINF] at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcher.executeOnCluster(ChannelCommandDispatcher.java:94)
> [JBossINF] at org.wildfly.clustering.server.singleton.CacheSingletonServiceBuilder.getRemoteValueRef(CacheSingletonServiceBuilder.java:298)
> [JBossINF] ... 73 more
> [JBossINF] Caused by: java.lang.reflect.InvocationTargetException
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:464)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:377)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:250)
> [JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:684)
> [JBossINF] at org.jgroups.JChannel.up(JChannel.java:738)
> [JBossINF] at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1029)
> [JBossINF] at org.jgroups.protocols.FORK.up(FORK.java:133)
> [JBossINF] at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:383)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:394)
> [JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1045)
> [JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> [JBossINF] at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:435)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.deliver(NAKACK2.java:961)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:840)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618)
> [JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> [JBossINF] at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> [JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> [JBossINF] at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> [JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:295)
> [JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
> [JBossINF] at org.jgroups.protocols.TP$3.run(TP.java:1511)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] Caused by: java.lang.IllegalStateException
> [JBossINF] at org.jboss.test.singletonservice.TestingSingletonService.getValue(TestingSingletonService.java:30)
> [JBossINF] at org.jboss.test.singletonservice.TestingSingletonService.getValue(TestingSingletonService.java:17)
> [JBossINF] at org.wildfly.clustering.server.singleton.CacheSingletonServiceBuilder.getValueRef(CacheSingletonServiceBuilder.java:288)
> [JBossINF] at org.wildfly.clustering.server.singleton.SingletonValueCommand.execute(SingletonValueCommand.java:31)
> [JBossINF] at org.wildfly.clustering.server.singleton.SingletonValueCommand.execute(SingletonValueCommand.java:26)
> [JBossINF] at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.handle(ChannelCommandDispatcherFactory.java:120)
> [JBossINF] at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:502)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:460)
> [JBossINF] ... 25 more
> {code}
> Link:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-jvmki...
> Link to source of TestingSingletonService:
> https://github.com/Ladicek/SingletonServiceTest-ejb/blob/master/src/main/...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5891) The standard host.xml configs include useless permgen settings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5891?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-5891:
-----------------------------------
Description:
Our standard host.xml files include permgen settings. Our software just ignores them on JDK 8 or later, and we only run on 8 or later, so having these settings in our standard configs is just misleading.
WFCORE-1151 attempted to fix this via a patch to core, but apparently the settings remain. So probably they are being added in some feature pack in full as well.
was:Our standard host.xml files include permgen settings. Our software just ignores them on JDK 8 or later, and we only run on 8 or later, so having these settings in our standard configs is just misleading.
> The standard host.xml configs include useless permgen settings
> --------------------------------------------------------------
>
> Key: WFLY-5891
> URL: https://issues.jboss.org/browse/WFLY-5891
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 10.0.0.CR5
>
>
> Our standard host.xml files include permgen settings. Our software just ignores them on JDK 8 or later, and we only run on 8 or later, so having these settings in our standard configs is just misleading.
> WFCORE-1151 attempted to fix this via a patch to core, but apparently the settings remain. So probably they are being added in some feature pack in full as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5891) The standard host.xml configs include useless permgen settings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5891?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved JBEAP-2508 to WFLY-5891:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5891 (was: JBEAP-2508)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Domain Management
(was: Domain Management)
Target Release: (was: 7.0.0.GA)
> The standard host.xml configs include useless permgen settings
> --------------------------------------------------------------
>
> Key: WFLY-5891
> URL: https://issues.jboss.org/browse/WFLY-5891
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Our standard host.xml files include permgen settings. Our software just ignores them on JDK 8 or later, and we only run on 8 or later, so having these settings in our standard configs is just misleading.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5890) Wildfly10's default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5890?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek moved JBEAP-2507 to WFLY-5890:
--------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5890 (was: JBEAP-2507)
Workflow: GIT Pull Request workflow (was: CDW v1)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.CR5
(was: 7.0.0.ER3)
> Wildfly10's default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-5890
> URL: https://issues.jboss.org/browse/WFLY-5890
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Karm Babacek
> Assignee: Radoslav Husar
> Labels: ux
>
> h3. Problem
> Wildfly 10's default load metric changed from *busyness* to *cpu*. Although otherwise fine, this change has a one major drawback: It doesn't work on Windows JDKs: MODCLUSTER-234. This fact has been known and acknowledged since 2011.
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> Instead of a valid Load value, subsystem returns 0 and prints: {{MODCLUSTER000045: AverageSystemLoadMetric is not supported on this system and will be disabled.}}
> h3. Example
> {code}
> C:\Users\Administrator>groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: -1.0
> avail. processors: 4
> {code}
> {code}
> mbabacek@localhost:~$ groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: 0.67
> avail. processors: 4
> {code}
> h3. Call to action
> IMHO, this is a Major user experience failure, the default should provide meaningful values on all major platforms.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1128) Improve the subsystem test schema test coverage
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1128?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1128:
------------------------------------------
I bumped this to 3 as 1) I don't think we'd merge it at this stage and 2) it would need a JBEAP and backport anyway.
> Improve the subsystem test schema test coverage
> -----------------------------------------------
>
> Key: WFCORE-1128
> URL: https://issues.jboss.org/browse/WFCORE-1128
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.1.Final
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 3.0.0.Alpha1
>
>
> Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths().
> Rather than making it explicit to turn on, it should be explicit to turn off.
> Also the current way of doing this uses Assume.assumeTrue() to check if a test has provided a schema file, which provides a lot of ignored test noise in the test output. If the xsd should not be tested, methods should instead override testSchema() or testSchemaOfSubsystemTemplates() and provide an empty implementation with a comment saying why it is not important.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1128) Improve the subsystem test schema test coverage
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1128?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1128:
-------------------------------------
Fix Version/s: 3.0.0.Alpha1
(was: 2.0.5.Final)
> Improve the subsystem test schema test coverage
> -----------------------------------------------
>
> Key: WFCORE-1128
> URL: https://issues.jboss.org/browse/WFCORE-1128
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.1.Final
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 3.0.0.Alpha1
>
>
> Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths().
> Rather than making it explicit to turn on, it should be explicit to turn off.
> Also the current way of doing this uses Assume.assumeTrue() to check if a test has provided a schema file, which provides a lot of ignored test noise in the test output. If the xsd should not be tested, methods should instead override testSchema() or testSchemaOfSubsystemTemplates() and provide an empty implementation with a comment saying why it is not important.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (SECURITY-930) A security-domain can only load login-modules from a single JBoss module
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-930?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration updated SECURITY-930:
---------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1280512
Bugzilla Update: Perform
> A security-domain can only load login-modules from a single JBoss module
> --------------------------------------------------------------------------
>
> Key: SECURITY-930
> URL: https://issues.jboss.org/browse/SECURITY-930
> Project: PicketBox
> Issue Type: Bug
> Components: JBossSX, Security-SPI
> Reporter: Derek Horton
> Assignee: Stefan Guilhen
>
> A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.
> For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:
> <security-domain name="jmx-console" cache-type="default">
> <authentication>
> <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> </login-module>
> <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> </login-module>
> </authentication>
> </security-domain>
> Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.
> There seems to be two issues. 1) The security subsystem code only "remembers" the last module that is defined within a single security domain. 2) I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code. The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months