[Dev] [Cynara] Async admin API proposal

Zofia Abramowska z.abramowska at samsung.com
Fri Aug 22 15:46:00 GMT 2014


Hi,

I believe cache was implemented as our optimization, not part of API,
whence I don't see a place for it to be visible to user of cynara async API.
If I am wrong, Lukasz will probably correct me (probably on Monday).

Now, if we assume, that client does not know about cache, why would
there be two points in API, which return the response?

@Jose
> > 2. cynara_async_check() will have to perform additional check for
> cynara disconnection (this is implementation problem, but as cache is
> only valid when connection to cynara is alive, this must be checked).
> Moreover both cynara_async_check() and cynara_async_process() will have
> to perform this check.
> 
> this state problem is true but should not be a stopper. the correct way
> to handle the case is to detect it in polling and to pass it to
> cynara_async_process that will manage the state. See the hangup in
> cynara_async_status.
> 
> typedef enum {
>     CYNARA_STATUS_FOR_READ,
>     CYNARA_STATUS_FOR_WRITE,
>     CYNARA_STATUS_FOR_RW,
>     CYNARA_STATUS_FOR_HANGUP
> } cynara_async_status;

How do you expect 100th check with cache hit to be still up-to-date if
information, that server has disconnected will be processed after in cynara_async_process?
If after 1st cache hit server has disconnected, all 99 responses are invalid.
Before every check in cache we must be sure, that this value is still valid.
We can write in documentation : don't do cynara_async_check if CYNARA_STATUS_FOR_HANGUP
is on cynara socket, but I believe it's not the point?

> The main topic of your mail is about calling response callback within
> cynara_async_check. The main drawbacks I'm seing if staying pending
> until further call to cynara_async_process is that the state of the
> file descriptor in the main loop will not change. Then returning to the
> main loop will not produce poll-able event and cynara_async_process
> will not be called.

I'm not sure what you mean here. cynara_async_check will always assure, that we
are waiting for writeable on socket (as it would be with API #1, when there is
no cache hit - we still need to send request to cynara).
I want to make one thing clear - every operation on socket is made inside
cynara_async_process, as both write and read can return EAGAIN and we don't want
to handle that anywhere (meaning - we want to return control to user without 
indicating any error like CYNARA_API_TRY_AGAIN). When write returns EAGAIN
we return control to user and we are still waiting for writable on socket. 
When we write everything we wanted, we call cynara_status_callback to wait only
for readable (waiting for responses or disconnection).
Still, this is all case of implementation, I just wanted to explain that state of fd
that we are waiting for is properly managed.

> 
> We naturally fall to the conclusion that you would enforce to call
> cynara_async_process after successfully calling cynara_async_check what
> is not elegant to my eyes.
> 

Yes, because why would you want the answer of asynchronous API outside
of event loop?

Best regards,
Zofia Abramowska. 




More information about the Dev mailing list