activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From superawesome <>
Subject [GitHub] activemq pull request #272: replicated LevelDB fix and debugging output
Date Fri, 05 Jan 2018 22:45:29 GMT
GitHub user superawesome opened a pull request:

    replicated LevelDB fix and debugging output

    I know LevelDB is now deprecated, and this may not get merged because of that. I certainly
don't want to become its maintainer. I had an unhealthy cluster, and did not want to try and
migrate it while in that state. This is just a small change to get it healthy again after
a slave encountered this error:
    Unexpected session error: Maximum protocol buffer length exeeded
    In my case I believe this is due to having too many LevelDB log files to replicate (a
separate LevelDB bug, which I intend to investigate now that this cluster is healthy again).
    2 commits in this PR:
    1) debugging output to track that down and make it more ... debuggable.
    2) a 2-character change to increase a buffer size by 4x, to "fix" the problem.

You can merge this pull request into a Git repository by running:

    $ git pull master

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #272
commit 4549f8ebbad4fb9191ef99da48d053864b31916c
Author: Jake Maul <jakemaul@...>
Date:   2018-01-05T22:27:44Z

    adding stack trace output to debug log level
    Tracing a connection failure was proving problematic. The session error is a warning,
but the particular error *I* was having is actually rather fatal, as restarting the slave
connections does not fix anything- it just fails again (and again, and again...).
    This will land in the log file iff debug logging is enabled. Otherwise this is a no-op.

commit ce29c2f29c3d9f4ae5d930e57e573f69f09521f4
Author: Jake Maul <jakemaul@...>
Date:   2018-01-05T22:35:10Z

    larger buffer for reading replication frames
    The default size (1024*64=65536 bytes) was insufficient on a cluster I manage. I think
because of an unrelated bug where LevelDB log files don't get purged. This is a simple fix
to get it going again.
    Making it 4x as big was *not* scientifically determined. I tried making it 4x as big first,
it worked, and I haven't tried any other size. I don't know why it was 64k in the first place,
so I can't be sure this doesn't cause any side effects.



View raw message