[JBoss JIRA] (JGRP-2090) JGRP000027: failed passing message up
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2090?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-2090.
--------------------------
Fix Version/s: (was: 4.0)
Resolution: Rejected
> JGRP000027: failed passing message up
> -------------------------------------
>
> Key: JGRP-2090
> URL: https://issues.jboss.org/browse/JGRP-2090
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Will Wright
> Assignee: Bela Ban
> Fix For: 3.6.11
>
>
> The JGroups library is generating NullPointerExceptions when attempting to process incoming messages. From what I can tell this is due to it looking for an incorrect message header.
> The TP object has a protocol id of 75 despite being a TUNNEL which ought to have an id of 24. The id is being correctly assigned to 24 at the Protocol.id member variable declaration, but is then subsequently changed to 75 by the TP.init method. This seems to have been caused by commit [6bc167f7e0181af32e1930935d8cf0efdc1e82f0|https://github.com/belaban/JGrou...] which has the message "Added TP to jg-protocols.xml". If I backout this change to the TP.init method so as to not update the id then my application receives the incoming messages fine.
> java.lang.NullPointerException: null
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2090) JGRP000027: failed passing message up
by Will Wright (JIRA)
[ https://issues.jboss.org/browse/JGRP-2090?page=com.atlassian.jira.plugin.... ]
Will Wright commented on JGRP-2090:
-----------------------------------
Sure. Thanks.
> JGRP000027: failed passing message up
> -------------------------------------
>
> Key: JGRP-2090
> URL: https://issues.jboss.org/browse/JGRP-2090
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Will Wright
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
>
> The JGroups library is generating NullPointerExceptions when attempting to process incoming messages. From what I can tell this is due to it looking for an incorrect message header.
> The TP object has a protocol id of 75 despite being a TUNNEL which ought to have an id of 24. The id is being correctly assigned to 24 at the Protocol.id member variable declaration, but is then subsequently changed to 75 by the TP.init method. This seems to have been caused by commit [6bc167f7e0181af32e1930935d8cf0efdc1e82f0|https://github.com/belaban/JGrou...] which has the message "Added TP to jg-protocols.xml". If I backout this change to the TP.init method so as to not update the id then my application receives the incoming messages fine.
> java.lang.NullPointerException: null
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5727) After day or two Wildfly hangs and consumes 100% CPU
by Soner Eker (JIRA)
[ https://issues.jboss.org/browse/WFLY-5727?page=com.atlassian.jira.plugin.... ]
Soner Eker commented on WFLY-5727:
----------------------------------
Problem exists in 9.0.2 version also. SSL fixes applied to 9.0.2 version?
> 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)
9 years, 9 months
[JBoss JIRA] (JGRP-2090) JGRP000027: failed passing message up
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2090?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2090:
--------------------------------
Yes, mea culpa, but every now and then I reserve the right to break binary compatibility, even between patch versions. Can we close this issue?
> JGRP000027: failed passing message up
> -------------------------------------
>
> Key: JGRP-2090
> URL: https://issues.jboss.org/browse/JGRP-2090
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Will Wright
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
>
> The JGroups library is generating NullPointerExceptions when attempting to process incoming messages. From what I can tell this is due to it looking for an incorrect message header.
> The TP object has a protocol id of 75 despite being a TUNNEL which ought to have an id of 24. The id is being correctly assigned to 24 at the Protocol.id member variable declaration, but is then subsequently changed to 75 by the TP.init method. This seems to have been caused by commit [6bc167f7e0181af32e1930935d8cf0efdc1e82f0|https://github.com/belaban/JGrou...] which has the message "Added TP to jg-protocols.xml". If I backout this change to the TP.init method so as to not update the id then my application receives the incoming messages fine.
> java.lang.NullPointerException: null
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1237) Remove @Deprecated from ExtensionContext.isRegisterTransformers()
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1237?page=com.atlassian.jira.plugi... ]
Tomaz Cerar closed WFCORE-1237.
-------------------------------
Fix Version/s: (was: 3.0.0.Alpha4)
Resolution: Duplicate Issue
Duplicate of WFCORE-823
> Remove @Deprecated from ExtensionContext.isRegisterTransformers()
> -----------------------------------------------------------------
>
> Key: WFCORE-1237
> URL: https://issues.jboss.org/browse/WFCORE-1237
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Priority: Minor
>
> Even if we change how transformers are done, this method could probably be retained for a bit. It's annoying to have a method every extension must invoke giving a deprecation warning for years for something maybe we'll change.
> And SubsystemRegistration.registerModelTransformers isn't deprecated and its the method far more likely to be broken by any change.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1237) Remove @Deprecated from ExtensionContext.isRegisterTransformers()
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1237?page=com.atlassian.jira.plugi... ]
Tomaz Cerar reassigned WFCORE-1237:
-----------------------------------
Assignee: Tomaz Cerar (was: Brian Stansberry)
> Remove @Deprecated from ExtensionContext.isRegisterTransformers()
> -----------------------------------------------------------------
>
> Key: WFCORE-1237
> URL: https://issues.jboss.org/browse/WFCORE-1237
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Priority: Minor
> Fix For: 3.0.0.Alpha4
>
>
> Even if we change how transformers are done, this method could probably be retained for a bit. It's annoying to have a method every extension must invoke giving a deprecation warning for years for something maybe we'll change.
> And SubsystemRegistration.registerModelTransformers isn't deprecated and its the method far more likely to be broken by any change.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-823) Undeprecate ExtensionContext.isRegisterTransformers()
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-823?page=com.atlassian.jira.plugin... ]
Tomaz Cerar reassigned WFCORE-823:
----------------------------------
Assignee: Tomaz Cerar (was: Kabir Khan)
> Undeprecate ExtensionContext.isRegisterTransformers()
> -----------------------------------------------------
>
> Key: WFCORE-823
> URL: https://issues.jboss.org/browse/WFCORE-823
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Priority: Minor
>
> Feel free to just reject this if you think the @Deprecated should remain. It's no big deal.
> I don't have anything specific in mind re: how transformers get registered, and it's quite likely the existing way will remain for the life of EAP 7. So I'm comfortable removing the @Deprecated from this method if you are.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5930) Unable to load deployments
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5930?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-5930.
-------------------------------
Fix Version/s: 10.1.0.Final
Resolution: Done
should be addressed as part of WFLY-6600
> Unable to load deployments
> --------------------------
>
> Key: WFLY-5930
> URL: https://issues.jboss.org/browse/WFLY-5930
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management, Web (Undertow)
> Affects Versions: 9.0.2.Final
> Reporter: Hamed Abdollahpour
> Assignee: Tomaz Cerar
> Fix For: 10.1.0.Final
>
>
> Fail to get list of deployment on application server with this error:
> 12:19:40,130 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-3) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "discripto-ear.ear"),
> ("subdeployment" => "discripto-rest.war"),
> ("subsystem" => "undertow"),
> ("servlet" => "com.wpic.discripto.rest.App")
> ]): java.lang.NullPointerException
> at org.wildfly.extension.undertow.DeploymentServletDefinition$AbstractMetricsHandler.execute(DeploymentServletDefinition.java:121)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:196)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:641)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:803)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:218)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:208)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> 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:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 12:21:20,258 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-2) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "discripto-ear.ear"),
> ("subdeployment" => "discripto-rest.war"),
> ("subsystem" => "undertow"),
> ("servlet" => "com.wpic.discripto.rest.App")
> ]): java.lang.NullPointerException
> at org.wildfly.extension.undertow.DeploymentServletDefinition$AbstractMetricsHandler.execute(DeploymentServletDefinition.java:121)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:196)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:641)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:803)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:218)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:208)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> 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:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> It works perfect after restarting.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2090) JGRP000027: failed passing message up
by Will Wright (JIRA)
[ https://issues.jboss.org/browse/JGRP-2090?page=com.atlassian.jira.plugin.... ]
Will Wright commented on JGRP-2090:
-----------------------------------
Thanks for getting back. I can see what the underlying issue was now. My publisher was running 3.6.6 and the receiver was on 3.6.10. Looks like this change does not maintain binary compatibility between the micro version, however, the checks in Version.isBinaryCompatible assume it does.
> JGRP000027: failed passing message up
> -------------------------------------
>
> Key: JGRP-2090
> URL: https://issues.jboss.org/browse/JGRP-2090
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Will Wright
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
>
> The JGroups library is generating NullPointerExceptions when attempting to process incoming messages. From what I can tell this is due to it looking for an incorrect message header.
> The TP object has a protocol id of 75 despite being a TUNNEL which ought to have an id of 24. The id is being correctly assigned to 24 at the Protocol.id member variable declaration, but is then subsequently changed to 75 by the TP.init method. This seems to have been caused by commit [6bc167f7e0181af32e1930935d8cf0efdc1e82f0|https://github.com/belaban/JGrou...] which has the message "Added TP to jg-protocols.xml". If I backout this change to the TP.init method so as to not update the id then my application receives the incoming messages fine.
> java.lang.NullPointerException: null
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months