[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