April 2014 - jboss-jira - Jboss List Archives

[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 testing. Normally, only the call to event really needs to be synced, I'll leave process out of it. > 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 > Attachments: JBWEB-297.diff > > > 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] (JBWEB-297) NIO can improperly lead to request/response objects being used concurrently

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/JBWEB-297?page=com.atlassian.jira.plugin.... ] Aaron Ogburn commented on JBWEB-297: ------------------------------------ Yeah, looks like it is not reproduced any longer with NioEndpoint.ChannelProcessor.run() synced as exampled in JBWEB-297.diff. Thanks, Remy. > 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 > Attachments: JBWEB-297.diff > > > 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] (JBWEB-297) NIO can improperly lead to request/response objects being used concurrently

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/JBWEB-297?page=com.atlassian.jira.plugin.... ] Aaron Ogburn updated JBWEB-297: ------------------------------- Attachment: JBWEB-297.diff > 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 > Attachments: JBWEB-297.diff > > > 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-3278) add-user for user admin / password admin says password must not match username but should say should

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-3278: -------------------------------------- Summary: add-user for user admin / password admin says password must not match username but should say should Key: WFLY-3278 URL: https://issues.jboss.org/browse/WFLY-3278 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management, Scripts Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 8.1.0.Final -- 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] (JGRP-1831) Differentiate exception from remote methods and JGroups Framework

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1831?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1831. ---------------------------- Resolution: Done > Differentiate exception from remote methods and JGroups Framework > ------------------------------------------------------------------- > > Key: JGRP-1831 > URL: https://issues.jboss.org/browse/JGRP-1831 > Project: JGroups > Issue Type: Feature Request > Reporter: Bastien Aracil > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > Looking at the API and code, it seems there is no clean way to differentiate the exceptions thrown by the called method/service and those thrown by JGroups Framework (timeout, supected, unreachable, serialization error and such). > Exception thrown by the called method/service should be wrap in an specific exception (like InvocationTargetException) to ease the exception handling by the developper. -- 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-456) ResourceConfigurationImpl class not found when using drools-karaf-feature

by Charles Moulliard (JIRA)

[ https://issues.jboss.org/browse/DROOLS-456?page=com.atlassian.jira.plugin... ] Charles Moulliard commented on DROOLS-456: ------------------------------------------ Can you please do a refresh of the bundle org.kie.internalapi [290] to see if the bundle will import the package 'org.drools.core.builder.conf.impl' ? If the problem is still there, then we need a test case to reproduce the issue ? > ResourceConfigurationImpl class not found when using drools-karaf-feature > ------------------------------------------------------------------------- > > Key: DROOLS-456 > URL: https://issues.jboss.org/browse/DROOLS-456 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Beta1 > Reporter: Gary Brown > Assignee: Mario Fusco > Attachments: fuse-drools-issue.log > > > While porting RTGov to Karaf, I have been using Drools 2.0.0.CR5 successfully. > However when I updated the version to 2.0.1.Final, and subsequently to 2.1.0.Beta1, I now get a class not found issue: > {noformat} > 11:26:49,440 | ERROR | l Console Thread | ResourceTypeImpl | 290 - org.kie.internalapi - 6.1.0.20140307-1723 | Error loading resource configuration from properties > java.lang.ClassNotFoundException: org.drools.core.builder.conf.impl.ResourceConfigurationImpl not found by org.kie.internalapi [290] > at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)[org.apache.felix.framework-4.0.3.redhat-610355.jar:] > at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)[org.apache.felix.framework-4.0.3.redhat-610355.jar:] > at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955) > at java.lang.ClassLoader.loadClass(ClassLoader.java:356)[:1.7.0_07] > at java.lang.Class.forName0(Native Method)[:1.7.0_07] > at java.lang.Class.forName(Class.java:186)[:1.7.0_07] > at org.kie.internal.io.ResourceTypeImpl.fromProperties(ResourceTypeImpl.java:41)[290:org.kie.internalapi:6.1.0.20140307-1723] > {noformat} -- 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-1524) Add main-class to the org.jboss.jandex module.xml to make it easier to run jandex

by Michael Reynolds (JIRA)

[ https://issues.jboss.org/browse/WFLY-1524?page=com.atlassian.jira.plugin.... ] Michael Reynolds commented on WFLY-1524: ---------------------------------------- would this cover adding a binary .sh/.bat script, or just updating the module with a main class? > Add main-class to the org.jboss.jandex module.xml to make it easier to run jandex > --------------------------------------------------------------------------------- > > Key: WFLY-1524 > URL: https://issues.jboss.org/browse/WFLY-1524 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Jason Greene > Priority: Minor > > Adding main-class will let JBoss Modules know the class to run and allow you to run jandex via java -jar $JBOSS_HOME/jboss-modules -mp $JBOSS_HOME/modules org.jboss.jandex > <module xmlns="urn:jboss:module:1.1" name="org.jboss.jandex"> > ... > <main-class name="org.jboss.jandex.Main"/> > ... -- 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-3275) Make log4j test scoped dependency

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3275?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3275: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1085730 > Make log4j test scoped dependency > --------------------------------- > > Key: WFLY-3275 > URL: https://issues.jboss.org/browse/WFLY-3275 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > Fix For: 8.1.0.Final, 9.0.0.CR1 > > > There's no real need for a log4j dependency except for some tests. Currently the log4j module is aliased to {{org.jboss.log4j.logmanager}}. -- 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-3275) Make log4j test scoped dependency

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3275?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3275: ----------------------------------------------- James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1085730|https://bugzilla.redhat.com/show_bug.cgi?id=1085730] from NEW to POST > Make log4j test scoped dependency > --------------------------------- > > Key: WFLY-3275 > URL: https://issues.jboss.org/browse/WFLY-3275 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > Fix For: 8.1.0.Final, 9.0.0.CR1 > > > There's no real need for a log4j dependency except for some tests. Currently the log4j module is aliased to {{org.jboss.log4j.logmanager}}. -- 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] (SECURITY-799) Port the fallback to BASIC auth fix from branch security-negotiation-2.1.x

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-799?page=com.atlassian.jira.plug... ] Darran Lofthouse resolved SECURITY-799. --------------------------------------- Resolution: Done > Port the fallback to BASIC auth fix from branch security-negotiation-2.1.x > -------------------------------------------------------------------------- > > Key: SECURITY-799 > URL: https://issues.jboss.org/browse/SECURITY-799 > Project: PicketBox > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: Negotiation_2_3_1_Final > > Attachments: NegotiationAuthenticator.java > > > The following two commits need to be pulled to master before 2.3.1 is tagged. > https://github.com/wildfly/jboss-negotiation/commit/3a9ca05459edd6e4d3f37... > https://github.com/wildfly/jboss-negotiation/commit/6edd2b0d30ff578bc3197... -- 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