[Bugs] [Bug 1585585] New: Cleanup "connected" state management of rpc-clnt

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1585585

            Bug ID: 1585585
           Summary: Cleanup "connected" state management of rpc-clnt
           Product: GlusterFS
           Version: mainline
         Component: rpc
          Assignee: bugs at gluster.org
          Reporter: rgowdapp at redhat.com
                CC: bugs at gluster.org



Description of problem:
The state management of "connected" in rpc is ad-hoc. rpc layer manages this
state in disconnect codepath and has exposed an api to manage this one from
consumers. Note that rpc layer never sets "connected" to true by itself, which
forces the consumers to use this api to get a working rpc connection. The
situation is best captured from a comment in code from Jeff Darcy in
glusterfsd/src/gf-attach.c:

-/*
- * In a sane world, the generic RPC layer would be capable of tracking
- * connection status by itself, with no help from us.  It might invoke our
- * callback if we had registered one, but only to provide information.  Sadly,
- * we don't live in that world.  Instead, the callback *must* exist and *must*
- * call rpc_clnt_{set,unset}_connected, because that's the only way those
- * fields get set (with RPC both above and below us on the stack).  If we
don't
- * do that, then rpc_clnt_submit doesn't think we're connected even when we
- * are.  It calls the socket code to reconnect, but the socket code tracks
this
- * stuff in a sane way so it knows we're connected and returns EINPROGRESS.
- * Then we're stuck, connected but unable to use the connection.  To make it
- * work, we define and register this trivial callback.
- */


Also, Consumers of rpc know about state of connection only through the
notifications sent by rpc-clnt. So, consumers don't have any extra information
to manage the state and hence letting them manage the state is counter
intuitive.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.