Brad, I lost track of this one, sorry about that. Where have you got to with
this?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115515#4115515
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115515
___
Pete,
It's a been a few weeks (~6 ;-)) but I ultimately reverted to session scope for
most of our state in the simple application in which the issue arose. Thus, I
don't have a solution for the problem I ran into here.
I will be in my office mid-next week and can look at that specific applicat
Do you have you thirdPartyHelper in the Conversation scope (or Session). eg:
| @Name("thirdPartyHelper")
| @Scope(ScopeType.CONVERSATION)
If so then it could be that your suggestion action is taking too long and the
conversation is reset due to the concurrent-request-timeout. If you think tha
Damian,
thirdPartyHelper is a SLSB - the intent here is to simply provide the suggested
options - it takes about 2-3 seconds to respond.
my core:manager settings are as follows:
|
|
I believe my conversation timeout parameter is longer than your suggestion (15
minutes above). I wond
Brad, see
http://docs.jboss.org/seam/2.0.0.GA/reference/en/html/conversations.html#d0e5062
for an in depth discussion of concurrent access to conversational components.
To see if this is the problem, try increasing concurrent-request-timeout to
about 3000 (6s).
View the original post :
http:/
Pete,
I went to 10 seconds concurrent-request-timeout="1" - no luck. I looked
over the documentation on that in the manual (just above section 6.9.1 which I
used to come up with the settings used in the suggestionbox attributes). The
basic flow I am trying to 'do' is:
a.) on an editor p
