April 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-460) Eval does not behave as intended

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-460?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-460. -------------------------------- Fix Version/s: 6.1.0.Beta3 Resolution: Done > Eval does not behave as intended > -------------------------------- > > Key: DROOLS-460 > URL: https://issues.jboss.org/browse/DROOLS-460 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Final > Reporter: Fabian Meyer > Assignee: Mario Fusco > Fix For: 6.1.0.Beta3 > > > Under certain conditions, eval does not behave as intended, when nested in a sub-network. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-297) NIO can improperly lead to request/response objects being used concurrently

by Remy Maucherat (JIRA)

[ https://issues.jboss.org/browse/JBWEB-297?page=com.atlassian.jira.plugin.... ] Remy Maucherat commented on JBWEB-297: -------------------------------------- Ok, thanks for the work on this. Can you confirm the simple sync I sent you in NioEndpoint.ChannelProcessor.run() I sent you fixes it for your test case ? > NIO can improperly lead to request/response objects being used concurrently > --------------------------------------------------------------------------- > > Key: JBWEB-297 > URL: https://issues.jboss.org/browse/JBWEB-297 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat > Affects Versions: JBossWeb-7.2.2.GA, JBossWeb-7.3.0.GA, JBossWeb-7.4.0.GA > Reporter: Aaron Ogburn > Assignee: Remy Maucherat > > Using NIO with async servlets can improperly lead to a processor and its request/response objects being used by multiple threads to process different requests at once. The problem arises here in Http11NioProtocol.event(): > {code:title=Http11NioProtocol.java|borderStyle=solid} > public SocketState event(NioChannel channel, SocketStatus status) { > Http11NioProcessor processor = connections.get(channel.getId()); > SocketState state = SocketState.CLOSED; > if (processor != null) { > processor.startProcessing(); > // Call the appropriate event > try { > state = processor.event(status); > } catch (java.net.SocketException e) { > // SocketExceptions are normal > CoyoteLogger.HTTP_NIO_LOGGER.socketException(e); > } catch (java.io.IOException e) { > // IOExceptions are normal > CoyoteLogger.HTTP_NIO_LOGGER.socketException(e); > } > // Future developers: if you discover any other > // rare-but-nonfatal exceptions, catch them here, and log as > // above. > catch (Throwable e) { > // any other exception or error is odd. Here we log it > // with "ERROR" level, so it will show up even on > // less-than-verbose logs. > CoyoteLogger.HTTP_NIO_LOGGER.socketError(e); > } finally { > if (state != SocketState.LONG) { > connections.remove(channel.getId()); > recycledProcessors.offer(processor); > {code} > If two events occur on the same channel and execute this at the same time, it'll lead to this issue if they result in a SocketState other than LONG. When that happens, they both offer the same processor to recycledProcessors in the finally block. Later on, two different requests can then poll the same processor at once from reycledProcessors; a processor should only ever have one entry in recycledProcessors. > It looks like we need to synch the Http11NioProtocol.event() call or the NioEndpoint.ChannelProcessor.run(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-460) Eval does not behave as intended

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-460?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-460: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1089285|https://bugzilla.redhat.com/show_bug.cgi?id=1089285] from NEW to ASSIGNED > Eval does not behave as intended > -------------------------------- > > Key: DROOLS-460 > URL: https://issues.jboss.org/browse/DROOLS-460 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Final > Reporter: Fabian Meyer > Assignee: Mario Fusco > > Under certain conditions, eval does not behave as intended, when nested in a sub-network. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-460) Eval does not behave as intended

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-460?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-460: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Eval does not behave as intended > -------------------------------- > > Key: DROOLS-460 > URL: https://issues.jboss.org/browse/DROOLS-460 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Final > Reporter: Fabian Meyer > Assignee: Mario Fusco > > Under certain conditions, eval does not behave as intended, when nested in a sub-network. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-297) NIO can improperly lead to request/response objects being used concurrently

by Aaron Ogburn (JIRA)

Aaron Ogburn created JBWEB-297: ---------------------------------- Summary: NIO can improperly lead to request/response objects being used concurrently Key: JBWEB-297 URL: https://issues.jboss.org/browse/JBWEB-297 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Tomcat Affects Versions: JBossWeb-7.2.2.GA, JBossWeb-7.3.0.GA, JBossWeb-7.4.0.GA Reporter: Aaron Ogburn Assignee: Remy Maucherat Using NIO with async servlets can improperly lead to a processor and its request/response objects being used by multiple threads to process different requests at once. The problem arises here in Http11NioProtocol.event(): {code:title=Http11NioProtocol.java|borderStyle=solid} public SocketState event(NioChannel channel, SocketStatus status) { Http11NioProcessor processor = connections.get(channel.getId()); SocketState state = SocketState.CLOSED; if (processor != null) { processor.startProcessing(); // Call the appropriate event try { state = processor.event(status); } catch (java.net.SocketException e) { // SocketExceptions are normal CoyoteLogger.HTTP_NIO_LOGGER.socketException(e); } catch (java.io.IOException e) { // IOExceptions are normal CoyoteLogger.HTTP_NIO_LOGGER.socketException(e); } // Future developers: if you discover any other // rare-but-nonfatal exceptions, catch them here, and log as // above. catch (Throwable e) { // any other exception or error is odd. Here we log it // with "ERROR" level, so it will show up even on // less-than-verbose logs. CoyoteLogger.HTTP_NIO_LOGGER.socketError(e); } finally { if (state != SocketState.LONG) { connections.remove(channel.getId()); recycledProcessors.offer(processor); {code} If two events occur on the same channel and execute this at the same time, it'll lead to this issue if they result in a SocketState other than LONG. When that happens, they both offer the same processor to recycledProcessors in the finally block. Later on, two different requests can then poll the same processor at once from reycledProcessors; a processor should only ever have one entry in recycledProcessors. It looks like we need to synch the Http11NioProtocol.event() call or the NioEndpoint.ChannelProcessor.run(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3277) Fix for JAVASERVERFACES-3189 causes memory leak

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3277?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3277: ------------------------------ Attachment: capedwarf-test.war Problem can be easily reproduced by attached war. Deploy it, undeploy it and do memory dump with profiler then look for "DeploymentUnit" instances > Fix for JAVASERVERFACES-3189 causes memory leak > ----------------------------------------------- > > Key: WFLY-3277 > URL: https://issues.jboss.org/browse/WFLY-3277 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF > Affects Versions: 8.1.0.CR1 > Reporter: Tomaz Cerar > Assignee: Farah Juma > Priority: Critical > Fix For: 8.1.0.Final > > Attachments: capedwarf-test.war > > > Running capedwarf testsuite we found out that after upgrade to 8.1.0.CR1 testsuite does not complete as server dies with OOM. > I traced problem down to this commit: https://github.com/jboss/mojarra/commit/d0f9f873dc0f99047a0a5031631d091fa... > reverting it fixes the problem. > For what is worth, I think original problem comes from fact that we somehow register two ConfigureListeners for every deployment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3277) Fix for JAVASERVERFACES-3189 causes memory leak

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3277?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3277: ------------------------------ Priority: Blocker (was: Critical) > Fix for JAVASERVERFACES-3189 causes memory leak > ----------------------------------------------- > > Key: WFLY-3277 > URL: https://issues.jboss.org/browse/WFLY-3277 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF > Affects Versions: 8.1.0.CR1 > Reporter: Tomaz Cerar > Assignee: Farah Juma > Priority: Blocker > Fix For: 8.1.0.Final > > Attachments: capedwarf-test.war > > > Running capedwarf testsuite we found out that after upgrade to 8.1.0.CR1 testsuite does not complete as server dies with OOM. > I traced problem down to this commit: https://github.com/jboss/mojarra/commit/d0f9f873dc0f99047a0a5031631d091fa... > reverting it fixes the problem. > For what is worth, I think original problem comes from fact that we somehow register two ConfigureListeners for every deployment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3277) Fix for JAVASERVERFACES-3189 causes memory leak

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-3277: --------------------------------- Summary: Fix for JAVASERVERFACES-3189 causes memory leak Key: WFLY-3277 URL: https://issues.jboss.org/browse/WFLY-3277 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: JSF Affects Versions: 8.1.0.CR1 Reporter: Tomaz Cerar Assignee: Farah Juma Priority: Critical Fix For: 8.1.0.Final Running capedwarf testsuite we found out that after upgrade to 8.1.0.CR1 testsuite does not complete as server dies with OOM. I traced problem down to this commit: https://github.com/jboss/mojarra/commit/d0f9f873dc0f99047a0a5031631d091fa... reverting it fixes the problem. For what is worth, I think original problem comes from fact that we somehow register two ConfigureListeners for every deployment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-921) Context initialization exceptions are swallowed on deployment

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-921?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on WFLY-921: ---------------------------------- Great! For future reference though, EAP bugs are tracked at https://bugzilla.redhat.com in BugZilla. > Context initialization exceptions are swallowed on deployment > ------------------------------------------------------------- > > Key: WFLY-921 > URL: https://issues.jboss.org/browse/WFLY-921 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EE > Environment: Windows 7 > Reporter: Jarkko Rantavuori > Assignee: David Lloyd > Attachments: jboss-7.1.1.-stacktrace-beans.txt, jboss-7.1.1.-stacktrace-namespace.txt, jboss-7.2.0.-stacktrace-namespace.txt, spring-app-1.0.0-BUILD-SNAPSHOT-startupexception.war > > > On 7.2.0.Alpha1, trying to deploy a simple spring app with problems in context initialization, all exceptions are swallowed, and only a meaningless error > org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161) > is shown, making it impossible to find out the root cause. > On 7.1.1., meaningful exception is shown, like > Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.osgi.org/xmlns/blueprint/v1.0.0] > Offending resource: ServletContext resource [/WEB-INF/spring/root-context.xml] > or > org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException > Caused by: org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 108; cvc-elt.1: Cannot find the declaration of element 'beans'. > which allows the developer to fix the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3274) connector values are not available like "requestCount , maxTime, bytesReceived etc " in wildfly (domain mode) 8.0.0.Final

by Rituraj Sinha (JIRA)

[ https://issues.jboss.org/browse/WFLY-3274?page=com.atlassian.jira.plugin.... ] Rituraj Sinha edited comment on WFLY-3274 at 4/22/14 7:39 AM: -------------------------------------------------------------- Hi Kabir, Thanks for replying i had raised the same on the community as well on 18th/04/2014 here is the link https://community.jboss.org/message/869273#869273 Thanks RIturaj was (Author: rituraj): Hi Kabir, Thanks for replying i have raised the same on the community as well here is the link https://community.jboss.org/message/869273#869273 Thanks RIturaj > connector values are not available like "requestCount , maxTime, bytesReceived etc " in wildfly (domain mode) 8.0.0.Final > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3274 > URL: https://issues.jboss.org/browse/WFLY-3274 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Reporter: Rituraj Sinha > Assignee: Tomaz Cerar > > while using jboss 7.2.0 we were able to fetch above values from the cli command as > {noformat} > [domain@test.com:9999 subsystem=web] ls > configuration valve default-virtual-server=default-host native=false > connector virtual-server instance-id=${jboss.node.name} > [domain@test.com:9999 connector] ls > ajp http > [domain@test.com:9999 connector] cd http > [domain@test.com:9999 connector] pwd > /profile=ha/subsystem=web/connector=http > [domain@test.com:9999 connector=http] ls > configuration max-connections=undefined proxy-port=undefined > ssl max-post-size=2097152 redirect-port=443 > bytesReceived= max-save-post-size=4096 requestCount= > bytesSent= maxTime= scheme=http > enable-lookups=false name=http secure=false > enabled=true processingTime= socket-binding=http > errorCount= protocol=HTTP/1.1 virtual-server=undefined > executor=undefined proxy-name=undefined > {noformat} > > Now we have moved to wildfly8 and trying to look for the same values in underetow( as there is no "web" subsystem in wildfly8) > as below > {noformat} > [domain@test2.com:9990 subsystem=undertow] ls > buffer-cache server default-servlet-container=default statistics-enabled=false (Here there is no connector attribute available as this was in jboss 7.2.0 ) > configuration servlet-container default-virtual-host=default-host > error-page default-server=default-server instance-id=${jboss.node.name} > {noformat} > > but the listners(HTTP, AJP and HTTPS ) are defined in the server attribute...hence going into server attribute we get the below as > {noformat} > [domain@test2.com:9990 server=default-server] ls > ajp-listener host http-listener https-listener default-host=default-host servlet-container=default > {noformat} > after getting into http-listener we get the below > {noformat} > [domain@test2.com:9990 http-listener=default] ls > allow-encoded-slash=false certificate-forwarding=false max-cookies=200 max-post-size=10485760 socket-binding=http > always-set-keep-alive=true decode-url=true max-header-size=51200 proxy-address-forwarding=false url-charset=UTF-8 > buffer-pipelined-data=true enabled=true max-headers=200 record-request-start-time=false worker=default > buffer-pool=default max-buffered-request-size=16384 max-parameters=1000 redirect-socket=https > {noformat} > > Can someone please look into it ..? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 5 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 April 2014