Just t be clear.
The handling of TRY_AGAIN versus the handling of NO_RESOURCES do differ.
A TRY_AGAIN loop must have a delay for each iteration and iterations must be
fast.
A NO_RESOURCES client loop does not need a delay and each iteration may be
indefinitely long.
Nearly all applications should handle TRY_AGAIN because it is normally a
temporary problem
over in a few seconds. The immsv can generate TRY_AGAIN for up to 60 seconds
for big syncs
but I would argue that this should be changes so that the immsv shifts from
TRY_AGAIN to NO_RESOURCES
if the sync takes longer than say 20 seconds.
Most crucially, from the implementation (server) side, each TRY_AGAIN
iterations should be fast (miliseconds)
Because this allows the client application to have realtime control over how
long they tolerate being stuck.
Application threads with real-time requirements should not bother retrying
NO_RESOURCES.
Each iteration can take a longer time and the error code itself signals that
the wait-time is outside the control
of the service and could be indefinite.
/AndersBj
From: Anders Bjornerstedt [mailto:ander...@users.sf.net]
Sent: den 26 augusti 2015 08:25
To: [opensaf:tickets]
Subject: [opensaf:tickets] Re: #1448 smf: Make campaigns less fragile by
retrying on ERR_NO_RESOURCES
Yes the principle about handling ERR_NO_RESOURCES should be the same everywhere
over all SAF services.
Just as the rules for handling TRY_AGAIN should be the same over all OpenSAF
services.
Any client-application is free to decide to not handle these errors, i.e. to
stop trying if they get them.
But applications can be made more robust by handling these errors.
There is also ERR_BUSY which for the immsv works exactly the same way as
ERR_NO_RESOURCES.
SAF created too many error codes as I see it.
There should only be one error code for any particular handling behavior
defined as appropriate for the error.
If two error codes are to be handled exactly the same then one of the error
codes should be deprecated.
/AndersBJ
From: Mathi Naickan [mailto:mathi-naic...@users.sf.net]
Sent: den 25 augusti 2015 17:03
To: [opensaf:tickets]
Subject: [opensaf:tickets] #1448 smf: Make campaigns less fragile by retrying
on ERR_NO_RESOURCES
Just as a note - previously, I had a discussion with Ingvar and he had agreed
to convert this into a defect.
I can provide a patch for this for OM api calls except for the CCB APIs (based
on the description above).
Should we also give this treatment for OI APIs?
________________________________
[tickets:#1448]<http://sourceforge.net/p/opensaf/tickets/1448/>http://sourceforge.net/p/opensaf/tickets/1448/
smf: Make campaigns less fragile by retrying on ERR_NO_RESOURCES
Status: unassigned
Milestone: future
Created: Fri Aug 14, 2015 07:09 AM UTC by Anders Bjornerstedt
Last Updated: Tue Aug 25, 2015 02:37 PM UTC
Owner: nobody
The SMF service is a heavy user of the IMM service.
The IMM has an established client pattern for ERR_TRY_AGAIN which allows an
application realtime
control over how long it is prepared to wait for a transient inability of the
IMM service to fullfill a request.
Each response of TRY_AGAIN should in itself be fast so the application needs a
delay in its retry loop.
There is also the very similar error code ERR_NO_RESOURSES. Logically that
error code is identical
to TRY_AGAIN in that the request could not be accepted due to no fault of the
client but due to some
more or less temporary problem in the IMM service. The difference is that
NO_RESOURCES has no
realtime ambitions. Typically this error code is used by the imm when the imm
can not fullfill a request
due to reasons that are outside of the imm service control. Also the time from
request to a response
of ERR_NO_RESOUIRCES may be long.
The SMF service in general has no realtime requirments. The main goal for the
SMF service is to
successfully complete correctly formulated camopaings. This means that the SMF
service should be
programmed to avoid unnecessary fragility related to temporary problems, even
if the temporary problem
could linger for seconds or minutes.
The alternative of aborting the campaign will itself discard potentially large
execution times already
completed. It may sometimes even result in a system restore.
This means that SMF campaigns should have a "retry loop" that handles not just
TRY_AGAIN,
but also ERR_NO_RESOURCES where this return code is relevant (can be returned
according to
the API spec).. The error copde ERR_BUSY also exists and is for all practical
purposes identical
to ERR_NO_RESOURCES in semantics, both logical and timing.
________________________________
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/opensaf/tickets/1448/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
________________________________
[tickets:#1448]<http://sourceforge.net/p/opensaf/tickets/1448/> smf: Make
campaigns less fragile by retrying on ERR_NO_RESOURCES
Status: unassigned
Milestone: future
Created: Fri Aug 14, 2015 07:09 AM UTC by Anders Bjornerstedt
Last Updated: Tue Aug 25, 2015 03:03 PM UTC
Owner: nobody
The SMF service is a heavy user of the IMM service.
The IMM has an established client pattern for ERR_TRY_AGAIN which allows an
application realtime
control over how long it is prepared to wait for a transient inability of the
IMM service to fullfill a request.
Each response of TRY_AGAIN should in itself be fast so the application needs a
delay in its retry loop.
There is also the very similar error code ERR_NO_RESOURSES. Logically that
error code is identical
to TRY_AGAIN in that the request could not be accepted due to no fault of the
client but due to some
more or less temporary problem in the IMM service. The difference is that
NO_RESOURCES has no
realtime ambitions. Typically this error code is used by the imm when the imm
can not fullfill a request
due to reasons that are outside of the imm service control. Also the time from
request to a response
of ERR_NO_RESOUIRCES may be long.
The SMF service in general has no realtime requirments. The main goal for the
SMF service is to
successfully complete correctly formulated camopaings. This means that the SMF
service should be
programmed to avoid unnecessary fragility related to temporary problems, even
if the temporary problem
could linger for seconds or minutes.
The alternative of aborting the campaign will itself discard potentially large
execution times already
completed. It may sometimes even result in a system restore.
This means that SMF campaigns should have a "retry loop" that handles not just
TRY_AGAIN,
but also ERR_NO_RESOURCES where this return code is relevant (can be returned
according to
the API spec).. The error copde ERR_BUSY also exists and is for all practical
purposes identical
to ERR_NO_RESOURCES in semantics, both logical and timing.
________________________________
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/opensaf/tickets/1448/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
---
** [tickets:#1448] smf: Make campaigns less fragile by retrying on
ERR_NO_RESOURCES**
**Status:** unassigned
**Milestone:** future
**Created:** Fri Aug 14, 2015 07:09 AM UTC by Anders Bjornerstedt
**Last Updated:** Tue Aug 25, 2015 03:03 PM UTC
**Owner:** nobody
The SMF service is a heavy user of the IMM service.
The IMM has an established client pattern for ERR_TRY_AGAIN which allows an
application realtime
control over how long it is prepared to wait for a transient inability of the
IMM service to fullfill a request.
Each response of TRY_AGAIN should in itself be fast so the application needs a
delay in its retry loop.
There is also the very similar error code ERR_NO_RESOURSES. Logically that
error code is identical
to TRY_AGAIN in that the request could not be accepted due to no fault of the
client but due to some
more or less temporary problem in the IMM service. The difference is that
NO_RESOURCES has no
realtime ambitions. Typically this error code is used by the imm when the imm
can not fullfill a request
due to reasons that are outside of the imm service control. Also the time from
request to a response
of ERR_NO_RESOUIRCES may be long.
The SMF service in general has no realtime requirments. The main goal for the
SMF service is to
successfully complete correctly formulated camopaings. This means that the SMF
service should be
programmed to avoid unnecessary fragility related to temporary problems, even
if the temporary problem
could linger for seconds or minutes.
The alternative of aborting the campaign will itself discard potentially large
execution times already
completed. It may sometimes even result in a system restore.
This means that SMF campaigns should have a "retry loop" that handles not just
TRY_AGAIN,
but also ERR_NO_RESOURCES where this return code is relevant (can be returned
according to
the API spec).. The error copde ERR_BUSY also exists and is for all practical
purposes identical
to ERR_NO_RESOURCES in semantics, both logical and timing.
---
Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is
subscribed to http://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
http://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
