April 2011 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4487) Concurrent requests; one invalidates the session, results in recursive loop of session creation

by dave atkins (JIRA)

Concurrent requests; one invalidates the session, results in recursive loop of session creation ----------------------------------------------------------------------------------------------- Key: JBSEAM-4487 URL: https://jira.jboss.org/jira/browse/JBSEAM-4487 Project: Seam Issue Type: Bug Components: Core Affects Versions: 2.2.0.GA, 2.2.0.CR1, 2.1.2.GA, 2.1.2.CR2, 2.1.2.CR1, 2.1.1.GA Environment: Jboss 4.2.2 with shipped Tomcat on Linux. Reporter: dave atkins I noticed that we had an massive number of sessions on one of our tomcat nodes that hosts our modest Seam app. After some investigation I discovered this in the log 2009-11-25 17:38:02,521 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.security.identity 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.security.identity 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session This is repeated for thousands of lines. After digging around the seam code I realised that if you have two concurrent requests and one invalidates the session before the other is finished, seam goes into an recursive loop of session creation (normally ended by stack overflow). Here's a stack trace showing two recursions. at org.jboss.seam.Component.newInstance(Component.java:2094) at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304) at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278) at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209) at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141) at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45) at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397) at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369) at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828) at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291) at org.apache.catalina.connector.Request.doGetSession(Request.java:2312) at org.apache.catalina.connector.Request.getSession(Request.java:2075) at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833) at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545) at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002) at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962) at org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110) at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189) at org.jboss.seam.Component.getInstance(Component.java:1949) at org.jboss.seam.Component.getInstance(Component.java:1944) at org.jboss.seam.Component.getInstance(Component.java:1924) at org.jboss.seam.Component.getInstance(Component.java:1919) at org.jboss.seam.security.Identity.create(Identity.java:101) at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144) at org.jboss.seam.Component.callComponentMethod(Component.java:2211) at org.jboss.seam.Component.callCreateMethod(Component.java:2134) at org.jboss.seam.Component.newInstance(Component.java:2094) at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304) at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278) at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209) at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141) at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45) at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397) at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369) at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828) at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291) at org.apache.catalina.connector.Request.doGetSession(Request.java:2312) at org.apache.catalina.connector.Request.getSession(Request.java:2075) at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833) at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545) at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002) at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962) at org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110) at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189) at org.jboss.seam.Component.getInstance(Component.java:1949) at org.jboss.seam.Component.getInstance(Component.java:1944) at org.jboss.seam.Component.getInstance(Component.java:1924) at org.jboss.seam.Component.getInstance(Component.java:1919) at org.jboss.seam.security.Identity.create(Identity.java:101) at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144) at org.jboss.seam.Component.callComponentMethod(Component.java:2211) at org.jboss.seam.Component.callCreateMethod(Component.java:2134) at org.jboss.seam.Component.newInstance(Component.java:2094) This problem is partially documented here - https://jira.jboss.org/jira/browse/JBSEAM-2888, unfortunately this bugfix didn't solve the root cause of the problem. The problem is caused by the SessionMap used by ServerConversationContext. Internally the session map uses HttpServletRequest.getSession(true) to retrieve the session, which creates a new session if the one defined on the HttpServletRequest is invalid or null. Unfortunately, when the new session is created session listeners are informed before the session has been set on the HttpServletRequest. Seam is one of these session listeners and creates a new Identity on session creation, which in turn accesses the SessionMap, still before the new Session has been set on the request. This leads to an infinite recursive loop. The SessionMap used is returned by externalContext.getSessionMap(). One solution could be to implement our own SessionMap that doesn't attempt to create a new session if the current session is invalid or null, although I've no idea how this would impact on other Seam code. The problem is relatively easy to create. In our application we have a search page that can take quite a while to complete a request. If we log out of the application in another tab before the search has completed the problem arises. We are using seam 2.1.1.GA. I've looked at the source code for the latest release and it appears that the problem will still occur due to use of SessionMap. Out current workaround is to add a ThreadLocal to Identity.create that counts recursive calls. If more then two recursive calls are detected an IllegalProcessState exception is thrown. This isn't definitely isn't a permanent solution, but stops our server creating 100,000 sessions. -- 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

12 years, 3 months

7
18
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3857) Include in docs a entity manager transaction flush behavior

by Rodrigo Souto (JIRA)

Include in docs a entity manager transaction flush behavior ----------------------------------------------------------- Key: JBSEAM-3857 URL: https://jira.jboss.org/jira/browse/JBSEAM-3857 Project: Seam Issue Type: Task Components: Documentation Issues, EJB3 Affects Versions: 2.1.1.CR1 Environment: documentation Reporter: Rodrigo Souto Priority: Optional Explain on reference doc (chapter 9.3. Seam-managed persistence contexts) that even if you are using a manual flush mode in your session bean, a transaction is flushed before any query. http://www.seamframework.org/Community/WhyEjbFunctionIsTryingToFlush -- 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

12 years, 3 months

2
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3759) Quartz example intermittent test suite failures

by Jay Balunas (JIRA)

Quartz example intermittent test suite failures ----------------------------------------------- Key: JBSEAM-3759 URL: https://jira.jboss.org/jira/browse/JBSEAM-3759 Project: Seam Issue Type: Bug Components: Examples, Test Harness Affects Versions: 2.1.1.CR1 Reporter: Jay Balunas Priority: Minor Fix For: 2.1.1.GA The quartz example unit tests fail intermittently. Since this is a timing test I am assuming there are times when the events are not fired as expected do to various system reasons. I have seen this in both hudson runs, and on my machine. Other users have also seen this. Usually just rerunning the tests solve the issue. Here is a sample build where the error has occurred: http://hudson.qa.jboss.com/hudson/job/Seam-trunk-JDK6/552/testReport/(roo... -- 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

12 years, 3 months

5
7
0 / 0

[JBoss JIRA] Created: (JBSEAM-4703) Migrate Seam DVDStore to the new Hibernate Search 3.2 APIs

by Emmanuel Bernard (JIRA)

Migrate Seam DVDStore to the new Hibernate Search 3.2 APIs ---------------------------------------------------------- Key: JBSEAM-4703 URL: https://jira.jboss.org/browse/JBSEAM-4703 Project: Seam Issue Type: Feature Request Reporter: Emmanuel Bernard Fix For: 3.0.0.BETA1 IndexerAction could use the massive indexer -- 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

12 years, 3 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4391) Need to add transaction propagation types to @Transactional

by asookazian (JIRA)

Need to add transaction propagation types to @Transactional ----------------------------------------------------------- Key: JBSEAM-4391 URL: https://jira.jboss.org/jira/browse/JBSEAM-4391 Project: Seam Issue Type: Feature Request Components: Core Affects Versions: 2.2.0.GA Environment: N/A Reporter: asookazian The current tx propagation types for use with @Transactional are the following: REQUIRED, MANDATORY, SUPPORTS, NEVER; Here is a comment from the TransactionalPropagationType enum class: * Transaction propagation strategies for Seam JavaBean components. Note that unlike EJB3 components, there are no strategies for suspending transactions. Please add REQUIRES_NEW and NOT_SUPPORTED. I am unable to solve my functional requirement of calling a webservice which inserts into remote db (which does not require a tx) and inserting into multiple local db tables (requires tx) using JavaBean components and Seam @Transactional. The requirement is that even if the webservice call fails, the local db inserts should continue and succeed (i.e. no atomicity, no rollback). There is an action method in my JavaBean Seam component that is invoked from a commandButton in JSF page. Then there are two private methods that are invoked from that public method. One requires tx support, the other does not. With EJB3, I would simply use NOT_SUPPORTED for one and REQUIRES_NEW for the other. Now using JavaBeans and @Transactional, I cannot solve my problem in terms of tx support requirements. @Transactional only works on public methods. I tried recalling the component's private method (now refactored to public with @Transactional) using Component.getInstance("foo"); but that did not work. Spring has robust tx support like EJB 3. Seam needs to be ramped up in terms of tx support for JavaBean components. References: http://www.seamframework.org/Community/TransactionalPropagationTypes http://www.seamframework.org/Community/TransactionalOnPrivateMethod -- 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

12 years, 4 months

3
5
0 / 0

[JBoss JIRA] Created: (JBSEAM-4512) BPM task does not rollback

by Jason E (JIRA)

BPM task does not rollback -------------------------- Key: JBSEAM-4512 URL: https://jira.jboss.org/jira/browse/JBSEAM-4512 Project: Seam Issue Type: Bug Components: BPM Affects Versions: 2.2.0.GA Environment: Testing this on Windows XP. Deploying to JBoss AS 4.2.2 Reporter: Jason E I have made a simple change to the ShipAction.java class in the dvdstore example that ships with Seam. Here is the change //@EndTask public String ship() { order.ship(track); TaskInstance ti = ManagedJbpmContext.instance().getTaskInstance(taskInstance.getId()); taskInstance.end(); if(true) throw new RuntimeException("TESTING"); return "admin"; } I commented out the end task annotation and I am ending the task via the TaskInstance API. When I throw the Runtime exception the changes to the ORDERS entity bean (i.e. updating the tracking number) rolls back. The problem is that the task instance change (i.e. ending the task) does not rollback. It appears that jBPM is flushing its changes in another db transaction. This seems like a bug since I would expect the ending of my task to also rollback. This seems like the desired behavior. This was the only change I made to the dvdstore example that ships with Seam 2.2.0.GA so it should be easy to reproduce. Thanks! Jason -- 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

12 years, 4 months

7
18
0 / 0

[JBoss JIRA] Created: (SEAMINTL-41) Messages cannot be used in TransactionPhase.AFTER_SUCCESS

by Jozef Hartinger (JIRA)

Messages cannot be used in TransactionPhase.AFTER_SUCCESS --------------------------------------------------------- Key: SEAMINTL-41 URL: https://issues.jboss.org/browse/SEAMINTL-41 Project: Seam International Issue Type: Bug Components: Messages Affects Versions: 3.0.0.Final Reporter: Jozef Hartinger Assignee: Ken Finnigan Fix For: 3.1.0.Alpha1 I am using the Seam Booking example (https://github.com/seam/examples/tree/3.0.0.Final) After a booking is made successfully, a message similar to "You're booked to stay at the Marriott Courtyard 5 days from now. " is supposed to be displayed on the web page. The message is set in an observer method. https://github.com/seam/examples/blob/3.0.0.Final/booking/src/main/java/o... Unfortunatelly, the message is never displayed. When the event is observed during TransactionPhase.IN_PROGRESS (i.e. public void onBookingComplete(@Observes @Confirmed final Booking booking)) , the message is displayed as expected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

10
22
0 / 0

[JBoss JIRA] Created: (SEAMINTL-7) Rewrite Messages API along the lines of JBoss Logging 3

by Ken Finnigan (JIRA)

Rewrite Messages API along the lines of JBoss Logging 3 ------------------------------------------------------- Key: SEAMINTL-7 URL: https://jira.jboss.org/browse/SEAMINTL-7 Project: Seam i18n Issue Type: Feature Request Components: Messages Affects Versions: 3.0.0.Alpha1 Reporter: Ken Finnigan Fix For: 3.0.0.Alpha2 Rewrite messages API along the lines of JBoss Logging 3 to be consistent with the logging approach once the switch from slf4j is made to JBoss Logging 3. -- 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

12 years, 4 months

7
37
0 / 0

[JBoss JIRA] Created: (SEAMINTL-40) Forge plugin for adding Seam International dependency, and setup tasks

by Ken Finnigan (JIRA)

Forge plugin for adding Seam International dependency, and setup tasks ---------------------------------------------------------------------- Key: SEAMINTL-40 URL: https://issues.jboss.org/browse/SEAMINTL-40 Project: Seam International Issue Type: Feature Request Components: Locales, Time zones Reporter: Ken Finnigan Assignee: Ken Finnigan Create forge facet/plugin for: - adding dependency for international - adding optional dependencies - override default config of timezones/locales -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2764) Factory method does not create objects properly

by Bogdan Minciu (JIRA)

Factory method does not create objects properly ----------------------------------------------- Key: JBSEAM-2764 URL: http://jira.jboss.com/jira/browse/JBSEAM-2764 Project: JBoss Seam Issue Type: Bug Components: EJB3 Affects Versions: 2.0.1.GA Reporter: Bogdan Minciu Hello, It seems that my @Factory method is recognizing the created objects only in its command block. I have this class: @Stateful @Name("xtw") @Scope(ScopeType.SESSION) @AutoCreate public class XTextSessionWrapper implements LocalXTextSessionWrapper { ... @In(required=false, create=true) @Out private XLanguage activeLanguage; public String getText(String identifier) { log.info("getText(1): identifier= #0, activeLanguage= #1", identifier, getActiveLanguage()); XTextEntry xte = xTextEntryDAO.findXTextEntry(identifier, getActiveLanguage()); log.info("getText(2): identifier= #0, activeLanguage= #1", identifier, getActiveLanguage()); xte.getXtext(); } @Factory(value="activeLanguage", autoCreate=true) public void initActiveLanguage() { XLanguage xl = xLanguageDAO.findXLanguageByIdentifier("ro"); log.info("initActiveLanguage(1): activeLanguage initialized to #0", xl.getIdentifier()); setActiveLanguage(xl); log.info("initActiveLanguage(1): activeLanguage initialized to #0", getActiveLanguage().getIdentifier()); } public XLanguage getActiveLanguage() { return activeLanguage; } public void setActiveLanguage(XLanguage activeLanguage) { this.activeLanguage = activeLanguage; } ... } And i am calling the getText() method. The method calling is as expected: 1. the injected activeLanguage is detecting that it has a null value, 2. the initActiveLanguage() factory method is called 3. then the getText() method is continuing its execution. But, the problem is that when the application exists the @Factory method block, the created objects: activeLanguage is lost and reported again as null. Here is the output: 12:43:48,203 INFO [XTextSessionWrapper] initActiveLanguage(1): activeLanguage initialized to ro 12:43:48,203 INFO [XTextSessionWrapper] initActiveLanguage(1): activeLanguage initialized to ro 12:43:48,703 INFO [XTextSessionWrapper] initActiveLanguage(1): activeLanguage initialized to ro 12:43:48,703 INFO [XTextSessionWrapper] initActiveLanguage(1): activeLanguage initialized to ro 12:43:48,703 INFO [XTextSessionWrapper] getText(1): identifier= com.brit.xcms.cms.Category.12.name, activeLanguage= null 12:43:49,234 INFO [XTextSessionWrapper] getText(2): identifier= com.brit.xcms.cms.Category.12.name, activeLanguage= null Where did I went wrong? Why is the activeLanguage factoried value lost when i leave the initActiveLanguage() method? -- 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

12 years, 4 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues April 2011