September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3652) Network connection leak

by Seth Miller (JIRA)

[ https://issues.jboss.org/browse/WFLY-3652?page=com.atlassian.jira.plugin.... ] Seth Miller commented on WFLY-3652: ----------------------------------- I am still able to repro this, or a very similar leak in Async on the latest 8.x HEAD branch (Undertow 1.1.0.RC2, which is newer than 1.1.0.Beta8 currently in wildfly-core/HEAD and newer than 1.1.0.Beta7 used in 9.0.0.Alpha1). Here's the related heap dump output; in load testing we are leaking about 100mb an hour. I am willing to submit a pull request if anyone has suggestions. {code} Class Name | Shallow Heap | Retained Heap ---------------------------------------------------------------------------------------------------------------------------------------------------- this$0 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask @ 0x2318e2e40 | 72 | 72 |- outerTask java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask @ 0x2318e2e40 | 72 | 72 |- scheduledFuture org.eclipse.jetty.util.thread.ScheduledExecutorScheduler$ScheduledFutureTask @ 0x2318e2e88 | 24 | 96 | '- task org.cometd.server.transport.AsyncJSONTransport$AsyncLongPollScheduler @ 0x2318e2dd8 | 48 | 144 | '- asyncListener io.undertow.servlet.spec.AsyncContextImpl$BoundAsyncListener @ 0x2318e2e08 | 32 | 176 | '- [0] java.lang.Object[1] @ 0x2318e2e28 | 24 | 200 | '- array java.util.concurrent.CopyOnWriteArrayList @ 0x2786644e0 | 24 | 272 | '- asyncListeners io.undertow.servlet.spec.AsyncContextImpl @ 0x278664498 | 72 | 464 | |- asyncContext io.undertow.servlet.spec.HttpServletRequestImpl @ 0x2318e2738 | 72 | 144 | |- asyncContext org.cometd.server.transport.AsyncJSONTransport$AsyncLongPollScheduler @ 0x2318e2dd8| 48 | 144 | |- this$0 io.undertow.servlet.spec.AsyncContextImpl$BoundAsyncListener @ 0x2318e2e08 | 32 | 176 | |- asyncContext io.undertow.servlet.spec.ServletOutputStreamImpl @ 0x278622580 | 72 | 6,136 | |- asyncContext org.cometd.server.transport.AsyncJSONTransport$Writer @ 0x2786225c8 | 56 | 6,040 | |- this$0 io.undertow.servlet.spec.AsyncContextImpl$TimeoutTask @ 0x278664528 | 16 | 16 | |- asyncContext org.cometd.server.transport.AsyncJSONTransport$UTF8Reader @ 0x2786645a0 | 40 | 1,664 | |- asyncContext io.undertow.servlet.spec.ServletInputStreamImpl @ 0x278664c20 | 48 | 1,712 ---------------------------------------------------------------------------------------------------------------------------------------------------- {code} > Network connection leak > ----------------------- > > Key: WFLY-3652 > URL: https://issues.jboss.org/browse/WFLY-3652 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: Linux 2.6.38-16-server > Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > Reporter: Jan Vanhercke > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > > When using Asynchronous servlets and AsyncListeners for long polling we observe a connection leak in the undertow subsystem. > Heap dumps show a large number of org.xnio.io.NioSocketConduit, io.undertow.server.protocol.http.HttpServerConnection and related objects. > However, since the effective number of connections is far less, nearly all AsyncContext instances we find are in a complete state and lsof output returns a large number of sockets with 'can't identify protocol' entries indicating that sockets are kept open by the JVM but are in fact half closed by the network stack. > Not all connections appear to be leaking, but over time, depending on the load, the server instance fills up. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-598) accumuate function not working when object chaining is used as accumulate condition

by John Le (JIRA)

[ https://issues.jboss.org/browse/DROOLS-598?page=com.atlassian.jira.plugin... ] John Le closed DROOLS-598. -------------------------- This scenario is now working but something else is not working. I will file a different ticket for it. > accumuate function not working when object chaining is used as accumulate condition > ----------------------------------------------------------------------------------- > > Key: DROOLS-598 > URL: https://issues.jboss.org/browse/DROOLS-598 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta2, 6.2.0.CR1, 6.2.0.Final > Reporter: John Le > Assignee: Mario Fusco > Labels: backport-to-6.0.x > Fix For: 6.2.0.CR1 > > Attachments: AccumulateWithPassAndFail.java, ShouldFireButNot.java, SumOfAllIssue.java > > > Please see attached code file to reproduce issue. Rule is supposed to fire and yield 0.0 as the sum but rule does not. If we remove TestA, TestB, TestC and leave only TestD as condition then rule fire. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3853) Cache PersistenceProviders within the same deployment

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3853?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-3853: ------------------------------- Forum Reference: http://lists.jboss.org/pipermail/hibernate-dev/2014-September/011777.html > Cache PersistenceProviders within the same deployment > ----------------------------------------------------- > > Key: WFLY-3853 > URL: https://issues.jboss.org/browse/WFLY-3853 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 9.0.0.Beta1 > > > See wildfly-dev ml discussion [http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002984.html] about calls to PersistenceProviderResolver.getPersistenceProviders() should return a cached list. The cache should be per deployment. > We can probably reuse our PersistenceProviderResolverImpl.persistenceProviderPerClassLoader map, just need to be careful that addDeploymentSpecificPersistenceProvider() is called early before any calls to getPersistenceProviders(). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-610) drools-worker-2 thread blocked and the main program blocks

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-610?page=com.atlassian.jira.plugin... ] Davide Sottara commented on DROOLS-610: --------------------------------------- I would recommend to move this discussion to the drools-usage mailing list. At this point this is clearly not a defect (nor a feature request), but a question on how to make drools work in a specific use case. People there will be able to help in a more appropriate fashion Best, Davide > drools-worker-2 thread blocked and the main program blocks > ---------------------------------------------------------- > > Key: DROOLS-610 > URL: https://issues.jboss.org/browse/DROOLS-610 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Environment: linux > Reporter: Nathalie ravenel > Assignee: Mario Fusco > Attachments: blocked.PNG, drools-worker-2.PNG, image001.jpg, image001.jpg, main thread.PNG, pool-1-thread1.PNG > > > Running our program, we got some deadlock on one thread (drools-worker-2). We investigated the problem using java memory control. The thread is blocked and the program also. The stack traces was registered for the different threads. The last trace for the thread was : org.drools.core.common.SynchronizedLeftTuplesSets.takeAll. > There are 1111 Blocked count on one DeadLock on the thread. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-114) [SyslogHandler] Logger name can be truncated in MSGID field

by Kyle Lape (JIRA)

Kyle Lape created LOGMGR-114: -------------------------------- Summary: [SyslogHandler] Logger name can be truncated in MSGID field Key: LOGMGR-114 URL: https://issues.jboss.org/browse/LOGMGR-114 Project: JBoss Log Manager Issue Type: Enhancement Reporter: Kyle Lape Assignee: James Perkins Possible solutions: 1. If the length is too long, use the shortened logger name: {{org.jboss.logmanager.LogManager}} -> {{o.j.l.LogManager}} 2. Use the {{STRUCTURED-DATA}} field to hold the logger name. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3891) Update appropriate web folders with newly changed schema

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/WFLY-3891?page=com.atlassian.jira.plugin.... ] Rob Stryker commented on WFLY-3891: ----------------------------------- > that is versioning the schemalocation content - but not the namespace/versions, right? The namespaces are also versioned. The above two mentioned files have the following namespaces: jboss-ejb-security_1_0.xsd -> targetNamespace="urn:security" jboss-ejb-security_1_1.xsd -> targetNamespace="urn:security:1.1" > Update appropriate web folders with newly changed schema > -------------------------------------------------------- > > Key: WFLY-3891 > URL: https://issues.jboss.org/browse/WFLY-3891 > Project: WildFly > Issue Type: Task > Reporter: Rob Stryker > Assignee: Jason Greene > > Recent changes to several ejb3 xsd files require the following web folders to be updated with the most up-to-date schema files: > http://www.jboss.org/j2ee/schema/ > http://www.jboss.org/schema/jbossas/ > While this specific request comes due to WFLY-3189, it is related to WFLY-3434 about finding somewhere to host all schema. But something tells me putting them all on wildfly.org is not sufficient. Tools like eclipse will see the namespace and schemaLocation in our examples online (Such as https://docs.jboss.org/author/display/AS71/jboss-ejb3.xml+Reference) and copy-paste them verbatim. Those example files include things like the following: > {code} > xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd" > {code} > The important thing to note here is that it specifically points to http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd and so that specific schema file needs to be updated at THAT url, not at the wildfly URL. Tools like eclipse or other validators will try to fetch those specific urls. > If we intend to move all schemas to wildfly.org, then we probably need to update all examples to point to the new files as well. > At this point, the schemas I care most about are those mentioned in the following two PRs: > https://github.com/wildfly/wildfly/pull/6739 > https://github.com/jboss/metadata/pull/72 > But obviously all appropriate or changed xsd's should be updated on the web urls if possible. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3758) Unable to run JSF applications deployed to "/"

by Ken H (JIRA)

[ https://issues.jboss.org/browse/WFLY-3758?page=com.atlassian.jira.plugin.... ] Ken H commented on WFLY-3758: ----------------------------- [~swd847], can you provide any information on what was changed? I've just built master and it looks like this issue is resolved but we are back to WFLY-3448 where the session ID is being regenerated on every subdirectory request. Checking the source, the changes in the pull request for WLFY-3448 are still present so it isn't clear what resolved this. > Unable to run JSF applications deployed to "/" > ----------------------------------------------- > > Key: WFLY-3758 > URL: https://issues.jboss.org/browse/WFLY-3758 > Project: WildFly > Issue Type: Bug > Components: JSF, Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Environment: WildFly master at 50a830205c, JDK 1.7 > Reporter: Ken H > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > > I don't think the patch in pull request 6338 is right. I experienced the issue defined in WLFY-3448 on 8.1.0.Final, then built master at 50a830205c and the new behavior is different but still broken. Now requests to http://host/login throws a Not Found, the server is expecting http://host//login (which explodes because it isn't valid). If I hit http://host then the redirect is generated to http://host//welcome because httpServletRequest.getContextPath() is returning "/" (when it was returning an empty string in 7.x). > From web.xml: > {code} > <welcome-file-list> > <welcome-file>/</welcome-file> > </welcome-file-list> > {code} > From jboss-web.xml: > {code} > <jboss-web> > <context-root>/</context-root> > </jboss-web> > {code} > My app is packaged as a war, so no application.xml exists to define context-root. > I would say this is a regression caused by the resolution to WLFY-3448 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3900) Unable to inject EJB Context into CDI Interceptor

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-3900?page=com.atlassian.jira.plugin.... ] Brad Maxwell updated WFLY-3900: ------------------------------- Attachment: server.log > Unable to inject EJB Context into CDI Interceptor > ------------------------------------------------- > > Key: WFLY-3900 > URL: https://issues.jboss.org/browse/WFLY-3900 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Stuart Douglas > Attachments: inject-ejb-context-into-cdi-interceptor.jar, server.log > > > CDI Interceptor cannot inject EJB session context. > If the Interceptor is changed to EJB interceptor by removing the @Interceptor on the interceptor and removing it from the beans.xml, and adding @Interceptors(...) to the EJB, then it is able to inject. > See attached reproducer with source and log file. > private @Resource SessionContext sessionContext; > Caused by: javax.naming.NameNotFoundException: env/test.ServiceLoggedInterceptor/sessionContext -- service jboss.naming.context.java.comp.inject-ejb-context-into-cdi-interceptor.inject-ejb-context-into-cdi-interceptor.HelloEJB.env."test.ServiceLoggedInterceptor".sessionContext > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] > at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] > at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:185) > ... 127 more -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3900) Unable to inject EJB Context into CDI Interceptor

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-3900?page=com.atlassian.jira.plugin.... ] Brad Maxwell updated WFLY-3900: ------------------------------- Attachment: inject-ejb-context-into-cdi-interceptor.jar > Unable to inject EJB Context into CDI Interceptor > ------------------------------------------------- > > Key: WFLY-3900 > URL: https://issues.jboss.org/browse/WFLY-3900 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Stuart Douglas > Attachments: inject-ejb-context-into-cdi-interceptor.jar, server.log > > > CDI Interceptor cannot inject EJB session context. > If the Interceptor is changed to EJB interceptor by removing the @Interceptor on the interceptor and removing it from the beans.xml, and adding @Interceptors(...) to the EJB, then it is able to inject. > See attached reproducer with source and log file. > private @Resource SessionContext sessionContext; > Caused by: javax.naming.NameNotFoundException: env/test.ServiceLoggedInterceptor/sessionContext -- service jboss.naming.context.java.comp.inject-ejb-context-into-cdi-interceptor.inject-ejb-context-into-cdi-interceptor.HelloEJB.env."test.ServiceLoggedInterceptor".sessionContext > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] > at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] > at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:185) > ... 127 more -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3900) Unable to inject EJB Context into CDI Interceptor

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-3900: ---------------------------------- Summary: Unable to inject EJB Context into CDI Interceptor Key: WFLY-3900 URL: https://issues.jboss.org/browse/WFLY-3900 Project: WildFly Issue Type: Bug Components: CDI / Weld Affects Versions: 9.0.0.Alpha1 Reporter: Brad Maxwell Assignee: Stuart Douglas Attachments: inject-ejb-context-into-cdi-interceptor.jar, server.log CDI Interceptor cannot inject EJB session context. If the Interceptor is changed to EJB interceptor by removing the @Interceptor on the interceptor and removing it from the beans.xml, and adding @Interceptors(...) to the EJB, then it is able to inject. See attached reproducer with source and log file. private @Resource SessionContext sessionContext; Caused by: javax.naming.NameNotFoundException: env/test.ServiceLoggedInterceptor/sessionContext -- service jboss.naming.context.java.comp.inject-ejb-context-into-cdi-interceptor.inject-ejb-context-into-cdi-interceptor.HelloEJB.env."test.ServiceLoggedInterceptor".sessionContext at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:185) ... 127 more -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2014