[JBoss JIRA] (WFLY-5727) After day or two Wildfly hangs and consumes 100% CPU
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5727?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5727:
--------------------------------------
I think this should be resolved in Wildfly 10. Can you try with the latest CR4?
> After day or two Wildfly hangs and consumes 100% CPU
> ----------------------------------------------------
>
> Key: WFLY-5727
> URL: https://issues.jboss.org/browse/WFLY-5727
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Affects Versions: 8.2.0.Final, 9.0.1.Final
> Environment: Wildfly 9.01 Final, Wildfly 8.2
> CentOS Linux release 7.1.1503 (Core)
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
> Reporter: Petri Tuomaala
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: Linux, io, ssl, undertow, wildfly, xnio
> Fix For: 9.x.x TBD
>
> Attachments: jstack.22263.102919.280420771, jstack.22263.102925.032513958, jstack.22263.102930.660792783, jstack.22263.102936.697001192, jstack.22263.102942.535009068, jstack.22263.102948.169314576, jstack.22263.102954.185475598, jstack.22263.102959.848031929, jstack.22263.103005.599986837, jstack.22263.103011.261542540, monitor.png, pid.png
>
>
> First disclaimer, this looks pointing to undertow/xnio but I am not sure for the root cause so I'm filing this for Wildfly.
> After a day or two Wildfly just hangs and consumes the cpu. We have noticed that the site traffic itself has no impact on this: it has happened during peak traffic and also almost in idle situations.
> We are handling SSL in Wildfly and example this https://issues.jboss.org/browse/UNDERTOW-282 looks similar to this but it has been resolved over year ago so it should be in Wildfly 9.01.
> Our SSL conf in standalone.xml:
> <https-listener name="https" socket-binding="https" security-realm="UndertowRealm" enabled-cipher-suites="TLS_DHE_DSS_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA" max-parameters="5000"/>
> I have narrowed down the thread that hangs. Or at least tried, my first time to study thread dumps. PID for thread that is jammed is 22599 => 0x5847 as hex and it points to the thread end of this description. I attach the actual thread dumps to this ticket. Any workaround for this is preciated, we currently need to reboot the servers when the Wildfly hangs (almost every nigth).
> "default task-20" #285 prio=5 os_prio=0 tid=0x00007f862c328800 nid=0x5847 runnable [0x00007f85f5ad6000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:192)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> - locked <0x00000006f6065210> (a java.lang.Object)
> at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:282)
> at org.xnio.ssl.JsseSslConduitEngine.handleUnwrapResult(JsseSslConduitEngine.java:737)
> - locked <0x00000006f606b708> (a org.xnio.ByteBufferSlicePool$PooledByteBuffer)
> at org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:620)
> - locked <0x00000006f606b708> (a org.xnio.ByteBufferSlicePool$PooledByteBuffer)
> at org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:574)
> at org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:89)
> at org.xnio.conduits.AbstractStreamSourceConduit.read(AbstractStreamSourceConduit.java:51)
> at io.undertow.conduits.ReadDataStreamSourceConduit.read(ReadDataStreamSourceConduit.java:67)
> at io.undertow.conduits.FixedLengthStreamSourceConduit.read(FixedLengthStreamSourceConduit.java:249)
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
> at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:209)
> at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:2136)
> at io.undertow.server.handlers.form.FormEncodedDataDefinition$FormEncodedDataParser.doParse(FormEncodedDataDefinition.java:133)
> at io.undertow.server.handlers.form.FormEncodedDataDefinition$FormEncodedDataParser.parseBlocking(FormEncodedDataDefinition.java:251)
> at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:753)
> at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:627)
> at org.apache.myfaces.context.servlet.RequestParameterMap.getAttribute(RequestParameterMap.java:45)
> at org.apache.myfaces.context.servlet.RequestParameterMap.getAttribute(RequestParameterMap.java:33)
> at org.apache.myfaces.util.AbstractAttributeMap.containsKey(AbstractAttributeMap.java:62)
> at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.isPostback(HtmlResponseStateManager.java:303)
> at org.apache.myfaces.lifecycle.DefaultRestoreViewSupport.isPostback(DefaultRestoreViewSupport.java:242)
> at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:120)
> at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170)
> at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> at fi.elbit.skills.loginview.DefaultsFilter.doFilter(DefaultsFilter.java:117)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> 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)
> Locked ownable synchronizers:
> - <0x00000006f20bb6c8> (a java.util.concurrent.ThreadPoolExecutor$Worker)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-3153) Testing legacy subsystem transformers between different versions of Wildlfy
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3153?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-3153.
-------------------------------
Fix Version/s: 10.0.0.CR4
Resolution: Out of Date
> Testing legacy subsystem transformers between different versions of Wildlfy
> ---------------------------------------------------------------------------
>
> Key: WFLY-3153
> URL: https://issues.jboss.org/browse/WFLY-3153
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: Tomaz Cerar
> Fix For: 10.0.0.CR4
>
>
> The legacy web subsystem is still evolving. Thus we need to make the legacy web subsystem in WildFly evolve and test the transformers.
> But testing the transformation between WildFly 8.0.0.Final and the next version of WildFly fails with the following exception :
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> 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.jboss.as.subsystem.bridge.local.ScopedKernelServicesBootstrap.createChildClassLoaderKernelServices(ScopedKernelServicesBootstrap.java:85)
> at org.jboss.as.subsystem.bridge.local.ScopedKernelServicesBootstrap.createKernelServices(ScopedKernelServicesBootstrap.java:53)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:771)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:644)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:616)
> at org.jboss.as.web.test.WebSubsystemTestCase.testTransformation_2_0(WebSubsystemTestCase.java:443)
> at org.jboss.as.web.test.WebSubsystemTestCase.testTransformationWildFly8(WebSubsystemTestCase.java:427)
> Caused by: java.lang.IllegalArgumentException: JBAS014880: No operation entry called 'add' registered at '[("subsystem" => "web")]'
> at org.jboss.as.controller.operations.validation.OperationValidator.throwOrWarnAboutDescriptorProblem(OperationValidator.java:549)
> at org.jboss.as.controller.operations.validation.OperationValidator.validateOperation(OperationValidator.java:123)
> at org.jboss.as.model.test.ModelTestModelControllerService.boot(ModelTestModelControllerService.java:199)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:289)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256)
> at java.lang.Thread.run(Thread.java:744)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-980) KieBase.getFactType should only be used to retrieve declared beans.
by Craig West (JIRA)
[ https://issues.jboss.org/browse/DROOLS-980?page=com.atlassian.jira.plugin... ]
Craig West commented on DROOLS-980:
-----------------------------------
I am having a similar issue, although I have no idea if the root cause is the same. I have a type declared in DRL as:
declare Drools_applications extends ProfileSettingGroup
drools_app_external : String
drools_lc_app_external : String
drools_app_memory : String
drools_numeric_app_memory : double
drools_app_package : String
drools_lc_app_package : String
drools_app_cache_storage : String
drools_numeric_app_cache_storage : double
drools_app_icon_url : String
drools_lc_app_icon_url : String
drools_app_version : String
drools_lc_app_version : String
drools_app_name : String
drools_lc_app_name : String
drools_app_system : String
drools_lc_app_system : String
drools_app_vcode : String
drools_numeric_app_vcode : double
drools_app_total_storage : String
drools_numeric_app_total_storage : double
drools_app_data_storage : String
drools_numeric_app_data_storage : double
drools_app_code_storage : String
drools_numeric_app_code_storage : double
drools_app_status : String
drools_lc_app_status : String
end
The exception I got was:
java.lang.UnsupportedOperationException: KieBase.getFactType should only be used to retrieve declared beans. Class com.crowdcare.rules.android.Drools_applications exists outside DRL
at org.drools.core.definitions.impl.KnowledgePackageImpl.getFactType(KnowledgePackageImpl.java:635) [drools-core.jar:6.3.0.Final]
at org.drools.core.impl.KnowledgeBaseImpl.getFactType(KnowledgeBaseImpl.java:1809) [drools-core.jar:6.3.0.Final]
at org.drools.core.impl.KnowledgeBaseImpl.getFactType(KnowledgeBaseImpl.java:1802) [drools-core.jar:6.3.0.Final]
at org.drools.impl.adapters.KnowledgeBaseAdapter.getFactType(KnowledgeBaseAdapter.java:98) [knowledge-api.jar:6.3.0.Final]
at com.crowdcare.service.DroolsBuilder.createProfileSettingGroup(DroolsBuilder.java:166) [classes:]
...
> KieBase.getFactType should only be used to retrieve declared beans.
> -------------------------------------------------------------------
>
> Key: DROOLS-980
> URL: https://issues.jboss.org/browse/DROOLS-980
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Alejo Jara
> Assignee: Mario Fusco
> Attachments: droolsBug980.zip, my_rules-1.jar, my_rules-2.jar
>
>
> Error inesperado en la ejecucion del artefacto
> java.lang.UnsupportedOperationException: KieBase.getFactType should only be used to retrieve declared beans. Class com.example.types.Person exists outside DRL
> at org.drools.core.definitions.impl.KnowledgePackageImpl.getFactType(KnowledgePackageImpl.java:635)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-831) KIE Execution Server is not able to find the Maven repository
by Roger Martínez (JIRA)
[ https://issues.jboss.org/browse/DROOLS-831?page=com.atlassian.jira.plugin... ]
Roger Martínez resolved DROOLS-831.
-----------------------------------
Fix Version/s: 6.3.0.Final
Resolution: Done
Labels: docker (was: )
Added the fix for latest 6.3.0.Final tags. Images will be soon available on docker hub.
> KIE Execution Server is not able to find the Maven repository
> -------------------------------------------------------------
>
> Key: DROOLS-831
> URL: https://issues.jboss.org/browse/DROOLS-831
> Project: Drools
> Issue Type: Bug
> Components: docker images
> Affects Versions: 6.2.0.Final
> Environment: ALL
> Reporter: Roger Martínez
> Assignee: Roger Martínez
> Labels: docker
> Fix For: 6.3.0.Final
>
> Attachments: settings.xml
>
>
> In a non-Docker installation of the KIE execution server, the user must configure the Maven settings file to specify where the Maven repository for the artifacts is located.
> As Docker images are immutable, this configuration must be specified at runtime using environment variables when the container starts.
> This feature is not implemented on latest image tag and it's mandatory for being able to use the external Maven repository.
> This bug is reported from community feedback:
> "I'm trying out the docker images for the workbench-showcase and the execution-showcase. Fresh install. I'm using -p 8080:8080 for the wb and 8081:8080 for the exec. WB runs fine and I can build and deploy the mortgage project. Exec runs fine and I can access using REST. I can register the exec server fine. Mortgage container creates fine. Starting the container produces this error on the exec docker:
> 987 ERROR [org.kie.server.services.rest.KieServerRestImpl] (default task-5) Error creating container 'Test1' for module 'mortgages:mortgages:0.0.1': java.lang.RuntimeException: Cannot find KieModule: mortgages:mortgages:0.0.1
> Should this work out of the box?"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1144) Space before JVM argument in <jvm-options> causes failure
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1144?page=com.atlassian.jira.plugi... ]
Jason Greene updated WFCORE-1144:
---------------------------------
Fix Version/s: 2.0.3.Final
> Space before JVM argument in <jvm-options> causes failure
> ---------------------------------------------------------
>
> Key: WFCORE-1144
> URL: https://issues.jboss.org/browse/WFCORE-1144
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: java version "1.7.0_85"
> OpenJDK Runtime Environment (rhel-2.6.1.3.el6_7-x86_64 u85-b01)
> OpenJDK 64-Bit Server VM (build 24.85-b03, mixed mode)
> RHEL 6.5
> Reporter: Lin Gao
> Assignee: Lin Gao
> Fix For: 2.0.3.Final
>
>
> I have this configuration in my host.xml. Note the space before -XX:HeapDumpPath.
> {code}
> <server name="server-one" group="main-server-group">
> <jvm name="default">
> <jvm-options>
> <option value="-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n"/>
> <option value=" -XX:HeapDumpPath=/tmp/"/>
> </jvm-options>
> </jvm>
> </server>
> {code}
> When I start up EAP, server-one fails to start with this error message:
> {code}
> 17:01:26,218 INFO [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 3) JBAS012017: Starting process 'Server:server-one'
> [Server:server-one] Listening for transport dt_socket at address: 8787
> [Server:server-one] Error: Could not find or load main class -XX:HeapDumpPath=.tmp.
> 17:01:26,766 INFO [org.jboss.as.process.Server:server-one.status] (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' finished with an exit status of 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5568) Concurrent access timeout -- could not obtain lock within 5000 MILLISECONDS
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5568?page=com.atlassian.jira.plugin.... ]
Paul Ferraro resolved WFLY-5568.
--------------------------------
Fix Version/s: 10.0.0.CR5
Resolution: Done
Fixed by WFLY-5617
> Concurrent access timeout -- could not obtain lock within 5000 MILLISECONDS
> ----------------------------------------------------------------------------
>
> Key: WFLY-5568
> URL: https://issues.jboss.org/browse/WFLY-5568
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.CR3
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
> Labels: clustering_revalidate
> Fix For: 10.0.0.CR5
>
>
> This problem happens in a seemingly innocent scenario: standalone EJB client invoking method on a stateful bean in the first "forwarding" cluster (2 nodes), this bean just forwards the call to a stateful bean in the second "target" cluster (2 nodes), and then back again. Invocations are serial; the client won't invoke a method on a bean until it got a response to previous invocation. During the test, one of the target servers is shut down, which is when the problem starts to appear.
> This is the exception we're seeing on the standalone client:
> {code}
> 2015/10/20 19:28:54:958 EDT [ERROR][Runner - 13] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <javax.ejb.EJBTransactionRolledbackException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on RemoteStatefulSBImpl - could not obtain lock within 5000 MILLISECONDS>
> javax.ejb.EJBTransactionRolledbackException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on RemoteStatefulSBImpl - could not obtain lock within 5000 MILLISECONDS
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:159)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:276)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy70.getSerialAndIncrement(Unknown Source)
> at org.jboss.test.clusterbench.ejb.stateful.AbstractForwardingStatefulSBImpl.getSerialAndIncrement(AbstractForwardingStatefulSBImpl.java:33)
> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96)
> at org.jboss.ejb.client.EJBClientInvocationContext$1.run(EJBClientInvocationContext.java:282)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:279)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy2.getSerialAndIncrement(Unknown Source)
> at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:83)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on RemoteStatefulSBImpl - could not obtain lock within 5000 MILLISECONDS
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> This was also reported before: https://bugzilla.redhat.com/show_bug.cgi?id=990102
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1161) Simplification of setCapabilityReference where resource only exposes a single capability.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1161?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1161:
------------------------------------------
I don't think either of these are important concerns. The latter, just don't use this if the attribute will be used in some weird way.
> Simplification of setCapabilityReference where resource only exposes a single capability.
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-1161
> URL: https://issues.jboss.org/browse/WFCORE-1161
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Brian Stansberry
> Labels: affects_elytron
>
> Currently we need to use the following method to specify that one of our attributes is a reference to another capability: -
> {code}
> public BUILDER setCapabilityReference(String referencedCapability, String dependentCapability, boolean dynamicDependent) {
> referenceRecorder = new CapabilityReferenceRecorder.DefaultCapabilityReferenceRecorder(referencedCapability, dependentCapability, dynamicDependent);
> return (BUILDER) this;
> }
> {code}
> However the resource has already indicated the capability it provides and indicated whether it is dynamic so the last two parameters duplicate this information.
> This makes it much harder to re-use attribute definitions across different resources as even though they may reference the same time they now contain information about the resource they are used within.
> As discussed previously there is still the case that a single resource could provide multiple capabilities and this additional information may be required to clarify which capability it is in relation to but in general if a resource only provides a single capability we should be able to detect that without the additional information on the attribute.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5705) Cluster is not created using TCPGOSSIP
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5705?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-5705.
------------------------------
Resolution: Rejected
Why would you expect the nodes to form a cluster if they are not configured to use the same bind address on which the gossip router communicates.
> Cluster is not created using TCPGOSSIP
> --------------------------------------
>
> Key: WFLY-5705
> URL: https://issues.jboss.org/browse/WFLY-5705
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR3
> Reporter: Ivan Straka
> Assignee: Paul Ferraro
> Priority: Minor
>
> If gossip router is bound to localhost and nodes are not, they won't make cluster. But if nodes are bound to localhost and only port offset is used, they will make cluster.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months