July 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-2967) Incorrect implementation of the Timer service

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2967?page=all ] Dimitris Andreadis updated JBAS-2967: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Incorrect implementation of the Timer service > --------------------------------------------- > > Key: JBAS-2967 > URL: http://jira.jboss.com/jira/browse/JBAS-2967 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Scheduling/Timers > Affects Versions: JBossAS-4.0.1 Final, JBossAS-4.0.0 Final, JBossAS-4.0.2 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1, JBossAS-4.0.3RC1, JBossAS-4.0.3RC2, JBossAS-4.0.4RC1, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1 > Environment: Any > Reporter: Andrei Iltchenko > Fix For: JBossAS-4.0.6.CR1 > > > JBoss's implementation of the timer service doesn't account for a potential for SLSB instances of the same bean to concurrently access and modify the same Timer object (I learnt it when inspecting the pertinent source code). > Chapter 22 of the EJB 2.1 spec contains enough information for us to infer how a complaint container must behave provided that a given Timer > object is always accessed and modified in a transactional context: > ? If the reading SLSB instance accesses the Timer object before the transaction of the writing (cancelling) SLSB instance has committed, the reading instance mustn?t see that the timer has been cancelled (seeing it would defeat the very concept of a > transaction); otherwise > ? If the transaction of the writing (cancelling) SLSB instance has already committed, the container must > make the changes to the Timer object visible to the reading SLSB. The spec prescribes that in this case the reading SLSB instance must receive the javax.ejb.NoSuchObjectLocalException. > Thus changes to the state of a timer object (i.e. cancelling it) must be made visible to other instances of the same bean only when the transaction in which the timer was cancelled has been successfully committed. > When I studied JBoss code what I saw was quite alarming ? no effort is put into ensuring that a Timer object cancellation is not visible to other SLSBs that might read the Timer object until the transaction in which it was cancelled is committed. As soon as a SLSB instance cancells the Timer object (and before the transaction is committed or rolled back), all other SLSB instances of the same bean will see it as cancelled and will get > (potentially spurious) NoSuchObjectLocalExceptions. If the canceling transaction is then rolled back, all reading SLSB instances will suddenly succeed in > accessing it (because then the flag in the Timer object will be cleared) comments are mine: > if (status == Status.STATUS_ROLLEDBACK) > { > log.debug("rollback: " + this); > if (timerState == STARTED_IN_TX) > killTimer(); > else if (timerState == CANCELED_IN_TX) > // suddenly again active, even though other beans might already > // have seen it in the cancelled state. > setTimerState(ACTIVE); > I believe the same problem might happend with MDBs too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 12 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2865) Move org.jboss.naming package from server module to naming module

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2865?page=all ] Dimitris Andreadis updated JBAS-2865: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 JBossAS-5.0.1.CR1 (was: JBossAS-5.0.0.Beta) (was: JBossAS-4.0.5.CR1) > Move org.jboss.naming package from server module to naming module > ----------------------------------------------------------------- > > Key: JBAS-2865 > URL: http://jira.jboss.com/jira/browse/JBAS-2865 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Naming > Reporter: Scott M Stark > Assigned To: Scott M Stark > Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1 > > > The existence of the org.jboss.naming classes in the server module are another point for broken module dependencies. There are InitialContextFactory implementations in the security module that should subclass org.jboss.naming implementations (JBAS-2731 for example) but cannot due to server depending on security. Only naming integration services should exist in the server module. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 12 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2833) Externalizing the ServiceController configuration for injecting the configuration of the ServiceBinding aspect

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2833?page=all ] Dimitris Andreadis updated JBAS-2833: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Externalizing the ServiceController configuration for injecting the configuration of the ServiceBinding aspect > -------------------------------------------------------------------------------------------------------------- > > Key: JBAS-2833 > URL: http://jira.jboss.com/jira/browse/JBAS-2833 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: System service > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Dimitris Andreadis > Assigned To: Dimitris Andreadis > Fix For: JBossAS-4.0.6.CR1 > > > The ServiceBindingManager should really be an aspect applied to the ServiceController (see forum post). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 12 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2773) LRUEnterpriseContextCachePolicy should be updated to use org.jboss.util.TimerQueue instead of java.util.Timer

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2773?page=all ] Dimitris Andreadis updated JBAS-2773: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > LRUEnterpriseContextCachePolicy should be updated to use org.jboss.util.TimerQueue instead of java.util.Timer > ------------------------------------------------------------------------------------------------------------- > > Key: JBAS-2773 > URL: http://jira.jboss.com/jira/browse/JBAS-2773 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB2 > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Darran Lofthouse > Assigned To: Darran Lofthouse > Fix For: JBossAS-4.0.6.CR1 > > > LRUEnterpriseContextCachePolicy should be updated to use org.jboss.util.TimerQueue instead of java.util.Timer. > The java.util.Timer implementation does not handle runtime exceptions thrown from the tasks, if any task throws a runtime exception when it executes the timer thread is killed and no further timers will fire. > The classes EntitySynchronizationInterceptor, LRUEnterpriseContextCachePolicy and LRUStatefulContextCachePolicy all set tasks on the static timer referenced from LRUEnterpriseContextCachePolicy, if any one of these tasks fail all of the timers are affected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 12 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2731) JndiLoginInitialContextFactory still extends org.jnp.interfaces.NamingContextFactory

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2731?page=all ] Dimitris Andreadis updated JBAS-2731: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > JndiLoginInitialContextFactory still extends org.jnp.interfaces.NamingContextFactory > ------------------------------------------------------------------------------------ > > Key: JBAS-2731 > URL: http://jira.jboss.com/jira/browse/JBAS-2731 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Arto Huusko > Assigned To: Scott M Stark > Fix For: JBossAS-4.0.6.CR1 > > > org.jboss.security.jndi.JndiLoginInitialContextFactory still extends org.jnp.interfaces.NamingContextFactory. This leads to problems with, for example, UserTransaction lookups (see JBAS-1270). > Changing the class to extend org.jboss.naming.NamingContextFactory makes it work properly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 12 months

1
0
0 / 0

[JBoss JIRA] Created: (JBSEAM-318) ViewHandler.createView using SeamViewHandler.calculateLocale tries to use already released FacesContext when used outside lifecycle

by Tuomas Kiviaho (JIRA)

ViewHandler.createView using SeamViewHandler.calculateLocale tries to use already released FacesContext when used outside lifecycle ----------------------------------------------------------------------------------------------------------------------------------- Key: JBSEAM-318 URL: http://jira.jboss.com/jira/browse/JBSEAM-318 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.0.1 Environment: JBoss 4.0.4.GA MyFaces 1.1.3 Reporter: Tuomas Kiviaho ViewHandler.createView can't be used outside lifecycle phases. The locale calculation done by seam view handler using locale selector ends up in a NullPointerException (should propably be t be IllegalStateException) in MyFaces external context implementation if FacesContext had already been consumed by Seam threadlocals (Contexts) One could ask why I am using createView outside lifecycle, but this is what happens when done so. StackTrace (NullPointerException): ApplicationMap.getAttribute(String) line: 42 ApplicationMap(AbstractAttributeMap).get(Object) line: 87 FacesApplicationContext.get(String) line: 46 FacesApplicationContext.get(Class) line: 79 Init.instance() line: 95 Component.getInstanceFromFactory(String) line: 1199 Component.getInstance(String, boolean, Object) line: 1176 Component.getInstance(String, ScopeType, boolean) line: 1169 LocaleSelector.instance() line: 123 SeamViewHandler.calculateLocale(FacesContext) line: 32 JspViewHandlerImpl.createView(FacesContext, String) line: 130 To tacle the symptom: 1. FacesContext.getExternalContext could be used inside Seam's FacesApplicationContext instead of direct reference to see if the context has been released by catching the IllegalStateException that MyFaces throws. 2. Using external context with RuntimeException precaution (3. Blame the messenger) But what then can be done inside Seam goes beyond my knowledge, since Seam's component instantiation is a core part of the system. Of course this step can be left alone just by a try/catch around locale selector instantiation and continuing with a warning. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 12 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2523) Add a multi-thread option to JndiLoginInitialContextFactory.

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2523?page=all ] Dimitris Andreadis updated JBAS-2523: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Add a multi-thread option to JndiLoginInitialContextFactory. > ------------------------------------------------------------ > > Key: JBAS-2523 > URL: http://jira.jboss.com/jira/browse/JBAS-2523 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Scott M Stark > Assigned To: Scott M Stark > Fix For: JBossAS-4.0.6.CR1 > > > The JndiLoginInitialContextFactory just uses the SecurityAssociation in whatever threading mode its configured for and has no multi-threaded option like the ClientLoginModule does. One should be added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 12 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2688) Externalize the MainDeployer subdeployment ordering logic

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2688?page=all ] Dimitris Andreadis updated JBAS-2688: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Externalize the MainDeployer subdeployment ordering logic > --------------------------------------------------------- > > Key: JBAS-2688 > URL: http://jira.jboss.com/jira/browse/JBAS-2688 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Scott M Stark > Fix For: JBossAS-4.0.6.CR1 > > > The MainDeployer uses a org.jboss.deployment.DeploymentSorter to order subdeployments to determine the implicit start ordering. This should be externalized to be overridable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 12 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2412) Update the logging framework

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2412?page=all ] Dimitris Andreadis updated JBAS-2412: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Update the logging framework > ---------------------------- > > Key: JBAS-2412 > URL: http://jira.jboss.com/jira/browse/JBAS-2412 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Logging > Reporter: Scott M Stark > Fix For: JBossAS-4.0.6.CR1 > > > Its been a long time since we revisted the logging framework and the use of log4j as the default. I looked at having better seamless integration with the jdk java.util.logging framework using a port of the log4j appenders/layout to jdk handlers/formatters and the initial prototype is in head as mentioned in the linked forum thread. > We need to reevaluate what the default logging implementation should be along with what updates the Log4jService needs. Some things to think about: > 1. Using a log4j implementation that does not suffer from the current deadlock problem > 2. How to nlog4j, slf4j, commons logging fit into the picture > 3. Generalization of the Log4jService into one that works for whatever the default implementation is > 3a. Add support for redirecting stderr, stdout to seperate log files instead of all loggers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 12 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2408) JCA1.5 EJB3 integration

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2408?page=all ] Dimitris Andreadis updated JBAS-2408: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) Assignee: Weston Price Deferring and assigning to Weston > JCA1.5 EJB3 integration > ----------------------- > > Key: JBAS-2408 > URL: http://jira.jboss.com/jira/browse/JBAS-2408 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1 > Reporter: Adrian Brock > Assigned To: Weston Price > Fix For: JBossAS-4.0.6.CR1 > > > Need to refactor JCA1.5 inbound messaging to work with both EJB2.1 and EJB3.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 12 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2006