September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3846) JMS resources allows duplicate JNDI entries

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3846?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3846: ----------------------------------------------- Miroslav Novak <mnovak(a)redhat.com> changed the Status of [bug 1140537|https://bugzilla.redhat.com/show_bug.cgi?id=1140537] from ON_QA to VERIFIED > JMS resources allows duplicate JNDI entries > ------------------------------------------- > > Key: WFLY-3846 > URL: https://issues.jboss.org/browse/WFLY-3846 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > The JMS resources that can be stored in JNDI (connection-factory, pooled-connection-factory, jms-queue, jms-topic) does not check whether their list of JNDI entries contains duplicates. > At runtime, duplicates are eliminated but this introduces a difference between the resource model with duplicate entries and its runtime state (without duplicates). > The attribute definitions for their JNDI entries should validate at the MODEL stage that their value does not contain duplicate elements. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

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

by Nathalie ravenel (JIRA)

Nathalie ravenel created DROOLS-610: --------------------------------------- Summary: 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: Mark Proctor 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)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3629) Upgrade Generic JMS RA to 1.0.6.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3629?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3629: ----------------------------------------------- Miroslav Novak <mnovak(a)redhat.com> changed the Status of [bug 1119645|https://bugzilla.redhat.com/show_bug.cgi?id=1119645] from ON_QA to VERIFIED > Upgrade Generic JMS RA to 1.0.6.Final > ------------------------------------- > > Key: WFLY-3629 > URL: https://issues.jboss.org/browse/WFLY-3629 > Project: WildFly > Issue Type: Component Upgrade > Components: JCA, JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3833) Cannot run mixed-domain tests on IPv6 hosts

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3833?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3833: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1145917|https://bugzilla.redhat.com/show_bug.cgi?id=1145917] from NEW to POST > Cannot run mixed-domain tests on IPv6 hosts > ------------------------------------------- > > Key: WFLY-3833 > URL: https://issues.jboss.org/browse/WFLY-3833 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 8.1.0.Final > Reporter: Dominik Pospisil > Assignee: Dominik Pospisil > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3833) Cannot run mixed-domain tests on IPv6 hosts

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3833?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3833: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1136210|https://bugzilla.redhat.com/show_bug.cgi?id=1136210] from ON_QA to VERIFIED > Cannot run mixed-domain tests on IPv6 hosts > ------------------------------------------- > > Key: WFLY-3833 > URL: https://issues.jboss.org/browse/WFLY-3833 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 8.1.0.Final > Reporter: Dominik Pospisil > Assignee: Dominik Pospisil > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3888) Show more informations of a timer in ERROR/WARN messages to identify the failed timer exactly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3888?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3888: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1145896, https://bugzilla.redhat.com/show_bug.cgi?id=1145903 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1145896) > Show more informations of a timer in ERROR/WARN messages to identify the failed timer exactly > --------------------------------------------------------------------------------------------- > > Key: WFLY-3888 > URL: https://issues.jboss.org/browse/WFLY-3888 > Project: WildFly > Issue Type: Enhancement > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > All ERROR and WARN messages should show the full timer information, specially the customer timer-information. > This will make it more easy to identify the exact timer in case of an EJB object has multiple timer instances active. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3888) Show more informations of a timer in ERROR/WARN messages to identify the failed timer exactly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3888?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3888: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1145896 > Show more informations of a timer in ERROR/WARN messages to identify the failed timer exactly > --------------------------------------------------------------------------------------------- > > Key: WFLY-3888 > URL: https://issues.jboss.org/browse/WFLY-3888 > Project: WildFly > Issue Type: Enhancement > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > All ERROR and WARN messages should show the full timer information, specially the customer timer-information. > This will make it more easy to identify the exact timer in case of an EJB object has multiple timer instances active. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3873) AJP-connector mangles SOAP-request

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3873?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-3873. ---------------------------------- Resolution: Out of Date This should be out of date, if you can reproduce on WF 9 then please re-open. > AJP-connector mangles SOAP-request > ---------------------------------- > > Key: WFLY-3873 > URL: https://issues.jboss.org/browse/WFLY-3873 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: Linux > reverse-proxy from Apache 2.2 via mod_proxy_ajp to AJP connector on WildFly 8.1.0-Final > Reporter: Gerke Ephorus > Assignee: Stuart Douglas > Labels: .net, ajp, soap > > When connecting to WildFly 8.1.0-Final SOAP-service from a .NET application via a reverse-proxy (Apache 2.2 with mod_proxy_ajp to the AJP-connector) it looks like the payload SOAP package gets mangled: > {noformat} > 2014-09-19 08:45:05,206 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-99) Interceptor for {http://ephorus.com/document-processor/ws/}DocumentProcessor has thrown exception, unwinding now: java.lang.RuntimeException: > Couldn't parse stream. > at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1447) > at org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:123) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:93) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:133) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-2.2.2.Final.jar:2.2.2.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:101) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20] > Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start byte 0x95 (at char #4, byte #-1) > at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:536) > at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:585) > at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:610) > at com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:316) > at __redirected.__XMLInputFactory.createXMLStreamReader(__XMLInputFactory.java:142) [jboss-modules.jar:1.3.3.Final] > at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1445) > ... 40 more > Caused by: java.io.CharConversionException: Invalid UTF-8 start byte 0x95 (at char #4, byte #-1) > at com.ctc.wstx.io.UTF8Reader.reportInvalidInitial(UTF8Reader.java:303) > at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:189) > at com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250) > at com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133) > at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:531) > ... 45 more > {noformat} > Connecting to the same SOAP-service via the reverse-proxy via the AJP from a different party/client does not show this problem. > Connecting to the same SOAP-service directly to the http-connector on the same WildFly 8.1.0-Final server does not show this problem. > Wild guess is that it depends somehow on the HTTP-headers of the .NET client. These are the headers captured via Fiddler-http-proxy on the client-side: > {noformat} > POST http://some.host.com/doce/Foo/Bar HTTP/1.1 > User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.3082) > Content-Type: text/xml; charset=utf-8 > SOAPAction: "http://host/some/soap-action/ws/addDocument" > Host: some.host.com > Content-Length: 6592 > Expect: 100-continue > Connection: Keep-Alive > Accept: application/json, text/plain, */* > {noformat} > There is a small change it's the same root-cause as [WFLY-2999]. Maybe I'll find the time to test this on 9.0.0-Beta1. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3889) JMX monitoring is extremely memory inefficient

by Koen Janssens (JIRA)

Koen Janssens created WFLY-3889: ----------------------------------- Summary: JMX monitoring is extremely memory inefficient Key: WFLY-3889 URL: https://issues.jboss.org/browse/WFLY-3889 Project: WildFly Issue Type: Bug Components: JMX Affects Versions: 9.0.0.Alpha1, JBoss AS7 7.1.1.Final Reporter: Koen Janssens Assignee: Kabir Khan When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created. A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class. More background on associated forum thread -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-123) Logging color "clear" not accepted by logging subsystem

by Kyle Lape (JIRA)

Kyle Lape created WFCORE-123: -------------------------------- Summary: Logging color "clear" not accepted by logging subsystem Key: WFCORE-123 URL: https://issues.jboss.org/browse/WFCORE-123 Project: WildFly Core Issue Type: Bug Components: Logging Reporter: Kyle Lape Assignee: James Perkins {{clear}} is a valid color in the JBoss LogManager {{ColorMap}} class, but it is not accepted in the logging subsystem {{color-map}} attribute pattern. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

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