[seam-dev] Re: [Richfaces-exadel] Concurrent requests (event queue and error condition)

Pete Muir pmuir at redhat.com
Wed Sep 3 08:19:32 EDT 2008

Thanks Shane, Sergey, I've mentioned what each framework will do when  
an error is received in the docs.

I also filed https://jira.jboss.org/jira/browse/JBSEAM-3373 so that we  
can add HTTP headers when an error is sent, allowing us to send the  
RFC recommended Retry-After header which should allow the  
implementation of Ted's suggestion of retrying after a period of time.

On 3 Sep 2008, at 04:57, Shane Bryzak wrote:

> Remoting still doesn't support exception handling very well (https://jira.jboss.org/jira/browse/JBSEAM-633 
> ) , however the basic intention is to handle any HTTP error codes  
> more gracefully than they currently are (I think that presently you  
> just get an alert box).  I don't think we can reasonably redirect  
> the user to an error page (as it's an inline request after all) but  
> we should be able to provide a more flexible API to allow developers  
> to define their own behaviour when an exception occurs.
> Pete Muir wrote:
>> On 2 Sep 2008, at 19:49, Pete Muir wrote:
>>> On 2 Sep 2008, at 19:19, Ted Goddard wrote:
>>>> Hi Pete,
>>>> The ICEfaces bridge can handle errors to various Ajax responses;  
>>>> for instance,
>>>> in some cases the icon in the connection status component will be  
>>>> changed to
>>>> reflect an error response.
>>> Ok, this is good - means that it should work as it is today with  
>>> IceFaces.
>>> Seam requires a bit of a rejig to make it do this, so I'll work on  
>>> that next.
>> So, Seam now throws an exception when it can't serialize a  
>> concurrent request, and you can use Seam's standard exception  
>> handler to translate that into the appropriate response (e.g.  
>> redirect to an error page, send an http error code).
>> I've tested A4Js error handling, and it all works well (e.g. you  
>> can pop up a message to the user).
>> Shane, can Seam remoting deal with an HTTP error being sent to it?
>> The changes the user will need to make:
>> 1) Define the exception handling in pages.xml to either send an  
>> HTTP error or go to an error page. Sending a 503 error with logging  
>> turned off will be the recommended approach.
>> 2a) A4J: alter their templates to override the A4J error handling
>> 2b) ICEfaces: ??? (do nothing by the sound of it)
>> 2c) Seam Remoting: ???
>> Currently the system boots them out of the conversation, we replace  
>> that with throwing an exception, both are equally bad so this  
>> shouldn't be too much of regression for existing apps.
>>>> So responding with an error to the Ajax request sounds good ...  
>>>> the question is
>>>> how it should be displayed to the user.  Or should this error  
>>>> cause a retry
>>>> over Ajax after some period of time (and not be displayed to the  
>>>> user
>>>> immediately)?
>>> I think both these are reasonable options, and should be up to the  
>>> developer to choose one. I would say the default behaviour should  
>>> be to display a message to the user.
>> It would be great if we could get an example of how to do these for  
>> ICEfaces, A4J and Seam remoting into the ref doc. Sergey/Ted/Shane  
>> can you provide me with an example of how to customize the  
>> behaviour of the framework in both these ways when an HTTP 503  
>> error is sent as the AJAX response?
>> Thanks!
>>>> Regards,
>>>> Ted.
>>>> On 2-Sep-08, at 12:06 PM, Pete Muir wrote:
>>>>> Ted, Judy, Shane,
>>>>> I've recently been working on https://jira.jboss.org/jira/browse/JBSEAM-1832 
>>>>>  and am trying to define better what Seam should do when it  
>>>>> cannot successfully serialize requests to the conversation scope  
>>>>> (because the queue times out). My preferred solution is to drop  
>>>>> the request, and send an error to the browser for it to deal  
>>>>> with. I'm looking for your input on the best way to send such an  
>>>>> error that will work with different remoting/ajax frameworks.
>>>>> A couple of points
>>>>> 1) Should work ootb - the user should just get some error  
>>>>> message in the browser by default, which they can customize
>>>>> 2) Should work the same for all different JS frameworks
>>>>> Having looked at A4J, I notice that it can handle being sent an  
>>>>> HTTP error. Semantically, it seems correct to approach it this  
>>>>> way (specifically sending a 503) but if we do that, we need a  
>>>>> way for (at least) Seam Remoting, A4J and IceFaces to intercept  
>>>>> that request and translate it to a message to the user (and not  
>>>>> bring up an ugly error message).  We can send a detailed error  
>>>>> message as the body of the message (e.g. concurrent request) and  
>>>>> perhaps add a http header that shows where this error comes from.
>>>>> WDYT?
>>>>> On 2 Sep 2008, at 18:55, Pete Muir wrote:
>>>>>> Seam serializes, also using a timed queue. We need to do  
>>>>>> *something* when the event reaches the timeout. Currently, Seam  
>>>>>> will make the active conversation inactive, which isn't the  
>>>>>> best behaviour, and I think the correct approach is to stay in  
>>>>>> the conversation, but to send an error. I took a look at the  
>>>>>> A4J error handling, and it looks like the best approach is to  
>>>>>> send an Http error to the browser, which can then be  
>>>>>> intercepted and handled? Can we provide a default behaviour for  
>>>>>> this?
>>>>>> Thanks,
>>>>>> Pete
>>>>>> _______________________________________________
>>>>>> Richfaces-exadel mailing list
>>>>>> Richfaces-exadel at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/richfaces-exadel
>>>> _______________________________________________
>>>> Richfaces-exadel mailing list
>>>> Richfaces-exadel at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/richfaces-exadel
> _______________________________________________
> Richfaces-exadel mailing list
> Richfaces-exadel at redhat.com
> https://www.redhat.com/mailman/listinfo/richfaces-exadel

More information about the seam-dev mailing list