Is there a way to be precise about the
TServerRequestQueue.CancelRequest? I just realised the reason for my
code not working at all was that the queue was getting stuck on a 404
response. The help says 200-299 are assumed okay, but 404 and others
will retry unless I call CancelRequest. Strikes me that I want to say
"cancel this specific one, not another one I might have added by
accident". The function seems to be "delete the first request in the
queue. My fear of accidents makes me want to not do this, and instead,
in the OnComplete, pass in, or use a function of the passed in Request,
to cancel that one for sure.

I think in my case I actually just want a request and not the queue, so
not urgent, just something to ponder for the future perhaps.

--

Matthew Jones

Matthew Jones wrote:

> I think in my case I actually just want a request and not the queue,
> so not urgent, just something to ponder for the future perhaps.

Hmm, so I sit down to ponder how I'm using it, and what I actually
need. My ideal is a queue that manages the lifetimes of the requests,
but doesn't get "stuck" when an error occurs. Make the request, get an
answer, move on. Which then made me think that the real solution is to
add a property to the queue to either behave as it does now, with the
"persist with items" mode, or "what the heck" mode and a 404 or 500 or
something is treated the same as a 200. Seems it would be an easy
change without looking into it - "if 200 or ignoreErrors then".

--

Matthew Jones

On 7/11/2016 9:03 AM, Matthew Jones wrote:
> Is there a way to be precise about the
> TServerRequestQueue.CancelRequest? I just realised the reason for my
> code not working at all was that the queue was getting stuck on a 404
> response. The help says 200-299 are assumed okay, but 404 and others
> will retry unless I call CancelRequest. Strikes me that I want to say
> "cancel this specific one, not another one I might have added by
> accident". The function seems to be "delete the first request in the
> queue. My fear of accidents makes me want to not do this, and instead,
> in the OnComplete, pass in, or use a function of the passed in Request,
> to cancel that one for sure.

TServerRequestQeue executes the server requests in order (one at a time)
so if you get stuck (i.e. error 404) then calling CancelRequest should
cancel that problem one and then calling ExecuteRequests should execute
next pending.

Is that not working for you ?

Raul

> TServerRequestQeue executes the server requests in order (one at a time)
> so if you get stuck (i.e. error 404) then calling CancelRequest should
> cancel that problem one and then calling ExecuteRequests should execute
> next pending.
>
> Is that not working for you ?

It probably would but I fear I'd make a mistake and either not call the
cancel or I'd cancel one I shouldn't. Hence thinking that an option to
auto-cancel would be good. Set and forget.

Basically I spent over an hour wondering why the core never did the right
call and just repeated an old one. I don't want my code to get stuck like
that.

--
Matthew Jones

On 7/11/2016 2:51 PM, Matthew Jones wrote:
> It probably would but I fear I'd make a mistake and either not call the
> cancel or I'd cancel one I shouldn't. Hence thinking that an option to
> auto-cancel would be good. Set and forget.

One option would be to not use TServerRequestQueue at all -
TServerRequest can be executed by itself and if you have bunch of them
they run async so nothing blocks or stops other reqeusts.

TServerRequestQueue is for scenarios where order is important and you
want to enforce it but it does involve bit of housekeeping around it.

The auto-cancel could cause as many issues as it solves - even if you
never want to retry the request there might be a case where you do and
then you have to have regular queue vs auto-cancel queue etc.


> Basically I spent over an hour wondering why the core never did the right
> call and just repeated an old one. I don't want my code to get stuck like
> that.

It is well documented in the manual IMHO that queue stops and you must
cancel or execute (blue section at the bottom) :
http://www.elevatesoft.com/manual?action=viewtopic&id=ewb2&topic=Executing_Request

Raul

Raul wrote:

> On 7/11/2016 2:51 PM, Matthew Jones wrote:
> > It probably would but I fear I'd make a mistake and either not call
> > the cancel or I'd cancel one I shouldn't. Hence thinking that an
> > option to auto-cancel would be good. Set and forget.
>
> One option would be to not use TServerRequestQueue at all -
> TServerRequest can be executed by itself and if you have bunch of
> them they run async so nothing blocks or stops other reqeusts.
>
> TServerRequestQueue is for scenarios where order is important and you
> want to enforce it but it does involve bit of housekeeping around it.
>
> The auto-cancel could cause as many issues as it solves - even if you
> never want to retry the request there might be a case where you do
> and then you have to have regular queue vs auto-cancel queue etc.

I have switched to the TServerRequest for this task, but I liked the
automatic memory management - my system will likely have multiple
things happening, so now I have to create a new one, set it up, and
remember to free it at the end (hoping that I can do that in the
OnComplete event handler). The Request Queue already does all that.


> > Basically I spent over an hour wondering why the core never did the
> > right call and just repeated an old one. I don't want my code to
> > get stuck like that.
>
> It is well documented in the manual IMHO that queue stops and you
> must cancel or execute (blue section at the bottom) :
>
http://www.elevatesoft.com/manual?action=viewtopic&id=ewb2&topic=Executing_Request

It is well documented, but it is hard to be deterministic with it. If I
get the code wrong in one handler, and don't kill it, the queue is
dead. Literally. I cannot look at the topmost request and see what its
ResultCode is and decide it should be killed. Now, the answer is of
course not to make the mistake in my code, but I don't need the ordered
part, I just want the management part. Hence me thinking it sounded
"simple" to auto-clear any request regardless of resultcode.

--

Matthew Jones

Matthew,

I'm also not quite sure what the concern is here.  If you attach an OnComplete event handler to the server request, you'll be informed of the status of the request when it's done.  You can then choose to call the Cancel method for the server request if the result isn't to your liking.  That will kill the current request and start executing any subsequent requests.

<< hoping that I can do that in the OnComplete event handler >>

No, you can't, and shouldn't, do that, especially if the TServerRequest was allocated by the queue.

Tim Young
Elevate Software
www.elevatesoft.com