Finally realised what was going on with this.
I had a LoginAction:
@Stateful
| @Scope(ScopeType.EVENT)
| public class LoginAction implements Login, Serializable
| {
| @Out
| SessionTimeoutHander sessionTimeoutHander;
|
| ...
|
| public String login() {
| ...
|
| sessionTimeoutHander = Component.getInstance("sessionTimeoutHander");
|
| ...
| }
| }
If a user had made a successful login twice within the same HTTP session (e.g.
login, hit back button, login again - surprisingly, this scenario shows up
quite a lot in my access logs!), the call to getInstance() would introduce a
duplicate object. When the SFSB destruction code ran, I got the
ConcurrentModificationException.
The solution was to handle the creation of the sessionTimeoutHandler using a
regular @In(create=true) against sessionTimeoutHandler and remove the call to
getInstance(). I was assuming that my code above was equivalent to
@In(create=true), but clearly it is not.
Although there was no apparent problem in my application, because of exception
raised during the SFSB clean-up there may be a potential memory leak situation
since EJB3 cannot successfully destroy objects. The exceptions were recurring
which would suggest that the objects are being held onto which supports this
theory.
Hope this helps,
Cheers,
Chris.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016302#4016302
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016302
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
