Hi All,

Anybody had an issue with EWB2 whereby a "failed" HTTP request (i.e. status code 400) seems to leave the request on the queue so that all subsequent requests trigger 2x responses, one of which is the 400 back again !?!?!?!

Driving me nuts.

Mark

On 6/2/2015 9:03 AM, Mark Brooks wrote:
> Anybody had an issue with EWB2 whereby a "failed" HTTP request (i.e. status code 400) seems to leave the request on the queue so that all subsequent requests trigger 2x responses, one of which is the 400 back again !?!?!?!
> Driving me nuts.


I assume you might be running into the new EWB2 request queueing so this
is by design i believe.

Queued requests are serialized and you can call cancel on them if you do
not wish to continue executing it once you get the 400 error back (or
even CancelAllRequests from server queue if you want to remove all).

Raul

Raul wrote:

>>Queued requests are serialized and you can call cancel on them if you do
>>not wish to continue executing it once you get the 400 error back (or
>>even CancelAllRequests from server queue if you want to remove all).

Hi Raul
Thanks for this. It sounds very much like what I'm experiencing. I am getting a 400 that seems to "hang around". Are you saying that I should call Cancel in order to remove it? Is the same true for 500 range status codes?
Cheers
Mark

On 6/2/2015 9:49 AM, Mark Brooks wrote:
> Thanks for this. It sounds very much like what I'm experiencing. I am getting a 400 that seems to "hang around". Are you saying that I should call Cancel in order to remove it? Is the same true for 500 range status codes?

The specific HTTP response code does not really matter - anything not
200 OK is considered an error and server queue processing stops and you
need to decide what to do.

You can do one of the following:
- call ExecuteRequests to try again
- call CancelRequest to cancel this request only but leave others
- call CancelAllRequests to cancel all pending requests

You can also query the NumPendingRequests property to see how many there
are.


Don't know what the 400 represents but it's usually considered invalid
data/request by client so for my apps 400 usually means cancel the request.

500 itself might be something you want to retry - again depends on your
server and what the errors actually represent.

Raul

Raul wrote:

>>You can do one of the following:
>>- call ExecuteRequests to try again
>>- call CancelRequest to cancel this request only but leave others
>>- call CancelAllRequests to cancel all pending requests

Ok Raul.

My app talks to a custom API and certain responses require certain actions on behalf of the client. However, I think the principle remains the same.

In the EWB1 world my client app would execute some HTTP request(s) and process the response(s) in the OnComplete event handler. A response in the 4XX range exhibited the identical EWB1 behaviour to one in the 2XX range.

What I'm seeing now, in EWB2, is that a response in the 4XX range exhibits different behaviour and I think you've explained why. It seems to stay in the queue and affects all subsequent requests. Previously it would disappear in exactly the same way as a 2XX response.

I want replicate the EWB1 behaviour so I'm trying your suggestion of calling CancelRequest or CancelAllRequests to just forget it and carry. However, this does not seem to have any effect. Can you confirm how and where to call these functions please?

Many thanks again
Mark

On 6/2/2015 10:22 AM, Mark Brooks wrote:
> In the EWB1 world my client app would execute some HTTP request(s) and process the response(s) in the OnComplete event handler. A response in the 4XX range exhibited the identical EWB1 behaviour to one in the 2XX range.

EWB1 just kept going - failed request did not stop queue processing.

> What I'm seeing now, in EWB2, is that a response in the 4XX range exhibits different behaviour and I think you've explained why. It seems to stay in the queue and affects all subsequent requests. Previously it would disappear in exactly the same way as a 2XX response.

Previous mode meant one had to do all the request state tracking in the
app while this one moves the serialization to the framework (for example
now you can queue a request to modify data and then right away one to
query for data before 1sst completes and this ensures that query data
does not get triggered until 1st completes - or if it failes you can
retry or cancel all to cancel the query data request also).

> I want replicate the EWB1 behaviour so I'm trying your suggestion of calling CancelRequest or CancelAllRequests to just forget it and carry. However, this does not seem to have any effect. Can you confirm how and where to call these functions please?

You should be able to just call it from the request OnComplete handler.

I don't have EWB2 on the laptop i'm with today but i can try it tonight
at home.


Raul

Raul wrote:

>>You should be able to just call it from the request OnComplete handler.
>>
>>I don't have EWB2 on the laptop i'm with today but i can try it tonight
>>at home.

That would be a great help - thanks Raul - it's just not working for me at this end

On 6/2/2015 11:29 AM, Mark Brooks wrote:
> That would be a great help - thanks Raul - it's just not working for me at this end

I had a small break and decided to try it out so installed ewb2 preview
- yes i can see a failing request getting stuck (in my case it's 404 as
it's the only one i produce easily).

So looks like a bug on surface.

Looking at webhttp it appears CancelRequest and CancelAllRequests only
run if FExecuting=true (which i don't think is not the case at this
point when callback is called so they might not properly cancel).

I think we need Tim to comment here for this

Raul

On 6/2/2015 12:27 PM, Raul wrote:
> Looking at webhttp it appears CancelRequest and CancelAllRequests only
> run if FExecuting=true (which i don't think is not the case at this
> point when callback is called so they might not properly cancel).

That should have said "(which i don't think is the case at this ..."

There appears to be a queue ordering issue here as well - which might be
just issue with the cancel part still.

I had submitted 2 events into the queue:
- 1st would result in StatusCode = 404
- 2nd was OK and would result in 200

When it runs i get the 404 error first and then just call
ExecuteRequests then the execution order i see is :
- 1st request (404)
- 2nd request (200)
- 1st request (404)
- 1st request (404)
.....

So looks like it if i just wanted to retry the request gets queued at
the end in case of failure.

Anyway, let's see what Tim says - might be something i'm doing also
causing this.

Raul

Raul wrote:

>>There appears to be a queue ordering issue here as well - which might be
>>just issue with the cancel part still.

Yup. Pretty much my experience, although you have looked in greater detail.

Let's see if Tim can shed any light.

Thanks again for taking the time to help me with this one Raul.