[JBoss JIRA] (WFCORE-1160) Definition of capabilities where the service return type is generic.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1160?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-1160:
------------------------------------------
This is reminding me why I did not raise a Jira issue the last time I encountered this problem - what I realised then was the MSC based injection also has exactly the same issue so even if solved at the capability level we still don't have it solved at the service level.
Your last sentence is correct, any solution should cover an arbitrary number of types.
This is actually pulling me back to a point I was at a couple of days ago - maybe it will be easier all round if within the Elytron project I just create a new interface CredentialSecurityFactory which is an extension of SecurityFactory but with the generic type specified as Credential. From a capabilities perspective and an MSC perspective, strongly typed dependencies and capability resolution will work unhindered.
> Definition of capabilities where the service return type is generic.
> --------------------------------------------------------------------
>
> Key: WFCORE-1160
> URL: https://issues.jboss.org/browse/WFCORE-1160
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Brian Stansberry
> Labels: affects_elytron
>
> Within Elytron we have the following interface: -
> {code}
> public interface SecurityFactory<T> {}
> {code}
> It is desirable to define capabilities where the generic type is specified so that as we wire together the various services we can be sure the correct SecurityFactory services are injected in the correct locations.
> As it stands our only option is going to be a runtime check so incorrectly wired SecurityFactory references will only occur late.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5727) After day or two Wildfly hangs and consumes 100% CPU
by Petri Tuomaala (JIRA)
[ https://issues.jboss.org/browse/WFLY-5727?page=com.atlassian.jira.plugin.... ]
Petri Tuomaala updated WFLY-5727:
---------------------------------
Description:
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)
was:
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)
!pid.png|thumbnail!
!monitor.png|thumbnail!
> 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-5727) After day or two Wildfly hangs and consumes 100% CPU
by Petri Tuomaala (JIRA)
Petri Tuomaala created WFLY-5727:
------------------------------------
Summary: 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: 9.0.1.Final, 8.2.0.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
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)
!pid.png|thumbnail!
!monitor.png|thumbnail!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1984) NPE while creating a dynamic FORK channel
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1984?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1984:
--------------------------------
Can't reproduce this, no NPE in my code.
Can you attach a standalone JGroups program which reproduces the NPE?
> NPE while creating a dynamic FORK channel
> -----------------------------------------
>
> Key: JGRP-1984
> URL: https://issues.jboss.org/browse/JGRP-1984
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Reporter: Ramesh Reddy
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> I am trying to create a ForkChannel based on the example in docs with code, when FORK protocol not present in the main stack
> {code}
> channel=new JChannel("tcp.xml"));
> channel.connect("RpcDispatcherTestGroup");
> ForkChannel forkChannel = new ForkChannel(channel, "test-rpc", name, true, ProtocolStack.BELOW, FRAG2.class);
> forkChannel.connect("test-rpc");
> {code}
> this ends with
> {code}
> Exception in thread "main" java.lang.NullPointerException
> at org.jgroups.protocols.FORK.createForkStack(FORK.java:199)
> at org.jgroups.fork.ForkChannel.<init>(ForkChannel.java:79)
> at org.teiid.systemmodel.RpcDispatcherTest.start(RpcDispatcherTest.java:32)
> at org.teiid.systemmodel.RpcDispatcherTest.main(RpcDispatcherTest.java:54
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5170) WildFlySecurityManager throws exception by some tests with security manager
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-5170?page=com.atlassian.jira.plugin.... ]
Ivo Studensky commented on WFLY-5170:
-------------------------------------
RemoteNamingEjbTestCase is fixed by MSC-151.
> WildFlySecurityManager throws exception by some tests with security manager
> ---------------------------------------------------------------------------
>
> Key: WFLY-5170
> URL: https://issues.jboss.org/browse/WFLY-5170
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Marek Kopecký
> Assignee: Ivo Studensky
>
> *Description of problem:*
> WildFlySecurityManager throws ExceptionInInitializerError exception by some tests with security manager.
> *Affected tests found so far:*
> * org.jboss.as.test.integration.batch.deployment.JobControlTestCase#testStop
> * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20MessageSelectorTestCase#retestMessageSelectors
> * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20QueueTestCase#testEjb20MDB
> * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase#testEjb20TopicMDBs
> * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB21TestCase#testSimple21MDB
> * org.jboss.as.test.integration.ejb.pool.lifecycle.PooledEJBLifecycleTestCase#testMDB
> * org.jboss.as.test.xts.annotation.compensationScoped.CompensationScopedTestCase#shouldSeeDifferentValuesInDifferentTransactions
> * org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteReadOnly
> * org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorSimple
> *Steps to Reproduce for MDB20QueueTestCase:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=MDB20QueueTestCase
> *Actual results:*
> {noformat}
> testEjb20MDB(org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20QueueTestCase) Time elapsed: 0.094 sec <<< ERROR!
> java.lang.ExceptionInInitializerError: null
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:496)
> at java.lang.System.getProperty(System.java:717)
> at java.lang.Integer.getInteger(Integer.java:1101)
> at java.lang.Integer.getInteger(Integer.java:1057)
> at org.jboss.as.test.shared.TimeoutUtil.<clinit>(TimeoutUtil.java:39)
> at org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20QueueTestCase.testEjb20MDB(MDB20QueueTestCase.java:110)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1989:
--------------------------------
If we use TCP, for instance and have no max_bundle_size, then we can get real huge buffers. This doesn't noramlly happen though, so perhaps - as you mentioned - I'll go with a copy for buffers greater than some predefined max size.
> Bundlers: reuse send buffer when transport == sync.
> ---------------------------------------------------
>
> Key: JGRP-1989
> URL: https://issues.jboss.org/browse/JGRP-1989
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}.
> Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer).
> The code in the bundler should check for this, and copy if async or not copy if sync.
> Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on JGRP-1989:
---------------------------------------
In the use cases I have in mind (i.e. in-memory data grids) holding onto a 60K buffer is really not a concern, so I'd rather keep it simple rather than attempt to scale it down safely.
But I understand 60K is an example, and also there might be applications in the embedded world for which this matters? I'd suggest to have a configurable upper bound, so that when a buffer is needed larger than that you allocate it normally without using the pool.
> Bundlers: reuse send buffer when transport == sync.
> ---------------------------------------------------
>
> Key: JGRP-1989
> URL: https://issues.jboss.org/browse/JGRP-1989
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}.
> Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer).
> The code in the bundler should check for this, and copy if async or not copy if sync.
> Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5682) Can't define absolute path for object store location
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-5682?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on WFLY-5682:
---------------------------------
Thanks Ondra,
I think the description of object-store-relative-to "References a global path configuration in the domain model" could means the value of this attribute is just a reference and can not be a path. The other change I think it should be in the fix of WFLY-5613.
sorry, I can not answer your doubt and actually I also have a little bit confuse about the relative-to attribute. I think we can raise a discuss on the wildfly forum or wildfly-dev that would get the more detail.
> Can't define absolute path for object store location
> ----------------------------------------------------
>
> Key: WFLY-5682
> URL: https://issues.jboss.org/browse/WFLY-5682
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.0.0.CR4
> Reporter: Ondřej Chaloupka
> Assignee: Amos Feng
> Fix For: 10.0.0.CR5
>
>
> As trying to set absolute path for location of transaction log store I've got to suspicion that's not possible.
> If I try to set `object-store-relative-to` to some absolute path or set `object-store-relative-to` to empty string and then `object-store-path` to some absolute path the server starts with exceptions [1][2].
> [1]
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) 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.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/home/ochaloup/tmp/'
> at org.jboss.as.controller.services.path.PathManagerService.resolveRelativePathEntry(PathManagerService.java:87) at org.jboss.as.txn.service.ArjunaObjectStoreEnvironmentService.start(ArjunaObjectStoreEnvironmentService.java:76)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ...
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.txn.ArjunaObjectStoreEnvironment" => "org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service
> Caused by: java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/home/ochaloup/tmp/'"}}
> INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status reportWFLYCTL0186: Services which failed to start: service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service
> {code}
> [2]
> {code}
> ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> at org.jboss.as.server.ServerService.boot(ServerService.java:356) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[348,13]
> Message: "WFLYCTL0113: '' is an invalid value for parameter relative-to. Values must have a minimum length of 1 characters"
> at org.jboss.as.controller.SimpleAttributeDefinition.parse(SimpleAttributeDefinition.java:161) at org.jboss.as.controller.SimpleAttributeDefinition.parseAndSetParameter(SimpleAttributeDefinition.java:186)
> at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.parseObjectStoreEnvironmentElementAndEnrichOperation(TransactionSubsystem14Parser.java:205)
> at org.jboss.as.txn.subsystem.TransactionSubsystem30Parser.readElement(TransactionSubsystem30Parser.java:67) at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:111)
> at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:54) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:547)
> at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:244) at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:143)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:69) at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:47) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1989:
--------------------------------
Downside: reusing {{ByteArrayDataOutputStream}} means it could increase on a large message and keep that large buffer in memory, e.g.
* Initial size: 1024
* Sending 500 bytes: size=1024
* Sending 60000 bytes: size=~60000
Even if we only send small messages from now on, the 60K buffer will remain allocated. Perhaps we should periodically re-allocate if the avg message size remains under the buffer's size?
> Bundlers: reuse send buffer when transport == sync.
> ---------------------------------------------------
>
> Key: JGRP-1989
> URL: https://issues.jboss.org/browse/JGRP-1989
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}.
> Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer).
> The code in the bundler should check for this, and copy if async or not copy if sync.
> Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months