7:16 a.m.
Race condition in component initialization
------------------------------------------
Key: JBSEAM-3999
URL: https://jira.jboss.org/jira/browse/JBSEAM-3999
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.1.GA
Reporter: Stuart Douglas
When starting up application (or session) scoped component that do not have an @Startup
annotation it is possible to get a race condition where two instances of the component are
instantiated, as no locking is present in component initialization. I ran into this when
my multi-threaded reporting process was the first component to hit the cache and jboss
cache provider got instantiated twice:
`16:54:48,717 INFO [JbossCacheProvider] Starting JBoss Treecache 1.x
16:54:48,717 INFO [JbossCacheProvider] Starting JBoss Treecache 1.x`
In this case it is easy to work around, by simply adding startup="true" to the
application scoped component. It is also possible to make calls on a component before the
create method is called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:32 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Assigned: (JBSEAM-3999) Race condition in component initialization
[
https://jira.jboss.org/jira/browse/JBSEAM-3999?page=com.atlassian.jira.pl...
]
Norman Richards reassigned JBSEAM-3999:
---------------------------------------
Assignee: Norman Richards
Race condition in component initialization
------------------------------------------
Key: JBSEAM-3999
URL: https://jira.jboss.org/jira/browse/JBSEAM-3999
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.1.GA
Reporter: Stuart Douglas
Assignee: Norman Richards
When starting up application (or session) scoped component that do not have an @Startup
annotation it is possible to get a race condition where two instances of the component are
instantiated, as no locking is present in component initialization. I ran into this when
my multi-threaded reporting process was the first component to hit the cache and jboss
cache provider got instantiated twice:
`16:54:48,717 INFO [JbossCacheProvider] Starting JBoss Treecache 1.x
16:54:48,717 INFO [JbossCacheProvider] Starting JBoss Treecache 1.x`
In this case it is easy to work around, by simply adding startup="true" to the
application scoped component. It is also possible to make calls on a component before the
create method is called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:38 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3999) Race condition in component initialization
[
https://jira.jboss.org/jira/browse/JBSEAM-3999?page=com.atlassian.jira.pl...
]
Norman Richards commented on JBSEAM-3999:
-----------------------------------------
I've verified the race condition. Although we've known that components are
registered before they are completely initialized, I didn't realize there was
potential for duplicate instances to be created. Since these are application-scoped
components, I think we can justify some sort of synchronization around new instance
creation. Since conversations are already serialized, this shouldn't be a big issue
for other scopes.
Race condition in component initialization
------------------------------------------
Key: JBSEAM-3999
URL: https://jira.jboss.org/jira/browse/JBSEAM-3999
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.1.GA
Reporter: Stuart Douglas
Assignee: Norman Richards
When starting up application (or session) scoped component that do not have an @Startup
annotation it is possible to get a race condition where two instances of the component are
instantiated, as no locking is present in component initialization. I ran into this when
my multi-threaded reporting process was the first component to hit the cache and jboss
cache provider got instantiated twice:
`16:54:48,717 INFO [JbossCacheProvider] Starting JBoss Treecache 1.x
16:54:48,717 INFO [JbossCacheProvider] Starting JBoss Treecache 1.x`
In this case it is easy to work around, by simply adding startup="true" to the
application scoped component. It is also possible to make calls on a component before the
create method is called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:40 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3999) Race condition in component initialization
[
https://jira.jboss.org/jira/browse/JBSEAM-3999?page=com.atlassian.jira.pl...
]
Norman Richards commented on JBSEAM-3999:
-----------------------------------------
Actually, I suppose session scoped components components would be affected too.
Race condition in component initialization
------------------------------------------
Key: JBSEAM-3999
URL: https://jira.jboss.org/jira/browse/JBSEAM-3999
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.1.GA
Reporter: Stuart Douglas
Assignee: Norman Richards
When starting up application (or session) scoped component that do not have an @Startup
annotation it is possible to get a race condition where two instances of the component are
instantiated, as no locking is present in component initialization. I ran into this when
my multi-threaded reporting process was the first component to hit the cache and jboss
cache provider got instantiated twice:
`16:54:48,717 INFO [JbossCacheProvider] Starting JBoss Treecache 1.x
16:54:48,717 INFO [JbossCacheProvider] Starting JBoss Treecache 1.x`
In this case it is easy to work around, by simply adding startup="true" to the
application scoped component. It is also possible to make calls on a component before the
create method is called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:44 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3999) Race condition in component initialization
[
https://jira.jboss.org/jira/browse/JBSEAM-3999?page=com.atlassian.jira.pl...
]
Toshiya Kobayashi commented on JBSEAM-3999:
-------------------------------------------
In case of org.jboss.seam.drools.RuleBase, Seam allows the 2nd thread to access the
component which is not properly instantiated and results in
"java.lang.IllegalArgumentException: Could not invoke method by reflection:
RuleBasedIdentity.setSecurityRules(org.drools.RuleBase) with parameters:
(org.jboss.seam.drools.RuleBase) on: org.jboss.seam.security.RuleBasedIdentity"
Since org.jboss.seam.drools.RuleBase is an application scoped component, you can add
startup="true" to work around.
Race condition in component initialization
------------------------------------------
Key: JBSEAM-3999
URL: https://jira.jboss.org/jira/browse/JBSEAM-3999
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.1.GA
Reporter: Stuart Douglas
Assignee: Norman Richards
When starting up application (or session) scoped component that do not have an @Startup
annotation it is possible to get a race condition where two instances of the component are
instantiated, as no locking is present in component initialization. I ran into this when
my multi-threaded reporting process was the first component to hit the cache and jboss
cache provider got instantiated twice:
`16:54:48,717 INFO [JbossCacheProvider] Starting JBoss Treecache 1.x
16:54:48,717 INFO [JbossCacheProvider] Starting JBoss Treecache 1.x`
In this case it is easy to work around, by simply adding startup="true" to the
application scoped component. It is also possible to make calls on a component before the
create method is called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:26 p.m.
New subject: [JBoss JIRA] Updated: (JBSEAM-3999) Race condition in component initialization
[
https://jira.jboss.org/jira/browse/JBSEAM-3999?page=com.atlassian.jira.pl...
]
Pete Muir updated JBSEAM-3999:
------------------------------
Assignee: (was: Norman Richards)
Race condition in component initialization
------------------------------------------
Key: JBSEAM-3999
URL: https://jira.jboss.org/jira/browse/JBSEAM-3999
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.1.GA
Reporter: Stuart Douglas
When starting up application (or session) scoped component that do not have an @Startup
annotation it is possible to get a race condition where two instances of the component are
instantiated, as no locking is present in component initialization. I ran into this when
my multi-threaded reporting process was the first component to hit the cache and jboss
cache provider got instantiated twice:
`16:54:48,717 INFO [JbossCacheProvider] Starting JBoss Treecache 1.x
16:54:48,717 INFO [JbossCacheProvider] Starting JBoss Treecache 1.x`
In this case it is easy to work around, by simply adding startup="true" to the
application scoped component. It is also possible to make calls on a component before the
create method is called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:04 p.m.
New subject: [JBoss JIRA] Commented: (JBSEAM-3999) Race condition in component initialization
[
https://jira.jboss.org/browse/JBSEAM-3999?page=com.atlassian.jira.plugin....
]
Mike Pettypiece commented on JBSEAM-3999:
-----------------------------------------
Same issue when two users log in at the exact same time before any other logins have
occurred - Configuration.instance() is called from Identity.getLoginContext() twice.
java.lang.IllegalArgumentException: factory method with defined scope outjected a value:
org.jboss.seam.security.configuration
at org.jboss.seam.Component.handleFactoryMethodResult(Component.java:2108)
at org.jboss.seam.Component.getInstanceFromFactory(Component.java:2081)
at org.jboss.seam.Component.getInstance(Component.java:2011)
at org.jboss.seam.Component.getInstance(Component.java:1983)
at org.jboss.seam.Component.getInstance(Component.java:1977)
at org.jboss.seam.Component.getInstance(Component.java:1972)
at org.jboss.seam.security.Configuration.instance(Configuration.java:73)
at org.jboss.seam.security.Identity.getLoginContext(Identity.java:419)
at org.jboss.seam.security.Identity.authenticate(Identity.java:332)
Solution in this case is to call Configuration.instance() in a @Startup component.
Race condition in component initialization
------------------------------------------
Key: JBSEAM-3999
URL: https://jira.jboss.org/browse/JBSEAM-3999
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.1.GA
Reporter: Stuart Douglas
When starting up application (or session) scoped component that do not have an @Startup
annotation it is possible to get a race condition where two instances of the component are
instantiated, as no locking is present in component initialization. I ran into this when
my multi-threaded reporting process was the first component to hit the cache and jboss
cache provider got instantiated twice:
`16:54:48,717 INFO [JbossCacheProvider] Starting JBoss Treecache 1.x
16:54:48,717 INFO [JbossCacheProvider] Starting JBoss Treecache 1.x`
In this case it is easy to work around, by simply adding startup="true" to the
application scoped component. It is also possible to make calls on a component before the
create method is called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5122
days inactive
5588
days old
6 comments
5 participants
participants (5)
-
Mike Pettypiece (JIRA) -
Norman Richards (JIRA)
-
Pete Muir (JIRA)
-
Stuart Douglas (JIRA)
-
Toshiya Kobayashi (JIRA)