pcp updates: qa and libpcp tweaks

Changes committed to git://git.pcp.io/kenj/pcp master

Ken McDonell (5):
      qa/759: unbound PMDA no longer forces pmcd restart
      qa/041: another case of needing to wait for pmcd _and_ pmlogger
      qa/365: add some more checking at the end for pmcd and primary pmlogger
      src/libpcp/src/auxserver.c: be a little more tolerant of EADDRINUSE
      src/libpcp/src/context.c: tweak to __pmCloseChannelbyFd() and  __pmCloseChannelbyContext()

 qa/041                     |    1 +
 qa/365                     |   28 +++++++++++++++++++++++-----
 qa/759.out                 |    3 ---
 src/libpcp/src/auxserver.c |   22 +++++++++++++++++++---
 src/libpcp/src/context.c   |   25 ++++++++++++++++++++++++-
 5 files changed, 67 insertions(+), 12 deletions(-)

Details ...

commit 33a9819165576b12dffc2560891f4313eae153b5
Author: Ken McDonell <[email protected]>
Date:   Fri Nov 4 07:03:26 2016 +1100

    src/libpcp/src/context.c: tweak to __pmCloseChannelbyFd() and
    __pmCloseChannelbyContext()

    These routines get called from multiple places because __pmGetPDU()
    is used in lots of places, but it really only makes sense to clobber
    to the underlying socket in cases where the caller is a PMAPI client.

    So the "close socket" part is NOT done if __pmGetInternalState()
    returns PM_STATE_PMCS, which means any socket between pmcd (or dbpmda)
    and a PMDA is not closed if a socket read timeout leads us to the
    __pmCloseChannelby*() routines.  In these cases, the higher level
    error handling is sufficient.

    Of course, if Frank's un-multiplexing of the client-pmcd socket on
    the client side is fully implemented, all of this code is likely to
    be culled because the motivation will have been removed.

commit 2261fc7af299a63b93d3df20aeabe5f42bf93fad
Author: Ken McDonell <[email protected]>
Date:   Fri Nov 4 06:53:11 2016 +1100

    src/libpcp/src/auxserver.c: be a little more tolerant of EADDRINUSE

    With recent changes to the daemon restarting logic to speed things up
    we seem to have opened a window where we try to bind to a specific
    port (e.g. pmcd's client connection port) before the last use has
    been fully torn down, resulting in EADDRINUSE errors on restart.

    The problem seems particularly bad on my QA vm19 running x86_64
    openSUSE 12.2 ... but that may have more to do with this VM than
    this distro.

    The change here is to add a small delay (of between 1 and 4 x 250msec)
    when bind() returns EADDRINUSE ... this seems to be enough to let the
    previous socket usage be completely cleaned up and the new daemon is
    off to the races.  Most calls see no delay.  Non-transient problems
    now take 4 failed attempts and 1 second longer to report EADDRINUSE.

commit 4d115e9f460117e052bda70aa1df44a7afe8b2b4
Author: Ken McDonell <[email protected]>
Date:   Fri Nov 4 06:52:30 2016 +1100

    qa/365: add some more checking at the end for pmcd and primary pmlogger

commit a44fd60f0a4d15551ca53022172443cea32ac1d0
Author: Ken McDonell <[email protected]>
Date:   Fri Nov 4 06:51:48 2016 +1100

    qa/041: another case of needing to wait for pmcd _and_ pmlogger

commit ac28f151eb69ce0ed1f45f091b66f6c315683c16
Author: Ken McDonell <[email protected]>
Date:   Thu Nov 3 10:30:55 2016 +1100

    qa/759: unbound PMDA no longer forces pmcd restart

    Revised 759.out.

-=-=-=-=-=-=-=-=-=-=-=-
pcp mailing list
[email protected]
https://groups.io/g/pcp/messages
-=-=-
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#14646): https://groups.io/g/pcp/message/14646
View All Messages In Topic (1): https://groups.io/g/pcp/topic/3040793
Mute This Topic: https://groups.io/mt/3040793?uid=174580
New Topic: https://groups.io/g/pcp/post

Change Your Subscription: https://groups.io/g/pcp/editsub?uid=174580

Group Home: https://groups.io/g/pcp
Contact Group Owner: [email protected]

Terms of Service: https://groups.io/static/tos

Unsubscribe: https://groups.io/g/pcp/leave/354243/563757577/xyzzy
-=-=-=-=-=-=-=-=-=-=-=-