Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder 2 Preview » View Thread |
Messages 1 to 10 of 13 total |
EWB2 TServerRequestQueue Issue? |
Tue, Jun 2 2015 9:03 AM | Permanent Link |
Mark Brooks Slikware | 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 |
Tue, Jun 2 2015 9:22 AM | Permanent Link |
Raul Team Elevate | 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 |
Tue, Jun 2 2015 9:49 AM | Permanent Link |
Mark Brooks Slikware | 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 |
Tue, Jun 2 2015 10:03 AM | Permanent Link |
Raul Team Elevate | 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 |
Tue, Jun 2 2015 10:22 AM | Permanent Link |
Mark Brooks Slikware | 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 |
Tue, Jun 2 2015 11:16 AM | Permanent Link |
Raul Team Elevate | 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 |
Tue, Jun 2 2015 11:29 AM | Permanent Link |
Mark Brooks Slikware | 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 |
Tue, Jun 2 2015 12:27 PM | Permanent Link |
Raul Team Elevate | 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 |
Tue, Jun 2 2015 12:39 PM | Permanent Link |
Raul Team Elevate | 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 |
Tue, Jun 2 2015 1:16 PM | Permanent Link |
Mark Brooks Slikware | 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. |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |