You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Vincent Russell <vi...@gmail.com> on 2022/12/08 17:27:34 UTC

jdk 17 and accumulo testing

Hello,

We are currently using accumulo 2.0.1.

We are in the process of upgrading our source code to use jdk 17 however we
are running into some problems with our tests and the MiniAccumuloCluster.

One of our developer encountered the following issues:

   1. The MiniAccumumluoClusterImpl._exec is hardcoded with the JVM arg
   -XX:+IUseConcMarkSweepGC, which is no longer tolerated with JDK17.
   2. In Zookeeper 3.4.14, ConetStringParser uses createUnresolved to
   make IPAddresses.  SaslServerPrincipal.WrapperInetSocketAddress.getAddress
   uses InetSocketAddess.getAddress, which returns null because it's not
   resolved, resulting in a failure to connect to the newly-started zookeeper.
   3. StaticHostProvider.getHostString() tries to extract he hostname by
   calling toString on the address and taking everything before the colon, but
   in JDK17, the string format changed to "localhost/<unresolved->:xx" (where
   XX is still the port number).  That's incorrect and it can't resolve the
   names.


Has anyone come across/resolved these kinds of issues?  Is it not possible
to use java17 from a client perspective?  Will upgrading to accumulo 2.1
help?

Thanks,
Vincent

Re: jdk 17 and accumulo testing

Posted by Vincent Russell <vi...@gmail.com>.
Christopher,

I was able to verify that tests that previously failed related to this
issue now pass.    Other tests are failing due to api changes, but I think
that's another issue.

Thanks,
Vincent

On Fri, Apr 28, 2023 at 9:27 AM Vincent Russell <vi...@gmail.com>
wrote:

> Thank you for the response Christopher.
>
> I did not test that a snapshot after cshannon:accumulo-3094-fix was merged
> because cshannon appeared to be pretty confident that he was able to create
> a test that duplicated my issue and was able to fix it, but I can build a
> snapshot and see if my tests pass on Monday.
>
> Thanks again,
> Vincent
>
> On Fri, Apr 28, 2023 at 8:42 AM Christopher <ct...@apache.org> wrote:
>
>> There's a few outstanding issues. Notably, the issue mentioned on
>> https://github.com/apache/accumulo/issues/3346
>> There's also ensuring some stuff is marked as deprecated in 2.1.1 that
>> is mentioned in
>> https://github.com/apache/accumulo/pull/3265#discussion_r1177315428
>> (but that's really minor).
>>
>> The project tracker is at
>> https://github.com/apache/accumulo/projects/25 and there's a few
>> things in flight.
>>
>> I'm bad at estimating time (there was a time I thought we'd have 3.0
>> out in December 2022 and I thought we'd have 2.1.1 sometime around
>> February). Technically, we could put together a release candidate now,
>> but if it doesn't include some important things, we'll want to do
>> anther one right away, and that rapid churn is tiring for both devs
>> and users. I would watch #3346, as that seems to be the most critical
>> issue right now. Once that's figured out, releasing should be able to
>> follow shortly after.
>>
>> I'm curious if the issue addressed in
>> https://github.com/apache/accumulo/pull/3134 actually fixes your
>> issue. Have you tried a recent snapshot version to see if the problem
>> is fixed for you? I looked for, but didn't see, any comment from you
>> about that.
>>
>> On Fri, Apr 28, 2023 at 7:07 AM Vincent Russell
>> <vi...@gmail.com> wrote:
>> >
>> > Hello,
>> >
>> > Just checking in on if there is a timeframe for 2.1.1.
>> >
>> > This has been delaying our upgrade to jdk 17 for almost 5 month now.
>> >
>> >
>> > Thanks,
>> > Vincent
>> >
>> >
>> >
>> > On Fri, Dec 30, 2022, 12:57 PM Vincent Russell <
>> vincent.russell@gmail.com>
>> > wrote:
>> >
>> > > Ok.. Thank you for the update.
>> > >
>> > > On Fri, Dec 30, 2022 at 11:55 AM Christopher <ct...@apache.org>
>> wrote:
>> > >
>> > >> For reference, here's the PR working on the fix for 2.1.1:
>> > >> https://github.com/apache/accumulo/pull/3134
>> > >>
>> > >> On Fri, Dec 30, 2022 at 11:39 AM Christopher Shannon
>> > >> <ch...@gmail.com> wrote:
>> > >> >
>> > >> > Version 2.1.1 will be released with bug fixes and this fix (when
>> > >> finished
>> > >> > and merged) is planned to be included as part of that release. I
>> don't
>> > >> know
>> > >> > the exact time frame yet though.
>> > >> >
>> > >> > On Fri, Dec 30, 2022 at 11:04 AM Vincent Russell <
>> > >> vincent.russell@gmail.com>
>> > >> > wrote:
>> > >> >
>> > >> > > Hello,
>> > >> > >
>> > >> > > Are there any plans to release an accumulo 2.1 patch to fix this
>> > >> issue?
>> > >> > >
>> > >> > > Thanks,
>> > >> > >
>> > >> > > On Sat, Dec 17, 2022 at 7:36 PM Vincent Russell <
>> > >> vincent.russell@gmail.com
>> > >> > > >
>> > >> > > wrote:
>> > >> > >
>> > >> > > > No worries.  I'm glad I was able to help in some small way.
>> > >> > > >
>> > >> > > > Thank you for fixing the issue.
>> > >> > > >
>> > >> > > > On Sat, Dec 17, 2022 at 11:49 AM Christopher Shannon <
>> > >> > > > christopher.l.shannon@gmail.com> wrote:
>> > >> > > >
>> > >> > > >> I created https://github.com/apache/accumulo/pull/3134 and
>> that
>> > >> should
>> > >> > > >> fix
>> > >> > > >> this issue.
>> > >> > > >>
>> > >> > > >> Thanks Vincent for pointing out the issue in TServerUtils,
>> your
>> > >> testing
>> > >> > > >> made this easy to track down and fix.
>> > >> > > >>
>> > >> > > >>
>> > >> > > >> On Sat, Dec 17, 2022 at 9:00 AM Christopher Shannon <
>> > >> > > >> christopher.l.shannon@gmail.com> wrote:
>> > >> > > >>
>> > >> > > >> > I was able to reproduce the issue by setting the value size
>> for a
>> > >> > > >> mutation
>> > >> > > >> > to size 16384001 to make sure it's greater than the default
>> > >> value for
>> > >> > > >> > Thrift and it fails immediately. I will work on a fix now
>> that
>> > >> we know
>> > >> > > >> how
>> > >> > > >> > to reproduce it.
>> > >> > > >> >
>> > >> > > >> > On Fri, Dec 16, 2022 at 2:31 PM Christopher <
>> ctubbsii@apache.org
>> > >> >
>> > >> > > >> wrote:
>> > >> > > >> >
>> > >> > > >> >> I don't think it's intentional. This might be the source
>> of the
>> > >> > > >> problem.
>> > >> > > >> >>
>> > >> > > >> >> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
>> > >> > > >> >> <vi...@gmail.com> wrote:
>> > >> > > >> >> >
>> > >> > > >> >> > Also in TserverUtils:270, when the
>> TNonblockingServerSocket is
>> > >> > > >> created
>> > >> > > >> >> it
>> > >> > > >> >> > looks like it ends up using the default frame size.  I
>> am not
>> > >> sure
>> > >> > > if
>> > >> > > >> >> this
>> > >> > > >> >> > is intentional or not.
>> > >> > > >> >> >
>> > >> > > >> >> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
>> > >> > > >> >> vincent.russell@gmail.com>
>> > >> > > >> >> > wrote:
>> > >> > > >> >> >
>> > >> > > >> >> > > Christopher,
>> > >> > > >> >> > >
>> > >> > > >> >> > > I am not sure if this issue is related to 3042 or not.
>> > >> > > >> >> > >
>> > >> > > >> >> > > On the client side it does look like TConfiguration
>> ends up
>> > >> being
>> > >> > > >> >> called
>> > >> > > >> >> > > with the default constructor.  I am not sure if this is
>> > >> > > intentional
>> > >> > > >> >> or not.
>> > >> > > >> >> > >
>> > >> > > >> >> > > On the server side I see this stack, so it also looks
>> like:
>> > >> > > >> >> > >
>> > >> > > >> >> > > at
>> > >> > > org.apache.thrift.TConfiguration.<init>(TConfiguration.java:36)
>> > >> > > >> >> > > at
>> > >> > > >> >>
>> > >> > >
>> org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
>> > >> > > >> >> > > at
>> > >> > > >>
>> org.apache.thrift.TConfiguration.<clinit>(TConfiguration.java:65)
>> > >> > > >> >> > > at
>> > >> > > >> >> > >
>> > >> > > >> >>
>> > >> > > >>
>> > >> > >
>> > >>
>> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:74)
>> > >> > > >> >> > > at
>> > >> > > >> >> > >
>> > >> > > >> >>
>> > >> > > >>
>> > >> > >
>> > >>
>> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:68)
>> > >> > > >> >> > > at
>> > >> > > >> >> > >
>> > >> > > >> >>
>> > >> > > >>
>> > >> > >
>> > >>
>> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
>> > >> > > >> >> > > at
>> > >> > > >> >> > >
>> > >> > > >> >>
>> > >> > > >>
>> > >> > >
>> > >>
>> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
>> > >> > > >> >> > > at
>> > >> > > >> >> > >
>> > >> > > >> >>
>> > >> > > >>
>> > >> > >
>> > >>
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
>> > >> > > >> >> > > at
>> > >> > > >> >> > >
>> > >> > > >> >>
>> > >> > > >>
>> > >> > >
>> > >>
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
>> > >> > > >> >> > > at
>> > >> > > >> >> > >
>> > >> > > >> >>
>> > >> > > >>
>> > >> > >
>> > >>
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
>> > >> > > >> >> > >
>> > >> > > >> >> > >
>> > >> > > >> >> > > I see this in the server log so it does look like it
>> should
>> > >> be
>> > >> > > >> using
>> > >> > > >> >> 1G:
>> > >> > > >> >> > > 2022-09-01 16:59:41 INFO
>> > >> > > >> [org.apache.accumulo.tserver.TabletServer]
>> > >> > > >> >> > > ServerUtil:124 - general.server.message.size.max = 1G
>> > >> > > >> >> > >
>> > >> > > >> >> > > Thanks,
>> > >> > > >> >> > > Vincent
>> > >> > > >> >> > >
>> > >> > > >> >> > > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
>> > >> > > >> >> > > vincent.russell@gmail.com> wrote:
>> > >> > > >> >> > >
>> > >> > > >> >> > >>
>> > >> > > >> >> > >>
>> > >> > > >> >> > >> I had to make a stack trace with hacking together a
>> remote
>> > >> debug
>> > >> > > >> >> instance:
>> > >> > > >> >> > >>
>> > >> > > >> >> > >> at
>> > >> > > >> >> > >>
>> > >> > > >> >>
>> > >> > > >>
>> > >> > >
>> > >>
>> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
>> > >> > > >> >> > >> at
>> > >> > > >> >> > >>
>> > >> > > >> >>
>> > >> > > >>
>> > >> > >
>> > >>
>> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
>> > >> > > >> >> > >> at
>> > >> > > >> >> > >>
>> > >> > > >> >>
>> > >> > > >>
>> > >> > >
>> > >>
>> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
>> > >> > > >> >> > >> at
>> > >> > > >> >> > >>
>> > >> > > >> >>
>> > >> > > >>
>> > >> > >
>> > >>
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
>> > >> > > >> >> > >> at
>> > >> > > >> >> > >>
>> > >> > > >> >>
>> > >> > > >>
>> > >> > >
>> > >>
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
>> > >> > > >> >> > >>
>> > >> > > >> >> > >> On Thu, Dec 15, 2022 at 12:52 AM Christopher <
>> > >> > > ctubbsii@apache.org
>> > >> > > >> >
>> > >> > > >> >> wrote:
>> > >> > > >> >> > >>
>> > >> > > >> >> > >>> From the numbers in the message, it looks like you're
>> > >> sending
>> > >> > > an
>> > >> > > >> >> 18MB
>> > >> > > >> >> > >>> payload but something in Thrift is limiting things to
>> > >> 16384000
>> > >> > > >> >> > >>> (16000KB). I doubt you've overridden the default
>> > >> > > >> >> > >>> general.server.message.size.max to be anything that
>> low
>> > >> (the
>> > >> > > >> default
>> > >> > > >> >> > >>> is 1G). Unless you're flushing after every mutation,
>> it
>> > >> would
>> > >> > > >> not be
>> > >> > > >> >> > >>> surprising to exceed the 16MB max frame size
>> indicated in
>> > >> the
>> > >> > > >> error
>> > >> > > >> >> > >>> message quite quickly.
>> > >> > > >> >> > >>>
>> > >> > > >> >> > >>> This value of 16384000 seemed weird. It looks like
>> it's
>> > >> not
>> > >> > > using
>> > >> > > >> >> our
>> > >> > > >> >> > >>> configuration, but using the built-in default value
>> of
>> > >> > > >> >> > >>>
>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE.
>> > >> It
>> > >> > > looks
>> > >> > > >> >> like
>> > >> > > >> >> > >>> this can happen whenever `new TConfiguration()` is
>> called
>> > >> > > without
>> > >> > > >> >> > >>> parameters... and there's a fair amount of internal
>> code,
>> > >> > > mostly
>> > >> > > >> in
>> > >> > > >> >> > >>> libthrift itself, that does that. It's a bit tricky
>> to
>> > >> track
>> > >> > > down
>> > >> > > >> >> the
>> > >> > > >> >> > >>> one causing this particular issue. If you have a full
>> > >> stack
>> > >> > > >> trace,
>> > >> > > >> >> it
>> > >> > > >> >> > >>> could help.
>> > >> > > >> >> > >>>
>> > >> > > >> >> > >>> Also, this might be the same issue seen reported in
>> > >> > > >> >> > >>> https://github.com/apache/accumulo/issues/3042
>> > >> > > >> >> > >>>
>> > >> > > >> >> > >>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
>> > >> > > >> >> > >>> <vi...@gmail.com> wrote:
>> > >> > > >> >> > >>> >
>> > >> > > >> >> > >>> > I was able to work out all of my compilation
>> issues;
>> > >> however
>> > >> > > >> when
>> > >> > > >> >> I
>> > >> > > >> >> > >>> run an
>> > >> > > >> >> > >>> > integration test with the Mini Accumulo Cluster
>> that
>> > >> tests
>> > >> > > >> writing
>> > >> > > >> >> > >>> > mutations with values of 5mb the flush hangs
>> forever
>> > >> > > >> >> > >>> > and I see  the following logs in the TabletServer
>> logs:
>> > >> > > >> >> > >>> >
>> > >> > > >> >> > >>> > 20:41:02.306 [Thread-7] ERROR
>> > >> > > >> >> > >>> >
>> o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer -
>> > >> Read a
>> > >> > > >> frame
>> > >> > > >> >> > >>> size of
>> > >> > > >> >> > >>> > 18874697, which is bigger than the maximum
>> allowable
>> > >> frame
>> > >> > > size
>> > >> > > >> >> > >>> 16384000
>> > >> > > >> >> > >>> > for ALL connections.
>> > >> > > >> >> > >>> > 20:41:03.582 [Thread-7] ERROR
>> > >> > > >> >> > >>> >
>> o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer -
>> > >> Read a
>> > >> > > >> frame
>> > >> > > >> >> > >>> size of
>> > >> > > >> >> > >>> > 18874697, which is bigger than the maximum
>> allowable
>> > >> frame
>> > >> > > size
>> > >> > > >> >> > >>> 16384000
>> > >> > > >> >> > >>> > for ALL connections.
>> > >> > > >> >> > >>> > 20:41:05.079 [Thread-7] ERROR
>> > >> > > >> >> > >>> >
>> o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer -
>> > >> Read a
>> > >> > > >> frame
>> > >> > > >> >> > >>> size of
>> > >> > > >> >> > >>> > 18874697, which is bigger than the maximum
>> allowable
>> > >> frame
>> > >> > > size
>> > >> > > >> >> > >>> 16384000
>> > >> > > >> >> > >>> > for ALL connections.
>> > >> > > >> >> > >>> >
>> > >> > > >> >> > >>> > Other tests that write smaller amounts of data
>> appear
>> > >> to work
>> > >> > > >> >> fine.
>> > >> > > >> >> > >>> >
>> > >> > > >> >> > >>> > Any idea what the issue might be?
>> > >> > > >> >> > >>> >
>> > >> > > >> >> > >>> > Thank you,
>> > >> > > >> >> > >>> > Vincent
>> > >> > > >> >> > >>> >
>> > >> > > >> >> > >>> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
>> > >> > > >> >> > >>> vincent.russell@gmail.com>
>> > >> > > >> >> > >>> > wrote:
>> > >> > > >> >> > >>> >
>> > >> > > >> >> > >>> > > Thank you both for your responses.
>> > >> > > >> >> > >>> > >
>> > >> > > >> >> > >>> > > We are using an event store library from a sister
>> > >> project
>> > >> > > >> that
>> > >> > > >> >> was
>> > >> > > >> >> > >>> written
>> > >> > > >> >> > >>> > > for accumulo 1.10., which I have already
>> upgraded to
>> > >> 2.0.
>> > >> > > >> >> > >>> > >
>> > >> > > >> >> > >>> > > I'll spend some time investigating how bad the
>> usage
>> > >> of the
>> > >> > > >> >> internal
>> > >> > > >> >> > >>> > > packages are and get back to you.
>> > >> > > >> >> > >>> > >
>> > >> > > >> >> > >>> > > Thanks again,
>> > >> > > >> >> > >>> > >
>> > >> > > >> >> > >>> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <
>> > >> > > >> >> ctubbsii@apache.org>
>> > >> > > >> >> > >>> wrote:
>> > >> > > >> >> > >>> > >
>> > >> > > >> >> > >>> > >> To add to Dave's answer, the public API is
>> defined at
>> > >> > > >> >> > >>> > >> https://accumulo.apache.org/api/
>> > >> > > >> >> > >>> > >> Anything else is not public and is subject to
>> change
>> > >> > > without
>> > >> > > >> >> notice
>> > >> > > >> >> > >>> on
>> > >> > > >> >> > >>> > >> any release without any attempt to retain
>> > >> compatibility.
>> > >> > > >> >> > >>> > >>
>> > >> > > >> >> > >>> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <
>> > >> > > >> >> dmarion18@gmail.com>
>> > >> > > >> >> > >>> wrote:
>> > >> > > >> >> > >>> > >> >
>> > >> > > >> >> > >>> > >> > There is no guide. You are using
>> implementation
>> > >> classes
>> > >> > > >> (see
>> > >> > > >> >> > >>> clientImpl
>> > >> > > >> >> > >>> > >> in
>> > >> > > >> >> > >>> > >> > the package name) vs. using the client api.
>> If you
>> > >> can
>> > >> > > use
>> > >> > > >> >> the
>> > >> > > >> >> > >>> client
>> > >> > > >> >> > >>> > >> api
>> > >> > > >> >> > >>> > >> > directly, then this should insulate you from
>> > >> changes in
>> > >> > > >> the
>> > >> > > >> >> future
>> > >> > > >> >> > >>> > >> (except
>> > >> > > >> >> > >>> > >> > during major versions). We can try and find
>> where
>> > >> things
>> > >> > > >> >> might
>> > >> > > >> >> > >>> have
>> > >> > > >> >> > >>> > >> moved,
>> > >> > > >> >> > >>> > >> > but a class may have been split into multiple
>> > >> pieces. If
>> > >> > > >> you
>> > >> > > >> >> could
>> > >> > > >> >> > >>> > >> provide
>> > >> > > >> >> > >>> > >> > class and method, that would be easier.
>> > >> > > >> >> > >>> > >> >
>> > >> > > >> >> > >>> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent
>> Russell <
>> > >> > > >> >> > >>> > >> vincent.russell@gmail.com>
>> > >> > > >> >> > >>> > >> > wrote:
>> > >> > > >> >> > >>> > >> >
>> > >> > > >> >> > >>> > >> > > Is there a guide that shows where classes
>> may
>> > >> have
>> > >> > > been
>> > >> > > >> >> moved
>> > >> > > >> >> > >>> with
>> > >> > > >> >> > >>> > >> moving
>> > >> > > >> >> > >>> > >> > > from 2.0 to 2.1?  For instance, I am having
>> > >> issues
>> > >> > > >> >> compiling,
>> > >> > > >> >> > >>> because
>> > >> > > >> >> > >>> > >> the
>> > >> > > >> >> > >>> > >> > > following class doesn't exist:
>> > >> > > >> >> > >>> > >> > > import
>> > >> org.apache.accumulo.core.clientImpl.Tables;
>> > >> > > >> >> > >>> > >> > >
>> > >> > > >> >> > >>> > >> > > I'm just getting started so I'm sure there
>> are
>> > >> others.
>> > >> > > >> >> > >>> > >> > >
>> > >> > > >> >> > >>> > >> > > Thanks,
>> > >> > > >> >> > >>> > >> > > Vincent
>> > >> > > >> >> > >>> > >> > >
>> > >> > > >> >> > >>> > >> > >
>> > >> > > >> >> > >>> > >> > >
>> > >> > > >> >> > >>> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent
>> Russell <
>> > >> > > >> >> > >>> > >> vincent.russell@gmail.com>
>> > >> > > >> >> > >>> > >> > > wrote:
>> > >> > > >> >> > >>> > >> > >
>> > >> > > >> >> > >>> > >> > > > I mean Christopher.
>> > >> > > >> >> > >>> > >> > > >
>> > >> > > >> >> > >>> > >> > > > Thanks again.
>> > >> > > >> >> > >>> > >> > > >
>> > >> > > >> >> > >>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent
>> Russell
>> > >> <
>> > >> > > >> >> > >>> > >> > > vincent.russell@gmail.com>
>> > >> > > >> >> > >>> > >> > > > wrote:
>> > >> > > >> >> > >>> > >> > > >
>> > >> > > >> >> > >>> > >> > > >> Thank you Chris.
>> > >> > > >> >> > >>> > >> > > >>
>> > >> > > >> >> > >>> > >> > > >> Will will upgrade to Accumulo 2.1 and
>> > >> ZooKeeper
>> > >> > > 3.7
>> > >> > > >> or
>> > >> > > >> >> > >>> later as
>> > >> > > >> >> > >>> > >> soon as
>> > >> > > >> >> > >>> > >> > > >> possible.
>> > >> > > >> >> > >>> > >> > > >>
>> > >> > > >> >> > >>> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM
>> Christopher <
>> > >> > > >> >> > >>> ctubbsii@apache.org>
>> > >> > > >> >> > >>> > >> wrote:
>> > >> > > >> >> > >>> > >> > > >>
>> > >> > > >> >> > >>> > >> > > >>> Hi Vincent,
>> > >> > > >> >> > >>> > >> > > >>>
>> > >> > > >> >> > >>> > >> > > >>> Version 2.0.1 is end of life as of the
>> 2.1.0
>> > >> LTM
>> > >> > > >> >> release,
>> > >> > > >> >> > >>> and 2.0
>> > >> > > >> >> > >>> > >> is
>> > >> > > >> >> > >>> > >> > > >>> not expected to receive any further
>> updates.
>> > >> > > Version
>> > >> > > >> >> 2.1.0
>> > >> > > >> >> > >>> may
>> > >> > > >> >> > >>> > >> work
>> > >> > > >> >> > >>> > >> > > >>> with ZooKeeper 3.4, but was developed
>> and
>> > >> tested
>> > >> > > >> >> against
>> > >> > > >> >> > >>> 3.5 and
>> > >> > > >> >> > >>> > >> later
>> > >> > > >> >> > >>> > >> > > >>> versions. I believe the ZooKeeper
>> community
>> > >> is
>> > >> > > >> >> currently
>> > >> > > >> >> > >>> > >> considering
>> > >> > > >> >> > >>> > >> > > >>> whether to make 3.6 end-of-life
>> themselves,
>> > >> so I
>> > >> > > >> would
>> > >> > > >> >> > >>> recommend
>> > >> > > >> >> > >>> > >> using
>> > >> > > >> >> > >>> > >> > > >>> Accumulo 2.1.0 with the latest
>> ZooKeeper 3.7
>> > >> or
>> > >> > > >> later
>> > >> > > >> >> to
>> > >> > > >> >> > >>> have the
>> > >> > > >> >> > >>> > >> best
>> > >> > > >> >> > >>> > >> > > >>> chance of any kind of support,
>> including JDK
>> > >> 17
>> > >> > > >> >> support.
>> > >> > > >> >> > >>> > >> > > >>>
>> > >> > > >> >> > >>> > >> > > >>> As for your specific issues:
>> > >> > > >> >> > >>> > >> > > >>>
>> > >> > > >> >> > >>> > >> > > >>> 1. This is already fixed in 2.1.0
>> > >> > > >> >> > >>> > >> > > >>> 2/3. These issues are likely fixed in
>> newer
>> > >> > > >> ZooKeeper
>> > >> > > >> >> > >>> versions. I
>> > >> > > >> >> > >>> > >> > > >>> haven't seen them anytime recently,
>> anyway.
>> > >> Bugs
>> > >> > > in
>> > >> > > >> >> > >>> ZooKeeper
>> > >> > > >> >> > >>> > >> itself
>> > >> > > >> >> > >>> > >> > > >>> are out of scope for the Accumulo
>> > >> developers, but
>> > >> > > I
>> > >> > > >> >> have
>> > >> > > >> >> > >>> tried
>> > >> > > >> >> > >>> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and
>> > >> ZooKeeper
>> > >> > > >> >> 3.8.0 and
>> > >> > > >> >> > >>> > >> haven't
>> > >> > > >> >> > >>> > >> > > >>> observed any unresolved issues.
>> However, it's
>> > >> > > >> >> difficult to
>> > >> > > >> >> > >>> > >> actually
>> > >> > > >> >> > >>> > >> > > >>> run it because I don't think Hadoop has
>> good
>> > >> JDK
>> > >> > > 17
>> > >> > > >> >> support
>> > >> > > >> >> > >>> yet.
>> > >> > > >> >> > >>> > >> So,
>> > >> > > >> >> > >>> > >> > > >>> MiniAccumuloCluster seems to work with
>> JDK
>> > >> 17, as
>> > >> > > >> does
>> > >> > > >> >> > >>> Accumulo
>> > >> > > >> >> > >>> > >> and ZK
>> > >> > > >> >> > >>> > >> > > >>> 3.8, but I don't think a full Hadoop
>> cluster
>> > >> would
>> > >> > > >> >> (yet).
>> > >> > > >> >> > >>> > >> > > >>>
>> > >> > > >> >> > >>> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent
>> > >> Russell
>> > >> > > >> >> > >>> > >> > > >>> <vi...@gmail.com> wrote:
>> > >> > > >> >> > >>> > >> > > >>> >
>> > >> > > >> >> > >>> > >> > > >>> > Hello,
>> > >> > > >> >> > >>> > >> > > >>> >
>> > >> > > >> >> > >>> > >> > > >>> > We are currently using accumulo 2.0.1.
>> > >> > > >> >> > >>> > >> > > >>> >
>> > >> > > >> >> > >>> > >> > > >>> > We are in the process of upgrading our
>> > >> source
>> > >> > > code
>> > >> > > >> >> to use
>> > >> > > >> >> > >>> jdk 17
>> > >> > > >> >> > >>> > >> > > >>> however we
>> > >> > > >> >> > >>> > >> > > >>> > are running into some problems with
>> our
>> > >> tests
>> > >> > > and
>> > >> > > >> the
>> > >> > > >> >> > >>> > >> > > >>> MiniAccumuloCluster.
>> > >> > > >> >> > >>> > >> > > >>> >
>> > >> > > >> >> > >>> > >> > > >>> > One of our developer encountered the
>> > >> following
>> > >> > > >> >> issues:
>> > >> > > >> >> > >>> > >> > > >>> >
>> > >> > > >> >> > >>> > >> > > >>> >    1. The
>> MiniAccumumluoClusterImpl._exec
>> > >> is
>> > >> > > >> >> hardcoded
>> > >> > > >> >> > >>> with the
>> > >> > > >> >> > >>> > >> JVM
>> > >> > > >> >> > >>> > >> > > arg
>> > >> > > >> >> > >>> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is
>> no
>> > >> longer
>> > >> > > >> >> tolerated
>> > >> > > >> >> > >>> with
>> > >> > > >> >> > >>> > >> JDK17.
>> > >> > > >> >> > >>> > >> > > >>> >    2. In Zookeeper 3.4.14,
>> > >> ConetStringParser
>> > >> > > uses
>> > >> > > >> >> > >>> > >> createUnresolved to
>> > >> > > >> >> > >>> > >> > > >>> >    make IPAddresses.
>> > >> > > >> >> > >>> > >> > > >>>
>> > >> > > >> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
>> > >> > > >> >> > >>> > >> > > >>> >    uses InetSocketAddess.getAddress,
>> which
>> > >> > > returns
>> > >> > > >> >> null
>> > >> > > >> >> > >>> because
>> > >> > > >> >> > >>> > >> it's
>> > >> > > >> >> > >>> > >> > > >>> not
>> > >> > > >> >> > >>> > >> > > >>> >    resolved, resulting in a failure to
>> > >> connect
>> > >> > > to
>> > >> > > >> the
>> > >> > > >> >> > >>> > >> newly-started
>> > >> > > >> >> > >>> > >> > > >>> zookeeper.
>> > >> > > >> >> > >>> > >> > > >>> >    3.
>> StaticHostProvider.getHostString()
>> > >> tries
>> > >> > > to
>> > >> > > >> >> extract
>> > >> > > >> >> > >>> he
>> > >> > > >> >> > >>> > >> hostname
>> > >> > > >> >> > >>> > >> > > >>> by
>> > >> > > >> >> > >>> > >> > > >>> >    calling toString on the address and
>> > >> taking
>> > >> > > >> >> everything
>> > >> > > >> >> > >>> before
>> > >> > > >> >> > >>> > >> the
>> > >> > > >> >> > >>> > >> > > >>> colon, but
>> > >> > > >> >> > >>> > >> > > >>> >    in JDK17, the string format
>> changed to
>> > >> > > >> >> > >>> > >> > > "localhost/<unresolved->:xx"
>> > >> > > >> >> > >>> > >> > > >>> (where
>> > >> > > >> >> > >>> > >> > > >>> >    XX is still the port number).
>> That's
>> > >> > > incorrect
>> > >> > > >> >> and it
>> > >> > > >> >> > >>> can't
>> > >> > > >> >> > >>> > >> > > >>> resolve the
>> > >> > > >> >> > >>> > >> > > >>> >    names.
>> > >> > > >> >> > >>> > >> > > >>> >
>> > >> > > >> >> > >>> > >> > > >>> >
>> > >> > > >> >> > >>> > >> > > >>> > Has anyone come across/resolved these
>> > >> kinds of
>> > >> > > >> >> issues?
>> > >> > > >> >> > >>> Is it
>> > >> > > >> >> > >>> > >> not
>> > >> > > >> >> > >>> > >> > > >>> possible
>> > >> > > >> >> > >>> > >> > > >>> > to use java17 from a client
>> perspective?
>> > >> Will
>> > >> > > >> >> upgrading
>> > >> > > >> >> > >>> to
>> > >> > > >> >> > >>> > >> accumulo
>> > >> > > >> >> > >>> > >> > > >>> 2.1
>> > >> > > >> >> > >>> > >> > > >>> > help?
>> > >> > > >> >> > >>> > >> > > >>> >
>> > >> > > >> >> > >>> > >> > > >>> > Thanks,
>> > >> > > >> >> > >>> > >> > > >>> > Vincent
>> > >> > > >> >> > >>> > >> > > >>>
>> > >> > > >> >> > >>> > >> > > >>
>> > >> > > >> >> > >>> > >> > >
>> > >> > > >> >> > >>> > >>
>> > >> > > >> >> > >>> > >
>> > >> > > >> >> > >>>
>> > >> > > >> >> > >>
>> > >> > > >> >>
>> > >> > > >> >
>> > >> > > >>
>> > >> > > >
>> > >> > >
>> > >>
>> > >
>>
>

Re: jdk 17 and accumulo testing

Posted by Vincent Russell <vi...@gmail.com>.
Thank you for the response Christopher.

I did not test that a snapshot after cshannon:accumulo-3094-fix was merged
because cshannon appeared to be pretty confident that he was able to create
a test that duplicated my issue and was able to fix it, but I can build a
snapshot and see if my tests pass on Monday.

Thanks again,
Vincent

On Fri, Apr 28, 2023 at 8:42 AM Christopher <ct...@apache.org> wrote:

> There's a few outstanding issues. Notably, the issue mentioned on
> https://github.com/apache/accumulo/issues/3346
> There's also ensuring some stuff is marked as deprecated in 2.1.1 that
> is mentioned in
> https://github.com/apache/accumulo/pull/3265#discussion_r1177315428
> (but that's really minor).
>
> The project tracker is at
> https://github.com/apache/accumulo/projects/25 and there's a few
> things in flight.
>
> I'm bad at estimating time (there was a time I thought we'd have 3.0
> out in December 2022 and I thought we'd have 2.1.1 sometime around
> February). Technically, we could put together a release candidate now,
> but if it doesn't include some important things, we'll want to do
> anther one right away, and that rapid churn is tiring for both devs
> and users. I would watch #3346, as that seems to be the most critical
> issue right now. Once that's figured out, releasing should be able to
> follow shortly after.
>
> I'm curious if the issue addressed in
> https://github.com/apache/accumulo/pull/3134 actually fixes your
> issue. Have you tried a recent snapshot version to see if the problem
> is fixed for you? I looked for, but didn't see, any comment from you
> about that.
>
> On Fri, Apr 28, 2023 at 7:07 AM Vincent Russell
> <vi...@gmail.com> wrote:
> >
> > Hello,
> >
> > Just checking in on if there is a timeframe for 2.1.1.
> >
> > This has been delaying our upgrade to jdk 17 for almost 5 month now.
> >
> >
> > Thanks,
> > Vincent
> >
> >
> >
> > On Fri, Dec 30, 2022, 12:57 PM Vincent Russell <
> vincent.russell@gmail.com>
> > wrote:
> >
> > > Ok.. Thank you for the update.
> > >
> > > On Fri, Dec 30, 2022 at 11:55 AM Christopher <ct...@apache.org>
> wrote:
> > >
> > >> For reference, here's the PR working on the fix for 2.1.1:
> > >> https://github.com/apache/accumulo/pull/3134
> > >>
> > >> On Fri, Dec 30, 2022 at 11:39 AM Christopher Shannon
> > >> <ch...@gmail.com> wrote:
> > >> >
> > >> > Version 2.1.1 will be released with bug fixes and this fix (when
> > >> finished
> > >> > and merged) is planned to be included as part of that release. I
> don't
> > >> know
> > >> > the exact time frame yet though.
> > >> >
> > >> > On Fri, Dec 30, 2022 at 11:04 AM Vincent Russell <
> > >> vincent.russell@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Hello,
> > >> > >
> > >> > > Are there any plans to release an accumulo 2.1 patch to fix this
> > >> issue?
> > >> > >
> > >> > > Thanks,
> > >> > >
> > >> > > On Sat, Dec 17, 2022 at 7:36 PM Vincent Russell <
> > >> vincent.russell@gmail.com
> > >> > > >
> > >> > > wrote:
> > >> > >
> > >> > > > No worries.  I'm glad I was able to help in some small way.
> > >> > > >
> > >> > > > Thank you for fixing the issue.
> > >> > > >
> > >> > > > On Sat, Dec 17, 2022 at 11:49 AM Christopher Shannon <
> > >> > > > christopher.l.shannon@gmail.com> wrote:
> > >> > > >
> > >> > > >> I created https://github.com/apache/accumulo/pull/3134 and
> that
> > >> should
> > >> > > >> fix
> > >> > > >> this issue.
> > >> > > >>
> > >> > > >> Thanks Vincent for pointing out the issue in TServerUtils, your
> > >> testing
> > >> > > >> made this easy to track down and fix.
> > >> > > >>
> > >> > > >>
> > >> > > >> On Sat, Dec 17, 2022 at 9:00 AM Christopher Shannon <
> > >> > > >> christopher.l.shannon@gmail.com> wrote:
> > >> > > >>
> > >> > > >> > I was able to reproduce the issue by setting the value size
> for a
> > >> > > >> mutation
> > >> > > >> > to size 16384001 to make sure it's greater than the default
> > >> value for
> > >> > > >> > Thrift and it fails immediately. I will work on a fix now
> that
> > >> we know
> > >> > > >> how
> > >> > > >> > to reproduce it.
> > >> > > >> >
> > >> > > >> > On Fri, Dec 16, 2022 at 2:31 PM Christopher <
> ctubbsii@apache.org
> > >> >
> > >> > > >> wrote:
> > >> > > >> >
> > >> > > >> >> I don't think it's intentional. This might be the source of
> the
> > >> > > >> problem.
> > >> > > >> >>
> > >> > > >> >> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
> > >> > > >> >> <vi...@gmail.com> wrote:
> > >> > > >> >> >
> > >> > > >> >> > Also in TserverUtils:270, when the
> TNonblockingServerSocket is
> > >> > > >> created
> > >> > > >> >> it
> > >> > > >> >> > looks like it ends up using the default frame size.  I am
> not
> > >> sure
> > >> > > if
> > >> > > >> >> this
> > >> > > >> >> > is intentional or not.
> > >> > > >> >> >
> > >> > > >> >> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
> > >> > > >> >> vincent.russell@gmail.com>
> > >> > > >> >> > wrote:
> > >> > > >> >> >
> > >> > > >> >> > > Christopher,
> > >> > > >> >> > >
> > >> > > >> >> > > I am not sure if this issue is related to 3042 or not.
> > >> > > >> >> > >
> > >> > > >> >> > > On the client side it does look like TConfiguration
> ends up
> > >> being
> > >> > > >> >> called
> > >> > > >> >> > > with the default constructor.  I am not sure if this is
> > >> > > intentional
> > >> > > >> >> or not.
> > >> > > >> >> > >
> > >> > > >> >> > > On the server side I see this stack, so it also looks
> like:
> > >> > > >> >> > >
> > >> > > >> >> > > at
> > >> > > org.apache.thrift.TConfiguration.<init>(TConfiguration.java:36)
> > >> > > >> >> > > at
> > >> > > >> >>
> > >> > >
> org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
> > >> > > >> >> > > at
> > >> > > >>
> org.apache.thrift.TConfiguration.<clinit>(TConfiguration.java:65)
> > >> > > >> >> > > at
> > >> > > >> >> > >
> > >> > > >> >>
> > >> > > >>
> > >> > >
> > >>
> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:74)
> > >> > > >> >> > > at
> > >> > > >> >> > >
> > >> > > >> >>
> > >> > > >>
> > >> > >
> > >>
> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:68)
> > >> > > >> >> > > at
> > >> > > >> >> > >
> > >> > > >> >>
> > >> > > >>
> > >> > >
> > >>
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
> > >> > > >> >> > > at
> > >> > > >> >> > >
> > >> > > >> >>
> > >> > > >>
> > >> > >
> > >>
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
> > >> > > >> >> > > at
> > >> > > >> >> > >
> > >> > > >> >>
> > >> > > >>
> > >> > >
> > >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
> > >> > > >> >> > > at
> > >> > > >> >> > >
> > >> > > >> >>
> > >> > > >>
> > >> > >
> > >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
> > >> > > >> >> > > at
> > >> > > >> >> > >
> > >> > > >> >>
> > >> > > >>
> > >> > >
> > >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> > >> > > >> >> > >
> > >> > > >> >> > >
> > >> > > >> >> > > I see this in the server log so it does look like it
> should
> > >> be
> > >> > > >> using
> > >> > > >> >> 1G:
> > >> > > >> >> > > 2022-09-01 16:59:41 INFO
> > >> > > >> [org.apache.accumulo.tserver.TabletServer]
> > >> > > >> >> > > ServerUtil:124 - general.server.message.size.max = 1G
> > >> > > >> >> > >
> > >> > > >> >> > > Thanks,
> > >> > > >> >> > > Vincent
> > >> > > >> >> > >
> > >> > > >> >> > > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
> > >> > > >> >> > > vincent.russell@gmail.com> wrote:
> > >> > > >> >> > >
> > >> > > >> >> > >>
> > >> > > >> >> > >>
> > >> > > >> >> > >> I had to make a stack trace with hacking together a
> remote
> > >> debug
> > >> > > >> >> instance:
> > >> > > >> >> > >>
> > >> > > >> >> > >> at
> > >> > > >> >> > >>
> > >> > > >> >>
> > >> > > >>
> > >> > >
> > >>
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
> > >> > > >> >> > >> at
> > >> > > >> >> > >>
> > >> > > >> >>
> > >> > > >>
> > >> > >
> > >>
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
> > >> > > >> >> > >> at
> > >> > > >> >> > >>
> > >> > > >> >>
> > >> > > >>
> > >> > >
> > >>
> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
> > >> > > >> >> > >> at
> > >> > > >> >> > >>
> > >> > > >> >>
> > >> > > >>
> > >> > >
> > >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
> > >> > > >> >> > >> at
> > >> > > >> >> > >>
> > >> > > >> >>
> > >> > > >>
> > >> > >
> > >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> > >> > > >> >> > >>
> > >> > > >> >> > >> On Thu, Dec 15, 2022 at 12:52 AM Christopher <
> > >> > > ctubbsii@apache.org
> > >> > > >> >
> > >> > > >> >> wrote:
> > >> > > >> >> > >>
> > >> > > >> >> > >>> From the numbers in the message, it looks like you're
> > >> sending
> > >> > > an
> > >> > > >> >> 18MB
> > >> > > >> >> > >>> payload but something in Thrift is limiting things to
> > >> 16384000
> > >> > > >> >> > >>> (16000KB). I doubt you've overridden the default
> > >> > > >> >> > >>> general.server.message.size.max to be anything that
> low
> > >> (the
> > >> > > >> default
> > >> > > >> >> > >>> is 1G). Unless you're flushing after every mutation,
> it
> > >> would
> > >> > > >> not be
> > >> > > >> >> > >>> surprising to exceed the 16MB max frame size
> indicated in
> > >> the
> > >> > > >> error
> > >> > > >> >> > >>> message quite quickly.
> > >> > > >> >> > >>>
> > >> > > >> >> > >>> This value of 16384000 seemed weird. It looks like
> it's
> > >> not
> > >> > > using
> > >> > > >> >> our
> > >> > > >> >> > >>> configuration, but using the built-in default value of
> > >> > > >> >> > >>>
> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE.
> > >> It
> > >> > > looks
> > >> > > >> >> like
> > >> > > >> >> > >>> this can happen whenever `new TConfiguration()` is
> called
> > >> > > without
> > >> > > >> >> > >>> parameters... and there's a fair amount of internal
> code,
> > >> > > mostly
> > >> > > >> in
> > >> > > >> >> > >>> libthrift itself, that does that. It's a bit tricky to
> > >> track
> > >> > > down
> > >> > > >> >> the
> > >> > > >> >> > >>> one causing this particular issue. If you have a full
> > >> stack
> > >> > > >> trace,
> > >> > > >> >> it
> > >> > > >> >> > >>> could help.
> > >> > > >> >> > >>>
> > >> > > >> >> > >>> Also, this might be the same issue seen reported in
> > >> > > >> >> > >>> https://github.com/apache/accumulo/issues/3042
> > >> > > >> >> > >>>
> > >> > > >> >> > >>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
> > >> > > >> >> > >>> <vi...@gmail.com> wrote:
> > >> > > >> >> > >>> >
> > >> > > >> >> > >>> > I was able to work out all of my compilation issues;
> > >> however
> > >> > > >> when
> > >> > > >> >> I
> > >> > > >> >> > >>> run an
> > >> > > >> >> > >>> > integration test with the Mini Accumulo Cluster that
> > >> tests
> > >> > > >> writing
> > >> > > >> >> > >>> > mutations with values of 5mb the flush hangs forever
> > >> > > >> >> > >>> > and I see  the following logs in the TabletServer
> logs:
> > >> > > >> >> > >>> >
> > >> > > >> >> > >>> > 20:41:02.306 [Thread-7] ERROR
> > >> > > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer
> -
> > >> Read a
> > >> > > >> frame
> > >> > > >> >> > >>> size of
> > >> > > >> >> > >>> > 18874697, which is bigger than the maximum allowable
> > >> frame
> > >> > > size
> > >> > > >> >> > >>> 16384000
> > >> > > >> >> > >>> > for ALL connections.
> > >> > > >> >> > >>> > 20:41:03.582 [Thread-7] ERROR
> > >> > > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer
> -
> > >> Read a
> > >> > > >> frame
> > >> > > >> >> > >>> size of
> > >> > > >> >> > >>> > 18874697, which is bigger than the maximum allowable
> > >> frame
> > >> > > size
> > >> > > >> >> > >>> 16384000
> > >> > > >> >> > >>> > for ALL connections.
> > >> > > >> >> > >>> > 20:41:05.079 [Thread-7] ERROR
> > >> > > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer
> -
> > >> Read a
> > >> > > >> frame
> > >> > > >> >> > >>> size of
> > >> > > >> >> > >>> > 18874697, which is bigger than the maximum allowable
> > >> frame
> > >> > > size
> > >> > > >> >> > >>> 16384000
> > >> > > >> >> > >>> > for ALL connections.
> > >> > > >> >> > >>> >
> > >> > > >> >> > >>> > Other tests that write smaller amounts of data
> appear
> > >> to work
> > >> > > >> >> fine.
> > >> > > >> >> > >>> >
> > >> > > >> >> > >>> > Any idea what the issue might be?
> > >> > > >> >> > >>> >
> > >> > > >> >> > >>> > Thank you,
> > >> > > >> >> > >>> > Vincent
> > >> > > >> >> > >>> >
> > >> > > >> >> > >>> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
> > >> > > >> >> > >>> vincent.russell@gmail.com>
> > >> > > >> >> > >>> > wrote:
> > >> > > >> >> > >>> >
> > >> > > >> >> > >>> > > Thank you both for your responses.
> > >> > > >> >> > >>> > >
> > >> > > >> >> > >>> > > We are using an event store library from a sister
> > >> project
> > >> > > >> that
> > >> > > >> >> was
> > >> > > >> >> > >>> written
> > >> > > >> >> > >>> > > for accumulo 1.10., which I have already upgraded
> to
> > >> 2.0.
> > >> > > >> >> > >>> > >
> > >> > > >> >> > >>> > > I'll spend some time investigating how bad the
> usage
> > >> of the
> > >> > > >> >> internal
> > >> > > >> >> > >>> > > packages are and get back to you.
> > >> > > >> >> > >>> > >
> > >> > > >> >> > >>> > > Thanks again,
> > >> > > >> >> > >>> > >
> > >> > > >> >> > >>> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <
> > >> > > >> >> ctubbsii@apache.org>
> > >> > > >> >> > >>> wrote:
> > >> > > >> >> > >>> > >
> > >> > > >> >> > >>> > >> To add to Dave's answer, the public API is
> defined at
> > >> > > >> >> > >>> > >> https://accumulo.apache.org/api/
> > >> > > >> >> > >>> > >> Anything else is not public and is subject to
> change
> > >> > > without
> > >> > > >> >> notice
> > >> > > >> >> > >>> on
> > >> > > >> >> > >>> > >> any release without any attempt to retain
> > >> compatibility.
> > >> > > >> >> > >>> > >>
> > >> > > >> >> > >>> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <
> > >> > > >> >> dmarion18@gmail.com>
> > >> > > >> >> > >>> wrote:
> > >> > > >> >> > >>> > >> >
> > >> > > >> >> > >>> > >> > There is no guide. You are using implementation
> > >> classes
> > >> > > >> (see
> > >> > > >> >> > >>> clientImpl
> > >> > > >> >> > >>> > >> in
> > >> > > >> >> > >>> > >> > the package name) vs. using the client api. If
> you
> > >> can
> > >> > > use
> > >> > > >> >> the
> > >> > > >> >> > >>> client
> > >> > > >> >> > >>> > >> api
> > >> > > >> >> > >>> > >> > directly, then this should insulate you from
> > >> changes in
> > >> > > >> the
> > >> > > >> >> future
> > >> > > >> >> > >>> > >> (except
> > >> > > >> >> > >>> > >> > during major versions). We can try and find
> where
> > >> things
> > >> > > >> >> might
> > >> > > >> >> > >>> have
> > >> > > >> >> > >>> > >> moved,
> > >> > > >> >> > >>> > >> > but a class may have been split into multiple
> > >> pieces. If
> > >> > > >> you
> > >> > > >> >> could
> > >> > > >> >> > >>> > >> provide
> > >> > > >> >> > >>> > >> > class and method, that would be easier.
> > >> > > >> >> > >>> > >> >
> > >> > > >> >> > >>> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent
> Russell <
> > >> > > >> >> > >>> > >> vincent.russell@gmail.com>
> > >> > > >> >> > >>> > >> > wrote:
> > >> > > >> >> > >>> > >> >
> > >> > > >> >> > >>> > >> > > Is there a guide that shows where classes may
> > >> have
> > >> > > been
> > >> > > >> >> moved
> > >> > > >> >> > >>> with
> > >> > > >> >> > >>> > >> moving
> > >> > > >> >> > >>> > >> > > from 2.0 to 2.1?  For instance, I am having
> > >> issues
> > >> > > >> >> compiling,
> > >> > > >> >> > >>> because
> > >> > > >> >> > >>> > >> the
> > >> > > >> >> > >>> > >> > > following class doesn't exist:
> > >> > > >> >> > >>> > >> > > import
> > >> org.apache.accumulo.core.clientImpl.Tables;
> > >> > > >> >> > >>> > >> > >
> > >> > > >> >> > >>> > >> > > I'm just getting started so I'm sure there
> are
> > >> others.
> > >> > > >> >> > >>> > >> > >
> > >> > > >> >> > >>> > >> > > Thanks,
> > >> > > >> >> > >>> > >> > > Vincent
> > >> > > >> >> > >>> > >> > >
> > >> > > >> >> > >>> > >> > >
> > >> > > >> >> > >>> > >> > >
> > >> > > >> >> > >>> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent
> Russell <
> > >> > > >> >> > >>> > >> vincent.russell@gmail.com>
> > >> > > >> >> > >>> > >> > > wrote:
> > >> > > >> >> > >>> > >> > >
> > >> > > >> >> > >>> > >> > > > I mean Christopher.
> > >> > > >> >> > >>> > >> > > >
> > >> > > >> >> > >>> > >> > > > Thanks again.
> > >> > > >> >> > >>> > >> > > >
> > >> > > >> >> > >>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent
> Russell
> > >> <
> > >> > > >> >> > >>> > >> > > vincent.russell@gmail.com>
> > >> > > >> >> > >>> > >> > > > wrote:
> > >> > > >> >> > >>> > >> > > >
> > >> > > >> >> > >>> > >> > > >> Thank you Chris.
> > >> > > >> >> > >>> > >> > > >>
> > >> > > >> >> > >>> > >> > > >> Will will upgrade to Accumulo 2.1 and
> > >> ZooKeeper
> > >> > > 3.7
> > >> > > >> or
> > >> > > >> >> > >>> later as
> > >> > > >> >> > >>> > >> soon as
> > >> > > >> >> > >>> > >> > > >> possible.
> > >> > > >> >> > >>> > >> > > >>
> > >> > > >> >> > >>> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM
> Christopher <
> > >> > > >> >> > >>> ctubbsii@apache.org>
> > >> > > >> >> > >>> > >> wrote:
> > >> > > >> >> > >>> > >> > > >>
> > >> > > >> >> > >>> > >> > > >>> Hi Vincent,
> > >> > > >> >> > >>> > >> > > >>>
> > >> > > >> >> > >>> > >> > > >>> Version 2.0.1 is end of life as of the
> 2.1.0
> > >> LTM
> > >> > > >> >> release,
> > >> > > >> >> > >>> and 2.0
> > >> > > >> >> > >>> > >> is
> > >> > > >> >> > >>> > >> > > >>> not expected to receive any further
> updates.
> > >> > > Version
> > >> > > >> >> 2.1.0
> > >> > > >> >> > >>> may
> > >> > > >> >> > >>> > >> work
> > >> > > >> >> > >>> > >> > > >>> with ZooKeeper 3.4, but was developed and
> > >> tested
> > >> > > >> >> against
> > >> > > >> >> > >>> 3.5 and
> > >> > > >> >> > >>> > >> later
> > >> > > >> >> > >>> > >> > > >>> versions. I believe the ZooKeeper
> community
> > >> is
> > >> > > >> >> currently
> > >> > > >> >> > >>> > >> considering
> > >> > > >> >> > >>> > >> > > >>> whether to make 3.6 end-of-life
> themselves,
> > >> so I
> > >> > > >> would
> > >> > > >> >> > >>> recommend
> > >> > > >> >> > >>> > >> using
> > >> > > >> >> > >>> > >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper
> 3.7
> > >> or
> > >> > > >> later
> > >> > > >> >> to
> > >> > > >> >> > >>> have the
> > >> > > >> >> > >>> > >> best
> > >> > > >> >> > >>> > >> > > >>> chance of any kind of support, including
> JDK
> > >> 17
> > >> > > >> >> support.
> > >> > > >> >> > >>> > >> > > >>>
> > >> > > >> >> > >>> > >> > > >>> As for your specific issues:
> > >> > > >> >> > >>> > >> > > >>>
> > >> > > >> >> > >>> > >> > > >>> 1. This is already fixed in 2.1.0
> > >> > > >> >> > >>> > >> > > >>> 2/3. These issues are likely fixed in
> newer
> > >> > > >> ZooKeeper
> > >> > > >> >> > >>> versions. I
> > >> > > >> >> > >>> > >> > > >>> haven't seen them anytime recently,
> anyway.
> > >> Bugs
> > >> > > in
> > >> > > >> >> > >>> ZooKeeper
> > >> > > >> >> > >>> > >> itself
> > >> > > >> >> > >>> > >> > > >>> are out of scope for the Accumulo
> > >> developers, but
> > >> > > I
> > >> > > >> >> have
> > >> > > >> >> > >>> tried
> > >> > > >> >> > >>> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and
> > >> ZooKeeper
> > >> > > >> >> 3.8.0 and
> > >> > > >> >> > >>> > >> haven't
> > >> > > >> >> > >>> > >> > > >>> observed any unresolved issues. However,
> it's
> > >> > > >> >> difficult to
> > >> > > >> >> > >>> > >> actually
> > >> > > >> >> > >>> > >> > > >>> run it because I don't think Hadoop has
> good
> > >> JDK
> > >> > > 17
> > >> > > >> >> support
> > >> > > >> >> > >>> yet.
> > >> > > >> >> > >>> > >> So,
> > >> > > >> >> > >>> > >> > > >>> MiniAccumuloCluster seems to work with
> JDK
> > >> 17, as
> > >> > > >> does
> > >> > > >> >> > >>> Accumulo
> > >> > > >> >> > >>> > >> and ZK
> > >> > > >> >> > >>> > >> > > >>> 3.8, but I don't think a full Hadoop
> cluster
> > >> would
> > >> > > >> >> (yet).
> > >> > > >> >> > >>> > >> > > >>>
> > >> > > >> >> > >>> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent
> > >> Russell
> > >> > > >> >> > >>> > >> > > >>> <vi...@gmail.com> wrote:
> > >> > > >> >> > >>> > >> > > >>> >
> > >> > > >> >> > >>> > >> > > >>> > Hello,
> > >> > > >> >> > >>> > >> > > >>> >
> > >> > > >> >> > >>> > >> > > >>> > We are currently using accumulo 2.0.1.
> > >> > > >> >> > >>> > >> > > >>> >
> > >> > > >> >> > >>> > >> > > >>> > We are in the process of upgrading our
> > >> source
> > >> > > code
> > >> > > >> >> to use
> > >> > > >> >> > >>> jdk 17
> > >> > > >> >> > >>> > >> > > >>> however we
> > >> > > >> >> > >>> > >> > > >>> > are running into some problems with our
> > >> tests
> > >> > > and
> > >> > > >> the
> > >> > > >> >> > >>> > >> > > >>> MiniAccumuloCluster.
> > >> > > >> >> > >>> > >> > > >>> >
> > >> > > >> >> > >>> > >> > > >>> > One of our developer encountered the
> > >> following
> > >> > > >> >> issues:
> > >> > > >> >> > >>> > >> > > >>> >
> > >> > > >> >> > >>> > >> > > >>> >    1. The
> MiniAccumumluoClusterImpl._exec
> > >> is
> > >> > > >> >> hardcoded
> > >> > > >> >> > >>> with the
> > >> > > >> >> > >>> > >> JVM
> > >> > > >> >> > >>> > >> > > arg
> > >> > > >> >> > >>> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is
> no
> > >> longer
> > >> > > >> >> tolerated
> > >> > > >> >> > >>> with
> > >> > > >> >> > >>> > >> JDK17.
> > >> > > >> >> > >>> > >> > > >>> >    2. In Zookeeper 3.4.14,
> > >> ConetStringParser
> > >> > > uses
> > >> > > >> >> > >>> > >> createUnresolved to
> > >> > > >> >> > >>> > >> > > >>> >    make IPAddresses.
> > >> > > >> >> > >>> > >> > > >>>
> > >> > > >> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> > >> > > >> >> > >>> > >> > > >>> >    uses InetSocketAddess.getAddress,
> which
> > >> > > returns
> > >> > > >> >> null
> > >> > > >> >> > >>> because
> > >> > > >> >> > >>> > >> it's
> > >> > > >> >> > >>> > >> > > >>> not
> > >> > > >> >> > >>> > >> > > >>> >    resolved, resulting in a failure to
> > >> connect
> > >> > > to
> > >> > > >> the
> > >> > > >> >> > >>> > >> newly-started
> > >> > > >> >> > >>> > >> > > >>> zookeeper.
> > >> > > >> >> > >>> > >> > > >>> >    3.
> StaticHostProvider.getHostString()
> > >> tries
> > >> > > to
> > >> > > >> >> extract
> > >> > > >> >> > >>> he
> > >> > > >> >> > >>> > >> hostname
> > >> > > >> >> > >>> > >> > > >>> by
> > >> > > >> >> > >>> > >> > > >>> >    calling toString on the address and
> > >> taking
> > >> > > >> >> everything
> > >> > > >> >> > >>> before
> > >> > > >> >> > >>> > >> the
> > >> > > >> >> > >>> > >> > > >>> colon, but
> > >> > > >> >> > >>> > >> > > >>> >    in JDK17, the string format changed
> to
> > >> > > >> >> > >>> > >> > > "localhost/<unresolved->:xx"
> > >> > > >> >> > >>> > >> > > >>> (where
> > >> > > >> >> > >>> > >> > > >>> >    XX is still the port number).
> That's
> > >> > > incorrect
> > >> > > >> >> and it
> > >> > > >> >> > >>> can't
> > >> > > >> >> > >>> > >> > > >>> resolve the
> > >> > > >> >> > >>> > >> > > >>> >    names.
> > >> > > >> >> > >>> > >> > > >>> >
> > >> > > >> >> > >>> > >> > > >>> >
> > >> > > >> >> > >>> > >> > > >>> > Has anyone come across/resolved these
> > >> kinds of
> > >> > > >> >> issues?
> > >> > > >> >> > >>> Is it
> > >> > > >> >> > >>> > >> not
> > >> > > >> >> > >>> > >> > > >>> possible
> > >> > > >> >> > >>> > >> > > >>> > to use java17 from a client
> perspective?
> > >> Will
> > >> > > >> >> upgrading
> > >> > > >> >> > >>> to
> > >> > > >> >> > >>> > >> accumulo
> > >> > > >> >> > >>> > >> > > >>> 2.1
> > >> > > >> >> > >>> > >> > > >>> > help?
> > >> > > >> >> > >>> > >> > > >>> >
> > >> > > >> >> > >>> > >> > > >>> > Thanks,
> > >> > > >> >> > >>> > >> > > >>> > Vincent
> > >> > > >> >> > >>> > >> > > >>>
> > >> > > >> >> > >>> > >> > > >>
> > >> > > >> >> > >>> > >> > >
> > >> > > >> >> > >>> > >>
> > >> > > >> >> > >>> > >
> > >> > > >> >> > >>>
> > >> > > >> >> > >>
> > >> > > >> >>
> > >> > > >> >
> > >> > > >>
> > >> > > >
> > >> > >
> > >>
> > >
>

Re: jdk 17 and accumulo testing

Posted by Christopher <ct...@apache.org>.
There's a few outstanding issues. Notably, the issue mentioned on
https://github.com/apache/accumulo/issues/3346
There's also ensuring some stuff is marked as deprecated in 2.1.1 that
is mentioned in
https://github.com/apache/accumulo/pull/3265#discussion_r1177315428
(but that's really minor).

The project tracker is at
https://github.com/apache/accumulo/projects/25 and there's a few
things in flight.

I'm bad at estimating time (there was a time I thought we'd have 3.0
out in December 2022 and I thought we'd have 2.1.1 sometime around
February). Technically, we could put together a release candidate now,
but if it doesn't include some important things, we'll want to do
anther one right away, and that rapid churn is tiring for both devs
and users. I would watch #3346, as that seems to be the most critical
issue right now. Once that's figured out, releasing should be able to
follow shortly after.

I'm curious if the issue addressed in
https://github.com/apache/accumulo/pull/3134 actually fixes your
issue. Have you tried a recent snapshot version to see if the problem
is fixed for you? I looked for, but didn't see, any comment from you
about that.

On Fri, Apr 28, 2023 at 7:07 AM Vincent Russell
<vi...@gmail.com> wrote:
>
> Hello,
>
> Just checking in on if there is a timeframe for 2.1.1.
>
> This has been delaying our upgrade to jdk 17 for almost 5 month now.
>
>
> Thanks,
> Vincent
>
>
>
> On Fri, Dec 30, 2022, 12:57 PM Vincent Russell <vi...@gmail.com>
> wrote:
>
> > Ok.. Thank you for the update.
> >
> > On Fri, Dec 30, 2022 at 11:55 AM Christopher <ct...@apache.org> wrote:
> >
> >> For reference, here's the PR working on the fix for 2.1.1:
> >> https://github.com/apache/accumulo/pull/3134
> >>
> >> On Fri, Dec 30, 2022 at 11:39 AM Christopher Shannon
> >> <ch...@gmail.com> wrote:
> >> >
> >> > Version 2.1.1 will be released with bug fixes and this fix (when
> >> finished
> >> > and merged) is planned to be included as part of that release. I don't
> >> know
> >> > the exact time frame yet though.
> >> >
> >> > On Fri, Dec 30, 2022 at 11:04 AM Vincent Russell <
> >> vincent.russell@gmail.com>
> >> > wrote:
> >> >
> >> > > Hello,
> >> > >
> >> > > Are there any plans to release an accumulo 2.1 patch to fix this
> >> issue?
> >> > >
> >> > > Thanks,
> >> > >
> >> > > On Sat, Dec 17, 2022 at 7:36 PM Vincent Russell <
> >> vincent.russell@gmail.com
> >> > > >
> >> > > wrote:
> >> > >
> >> > > > No worries.  I'm glad I was able to help in some small way.
> >> > > >
> >> > > > Thank you for fixing the issue.
> >> > > >
> >> > > > On Sat, Dec 17, 2022 at 11:49 AM Christopher Shannon <
> >> > > > christopher.l.shannon@gmail.com> wrote:
> >> > > >
> >> > > >> I created https://github.com/apache/accumulo/pull/3134 and that
> >> should
> >> > > >> fix
> >> > > >> this issue.
> >> > > >>
> >> > > >> Thanks Vincent for pointing out the issue in TServerUtils, your
> >> testing
> >> > > >> made this easy to track down and fix.
> >> > > >>
> >> > > >>
> >> > > >> On Sat, Dec 17, 2022 at 9:00 AM Christopher Shannon <
> >> > > >> christopher.l.shannon@gmail.com> wrote:
> >> > > >>
> >> > > >> > I was able to reproduce the issue by setting the value size for a
> >> > > >> mutation
> >> > > >> > to size 16384001 to make sure it's greater than the default
> >> value for
> >> > > >> > Thrift and it fails immediately. I will work on a fix now that
> >> we know
> >> > > >> how
> >> > > >> > to reproduce it.
> >> > > >> >
> >> > > >> > On Fri, Dec 16, 2022 at 2:31 PM Christopher <ctubbsii@apache.org
> >> >
> >> > > >> wrote:
> >> > > >> >
> >> > > >> >> I don't think it's intentional. This might be the source of the
> >> > > >> problem.
> >> > > >> >>
> >> > > >> >> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
> >> > > >> >> <vi...@gmail.com> wrote:
> >> > > >> >> >
> >> > > >> >> > Also in TserverUtils:270, when the TNonblockingServerSocket is
> >> > > >> created
> >> > > >> >> it
> >> > > >> >> > looks like it ends up using the default frame size.  I am not
> >> sure
> >> > > if
> >> > > >> >> this
> >> > > >> >> > is intentional or not.
> >> > > >> >> >
> >> > > >> >> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
> >> > > >> >> vincent.russell@gmail.com>
> >> > > >> >> > wrote:
> >> > > >> >> >
> >> > > >> >> > > Christopher,
> >> > > >> >> > >
> >> > > >> >> > > I am not sure if this issue is related to 3042 or not.
> >> > > >> >> > >
> >> > > >> >> > > On the client side it does look like TConfiguration ends up
> >> being
> >> > > >> >> called
> >> > > >> >> > > with the default constructor.  I am not sure if this is
> >> > > intentional
> >> > > >> >> or not.
> >> > > >> >> > >
> >> > > >> >> > > On the server side I see this stack, so it also looks like:
> >> > > >> >> > >
> >> > > >> >> > > at
> >> > > org.apache.thrift.TConfiguration.<init>(TConfiguration.java:36)
> >> > > >> >> > > at
> >> > > >> >>
> >> > > org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
> >> > > >> >> > > at
> >> > > >> org.apache.thrift.TConfiguration.<clinit>(TConfiguration.java:65)
> >> > > >> >> > > at
> >> > > >> >> > >
> >> > > >> >>
> >> > > >>
> >> > >
> >> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:74)
> >> > > >> >> > > at
> >> > > >> >> > >
> >> > > >> >>
> >> > > >>
> >> > >
> >> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:68)
> >> > > >> >> > > at
> >> > > >> >> > >
> >> > > >> >>
> >> > > >>
> >> > >
> >> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
> >> > > >> >> > > at
> >> > > >> >> > >
> >> > > >> >>
> >> > > >>
> >> > >
> >> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
> >> > > >> >> > > at
> >> > > >> >> > >
> >> > > >> >>
> >> > > >>
> >> > >
> >> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
> >> > > >> >> > > at
> >> > > >> >> > >
> >> > > >> >>
> >> > > >>
> >> > >
> >> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
> >> > > >> >> > > at
> >> > > >> >> > >
> >> > > >> >>
> >> > > >>
> >> > >
> >> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> >> > > >> >> > >
> >> > > >> >> > >
> >> > > >> >> > > I see this in the server log so it does look like it should
> >> be
> >> > > >> using
> >> > > >> >> 1G:
> >> > > >> >> > > 2022-09-01 16:59:41 INFO
> >> > > >> [org.apache.accumulo.tserver.TabletServer]
> >> > > >> >> > > ServerUtil:124 - general.server.message.size.max = 1G
> >> > > >> >> > >
> >> > > >> >> > > Thanks,
> >> > > >> >> > > Vincent
> >> > > >> >> > >
> >> > > >> >> > > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
> >> > > >> >> > > vincent.russell@gmail.com> wrote:
> >> > > >> >> > >
> >> > > >> >> > >>
> >> > > >> >> > >>
> >> > > >> >> > >> I had to make a stack trace with hacking together a remote
> >> debug
> >> > > >> >> instance:
> >> > > >> >> > >>
> >> > > >> >> > >> at
> >> > > >> >> > >>
> >> > > >> >>
> >> > > >>
> >> > >
> >> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
> >> > > >> >> > >> at
> >> > > >> >> > >>
> >> > > >> >>
> >> > > >>
> >> > >
> >> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
> >> > > >> >> > >> at
> >> > > >> >> > >>
> >> > > >> >>
> >> > > >>
> >> > >
> >> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
> >> > > >> >> > >> at
> >> > > >> >> > >>
> >> > > >> >>
> >> > > >>
> >> > >
> >> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
> >> > > >> >> > >> at
> >> > > >> >> > >>
> >> > > >> >>
> >> > > >>
> >> > >
> >> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> >> > > >> >> > >>
> >> > > >> >> > >> On Thu, Dec 15, 2022 at 12:52 AM Christopher <
> >> > > ctubbsii@apache.org
> >> > > >> >
> >> > > >> >> wrote:
> >> > > >> >> > >>
> >> > > >> >> > >>> From the numbers in the message, it looks like you're
> >> sending
> >> > > an
> >> > > >> >> 18MB
> >> > > >> >> > >>> payload but something in Thrift is limiting things to
> >> 16384000
> >> > > >> >> > >>> (16000KB). I doubt you've overridden the default
> >> > > >> >> > >>> general.server.message.size.max to be anything that low
> >> (the
> >> > > >> default
> >> > > >> >> > >>> is 1G). Unless you're flushing after every mutation, it
> >> would
> >> > > >> not be
> >> > > >> >> > >>> surprising to exceed the 16MB max frame size indicated in
> >> the
> >> > > >> error
> >> > > >> >> > >>> message quite quickly.
> >> > > >> >> > >>>
> >> > > >> >> > >>> This value of 16384000 seemed weird. It looks like it's
> >> not
> >> > > using
> >> > > >> >> our
> >> > > >> >> > >>> configuration, but using the built-in default value of
> >> > > >> >> > >>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE.
> >> It
> >> > > looks
> >> > > >> >> like
> >> > > >> >> > >>> this can happen whenever `new TConfiguration()` is called
> >> > > without
> >> > > >> >> > >>> parameters... and there's a fair amount of internal code,
> >> > > mostly
> >> > > >> in
> >> > > >> >> > >>> libthrift itself, that does that. It's a bit tricky to
> >> track
> >> > > down
> >> > > >> >> the
> >> > > >> >> > >>> one causing this particular issue. If you have a full
> >> stack
> >> > > >> trace,
> >> > > >> >> it
> >> > > >> >> > >>> could help.
> >> > > >> >> > >>>
> >> > > >> >> > >>> Also, this might be the same issue seen reported in
> >> > > >> >> > >>> https://github.com/apache/accumulo/issues/3042
> >> > > >> >> > >>>
> >> > > >> >> > >>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
> >> > > >> >> > >>> <vi...@gmail.com> wrote:
> >> > > >> >> > >>> >
> >> > > >> >> > >>> > I was able to work out all of my compilation issues;
> >> however
> >> > > >> when
> >> > > >> >> I
> >> > > >> >> > >>> run an
> >> > > >> >> > >>> > integration test with the Mini Accumulo Cluster that
> >> tests
> >> > > >> writing
> >> > > >> >> > >>> > mutations with values of 5mb the flush hangs forever
> >> > > >> >> > >>> > and I see  the following logs in the TabletServer logs:
> >> > > >> >> > >>> >
> >> > > >> >> > >>> > 20:41:02.306 [Thread-7] ERROR
> >> > > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer -
> >> Read a
> >> > > >> frame
> >> > > >> >> > >>> size of
> >> > > >> >> > >>> > 18874697, which is bigger than the maximum allowable
> >> frame
> >> > > size
> >> > > >> >> > >>> 16384000
> >> > > >> >> > >>> > for ALL connections.
> >> > > >> >> > >>> > 20:41:03.582 [Thread-7] ERROR
> >> > > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer -
> >> Read a
> >> > > >> frame
> >> > > >> >> > >>> size of
> >> > > >> >> > >>> > 18874697, which is bigger than the maximum allowable
> >> frame
> >> > > size
> >> > > >> >> > >>> 16384000
> >> > > >> >> > >>> > for ALL connections.
> >> > > >> >> > >>> > 20:41:05.079 [Thread-7] ERROR
> >> > > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer -
> >> Read a
> >> > > >> frame
> >> > > >> >> > >>> size of
> >> > > >> >> > >>> > 18874697, which is bigger than the maximum allowable
> >> frame
> >> > > size
> >> > > >> >> > >>> 16384000
> >> > > >> >> > >>> > for ALL connections.
> >> > > >> >> > >>> >
> >> > > >> >> > >>> > Other tests that write smaller amounts of data appear
> >> to work
> >> > > >> >> fine.
> >> > > >> >> > >>> >
> >> > > >> >> > >>> > Any idea what the issue might be?
> >> > > >> >> > >>> >
> >> > > >> >> > >>> > Thank you,
> >> > > >> >> > >>> > Vincent
> >> > > >> >> > >>> >
> >> > > >> >> > >>> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
> >> > > >> >> > >>> vincent.russell@gmail.com>
> >> > > >> >> > >>> > wrote:
> >> > > >> >> > >>> >
> >> > > >> >> > >>> > > Thank you both for your responses.
> >> > > >> >> > >>> > >
> >> > > >> >> > >>> > > We are using an event store library from a sister
> >> project
> >> > > >> that
> >> > > >> >> was
> >> > > >> >> > >>> written
> >> > > >> >> > >>> > > for accumulo 1.10., which I have already upgraded to
> >> 2.0.
> >> > > >> >> > >>> > >
> >> > > >> >> > >>> > > I'll spend some time investigating how bad the usage
> >> of the
> >> > > >> >> internal
> >> > > >> >> > >>> > > packages are and get back to you.
> >> > > >> >> > >>> > >
> >> > > >> >> > >>> > > Thanks again,
> >> > > >> >> > >>> > >
> >> > > >> >> > >>> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <
> >> > > >> >> ctubbsii@apache.org>
> >> > > >> >> > >>> wrote:
> >> > > >> >> > >>> > >
> >> > > >> >> > >>> > >> To add to Dave's answer, the public API is defined at
> >> > > >> >> > >>> > >> https://accumulo.apache.org/api/
> >> > > >> >> > >>> > >> Anything else is not public and is subject to change
> >> > > without
> >> > > >> >> notice
> >> > > >> >> > >>> on
> >> > > >> >> > >>> > >> any release without any attempt to retain
> >> compatibility.
> >> > > >> >> > >>> > >>
> >> > > >> >> > >>> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <
> >> > > >> >> dmarion18@gmail.com>
> >> > > >> >> > >>> wrote:
> >> > > >> >> > >>> > >> >
> >> > > >> >> > >>> > >> > There is no guide. You are using implementation
> >> classes
> >> > > >> (see
> >> > > >> >> > >>> clientImpl
> >> > > >> >> > >>> > >> in
> >> > > >> >> > >>> > >> > the package name) vs. using the client api. If you
> >> can
> >> > > use
> >> > > >> >> the
> >> > > >> >> > >>> client
> >> > > >> >> > >>> > >> api
> >> > > >> >> > >>> > >> > directly, then this should insulate you from
> >> changes in
> >> > > >> the
> >> > > >> >> future
> >> > > >> >> > >>> > >> (except
> >> > > >> >> > >>> > >> > during major versions). We can try and find where
> >> things
> >> > > >> >> might
> >> > > >> >> > >>> have
> >> > > >> >> > >>> > >> moved,
> >> > > >> >> > >>> > >> > but a class may have been split into multiple
> >> pieces. If
> >> > > >> you
> >> > > >> >> could
> >> > > >> >> > >>> > >> provide
> >> > > >> >> > >>> > >> > class and method, that would be easier.
> >> > > >> >> > >>> > >> >
> >> > > >> >> > >>> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
> >> > > >> >> > >>> > >> vincent.russell@gmail.com>
> >> > > >> >> > >>> > >> > wrote:
> >> > > >> >> > >>> > >> >
> >> > > >> >> > >>> > >> > > Is there a guide that shows where classes may
> >> have
> >> > > been
> >> > > >> >> moved
> >> > > >> >> > >>> with
> >> > > >> >> > >>> > >> moving
> >> > > >> >> > >>> > >> > > from 2.0 to 2.1?  For instance, I am having
> >> issues
> >> > > >> >> compiling,
> >> > > >> >> > >>> because
> >> > > >> >> > >>> > >> the
> >> > > >> >> > >>> > >> > > following class doesn't exist:
> >> > > >> >> > >>> > >> > > import
> >> org.apache.accumulo.core.clientImpl.Tables;
> >> > > >> >> > >>> > >> > >
> >> > > >> >> > >>> > >> > > I'm just getting started so I'm sure there are
> >> others.
> >> > > >> >> > >>> > >> > >
> >> > > >> >> > >>> > >> > > Thanks,
> >> > > >> >> > >>> > >> > > Vincent
> >> > > >> >> > >>> > >> > >
> >> > > >> >> > >>> > >> > >
> >> > > >> >> > >>> > >> > >
> >> > > >> >> > >>> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
> >> > > >> >> > >>> > >> vincent.russell@gmail.com>
> >> > > >> >> > >>> > >> > > wrote:
> >> > > >> >> > >>> > >> > >
> >> > > >> >> > >>> > >> > > > I mean Christopher.
> >> > > >> >> > >>> > >> > > >
> >> > > >> >> > >>> > >> > > > Thanks again.
> >> > > >> >> > >>> > >> > > >
> >> > > >> >> > >>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell
> >> <
> >> > > >> >> > >>> > >> > > vincent.russell@gmail.com>
> >> > > >> >> > >>> > >> > > > wrote:
> >> > > >> >> > >>> > >> > > >
> >> > > >> >> > >>> > >> > > >> Thank you Chris.
> >> > > >> >> > >>> > >> > > >>
> >> > > >> >> > >>> > >> > > >> Will will upgrade to Accumulo 2.1 and
> >> ZooKeeper
> >> > > 3.7
> >> > > >> or
> >> > > >> >> > >>> later as
> >> > > >> >> > >>> > >> soon as
> >> > > >> >> > >>> > >> > > >> possible.
> >> > > >> >> > >>> > >> > > >>
> >> > > >> >> > >>> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <
> >> > > >> >> > >>> ctubbsii@apache.org>
> >> > > >> >> > >>> > >> wrote:
> >> > > >> >> > >>> > >> > > >>
> >> > > >> >> > >>> > >> > > >>> Hi Vincent,
> >> > > >> >> > >>> > >> > > >>>
> >> > > >> >> > >>> > >> > > >>> Version 2.0.1 is end of life as of the 2.1.0
> >> LTM
> >> > > >> >> release,
> >> > > >> >> > >>> and 2.0
> >> > > >> >> > >>> > >> is
> >> > > >> >> > >>> > >> > > >>> not expected to receive any further updates.
> >> > > Version
> >> > > >> >> 2.1.0
> >> > > >> >> > >>> may
> >> > > >> >> > >>> > >> work
> >> > > >> >> > >>> > >> > > >>> with ZooKeeper 3.4, but was developed and
> >> tested
> >> > > >> >> against
> >> > > >> >> > >>> 3.5 and
> >> > > >> >> > >>> > >> later
> >> > > >> >> > >>> > >> > > >>> versions. I believe the ZooKeeper community
> >> is
> >> > > >> >> currently
> >> > > >> >> > >>> > >> considering
> >> > > >> >> > >>> > >> > > >>> whether to make 3.6 end-of-life themselves,
> >> so I
> >> > > >> would
> >> > > >> >> > >>> recommend
> >> > > >> >> > >>> > >> using
> >> > > >> >> > >>> > >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7
> >> or
> >> > > >> later
> >> > > >> >> to
> >> > > >> >> > >>> have the
> >> > > >> >> > >>> > >> best
> >> > > >> >> > >>> > >> > > >>> chance of any kind of support, including JDK
> >> 17
> >> > > >> >> support.
> >> > > >> >> > >>> > >> > > >>>
> >> > > >> >> > >>> > >> > > >>> As for your specific issues:
> >> > > >> >> > >>> > >> > > >>>
> >> > > >> >> > >>> > >> > > >>> 1. This is already fixed in 2.1.0
> >> > > >> >> > >>> > >> > > >>> 2/3. These issues are likely fixed in newer
> >> > > >> ZooKeeper
> >> > > >> >> > >>> versions. I
> >> > > >> >> > >>> > >> > > >>> haven't seen them anytime recently, anyway.
> >> Bugs
> >> > > in
> >> > > >> >> > >>> ZooKeeper
> >> > > >> >> > >>> > >> itself
> >> > > >> >> > >>> > >> > > >>> are out of scope for the Accumulo
> >> developers, but
> >> > > I
> >> > > >> >> have
> >> > > >> >> > >>> tried
> >> > > >> >> > >>> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and
> >> ZooKeeper
> >> > > >> >> 3.8.0 and
> >> > > >> >> > >>> > >> haven't
> >> > > >> >> > >>> > >> > > >>> observed any unresolved issues. However, it's
> >> > > >> >> difficult to
> >> > > >> >> > >>> > >> actually
> >> > > >> >> > >>> > >> > > >>> run it because I don't think Hadoop has good
> >> JDK
> >> > > 17
> >> > > >> >> support
> >> > > >> >> > >>> yet.
> >> > > >> >> > >>> > >> So,
> >> > > >> >> > >>> > >> > > >>> MiniAccumuloCluster seems to work with JDK
> >> 17, as
> >> > > >> does
> >> > > >> >> > >>> Accumulo
> >> > > >> >> > >>> > >> and ZK
> >> > > >> >> > >>> > >> > > >>> 3.8, but I don't think a full Hadoop cluster
> >> would
> >> > > >> >> (yet).
> >> > > >> >> > >>> > >> > > >>>
> >> > > >> >> > >>> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent
> >> Russell
> >> > > >> >> > >>> > >> > > >>> <vi...@gmail.com> wrote:
> >> > > >> >> > >>> > >> > > >>> >
> >> > > >> >> > >>> > >> > > >>> > Hello,
> >> > > >> >> > >>> > >> > > >>> >
> >> > > >> >> > >>> > >> > > >>> > We are currently using accumulo 2.0.1.
> >> > > >> >> > >>> > >> > > >>> >
> >> > > >> >> > >>> > >> > > >>> > We are in the process of upgrading our
> >> source
> >> > > code
> >> > > >> >> to use
> >> > > >> >> > >>> jdk 17
> >> > > >> >> > >>> > >> > > >>> however we
> >> > > >> >> > >>> > >> > > >>> > are running into some problems with our
> >> tests
> >> > > and
> >> > > >> the
> >> > > >> >> > >>> > >> > > >>> MiniAccumuloCluster.
> >> > > >> >> > >>> > >> > > >>> >
> >> > > >> >> > >>> > >> > > >>> > One of our developer encountered the
> >> following
> >> > > >> >> issues:
> >> > > >> >> > >>> > >> > > >>> >
> >> > > >> >> > >>> > >> > > >>> >    1. The MiniAccumumluoClusterImpl._exec
> >> is
> >> > > >> >> hardcoded
> >> > > >> >> > >>> with the
> >> > > >> >> > >>> > >> JVM
> >> > > >> >> > >>> > >> > > arg
> >> > > >> >> > >>> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no
> >> longer
> >> > > >> >> tolerated
> >> > > >> >> > >>> with
> >> > > >> >> > >>> > >> JDK17.
> >> > > >> >> > >>> > >> > > >>> >    2. In Zookeeper 3.4.14,
> >> ConetStringParser
> >> > > uses
> >> > > >> >> > >>> > >> createUnresolved to
> >> > > >> >> > >>> > >> > > >>> >    make IPAddresses.
> >> > > >> >> > >>> > >> > > >>>
> >> > > >> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> >> > > >> >> > >>> > >> > > >>> >    uses InetSocketAddess.getAddress, which
> >> > > returns
> >> > > >> >> null
> >> > > >> >> > >>> because
> >> > > >> >> > >>> > >> it's
> >> > > >> >> > >>> > >> > > >>> not
> >> > > >> >> > >>> > >> > > >>> >    resolved, resulting in a failure to
> >> connect
> >> > > to
> >> > > >> the
> >> > > >> >> > >>> > >> newly-started
> >> > > >> >> > >>> > >> > > >>> zookeeper.
> >> > > >> >> > >>> > >> > > >>> >    3. StaticHostProvider.getHostString()
> >> tries
> >> > > to
> >> > > >> >> extract
> >> > > >> >> > >>> he
> >> > > >> >> > >>> > >> hostname
> >> > > >> >> > >>> > >> > > >>> by
> >> > > >> >> > >>> > >> > > >>> >    calling toString on the address and
> >> taking
> >> > > >> >> everything
> >> > > >> >> > >>> before
> >> > > >> >> > >>> > >> the
> >> > > >> >> > >>> > >> > > >>> colon, but
> >> > > >> >> > >>> > >> > > >>> >    in JDK17, the string format changed to
> >> > > >> >> > >>> > >> > > "localhost/<unresolved->:xx"
> >> > > >> >> > >>> > >> > > >>> (where
> >> > > >> >> > >>> > >> > > >>> >    XX is still the port number).  That's
> >> > > incorrect
> >> > > >> >> and it
> >> > > >> >> > >>> can't
> >> > > >> >> > >>> > >> > > >>> resolve the
> >> > > >> >> > >>> > >> > > >>> >    names.
> >> > > >> >> > >>> > >> > > >>> >
> >> > > >> >> > >>> > >> > > >>> >
> >> > > >> >> > >>> > >> > > >>> > Has anyone come across/resolved these
> >> kinds of
> >> > > >> >> issues?
> >> > > >> >> > >>> Is it
> >> > > >> >> > >>> > >> not
> >> > > >> >> > >>> > >> > > >>> possible
> >> > > >> >> > >>> > >> > > >>> > to use java17 from a client perspective?
> >> Will
> >> > > >> >> upgrading
> >> > > >> >> > >>> to
> >> > > >> >> > >>> > >> accumulo
> >> > > >> >> > >>> > >> > > >>> 2.1
> >> > > >> >> > >>> > >> > > >>> > help?
> >> > > >> >> > >>> > >> > > >>> >
> >> > > >> >> > >>> > >> > > >>> > Thanks,
> >> > > >> >> > >>> > >> > > >>> > Vincent
> >> > > >> >> > >>> > >> > > >>>
> >> > > >> >> > >>> > >> > > >>
> >> > > >> >> > >>> > >> > >
> >> > > >> >> > >>> > >>
> >> > > >> >> > >>> > >
> >> > > >> >> > >>>
> >> > > >> >> > >>
> >> > > >> >>
> >> > > >> >
> >> > > >>
> >> > > >
> >> > >
> >>
> >

Re: jdk 17 and accumulo testing

Posted by Vincent Russell <vi...@gmail.com>.
Hello,

Just checking in on if there is a timeframe for 2.1.1.

This has been delaying our upgrade to jdk 17 for almost 5 month now.


Thanks,
Vincent



On Fri, Dec 30, 2022, 12:57 PM Vincent Russell <vi...@gmail.com>
wrote:

> Ok.. Thank you for the update.
>
> On Fri, Dec 30, 2022 at 11:55 AM Christopher <ct...@apache.org> wrote:
>
>> For reference, here's the PR working on the fix for 2.1.1:
>> https://github.com/apache/accumulo/pull/3134
>>
>> On Fri, Dec 30, 2022 at 11:39 AM Christopher Shannon
>> <ch...@gmail.com> wrote:
>> >
>> > Version 2.1.1 will be released with bug fixes and this fix (when
>> finished
>> > and merged) is planned to be included as part of that release. I don't
>> know
>> > the exact time frame yet though.
>> >
>> > On Fri, Dec 30, 2022 at 11:04 AM Vincent Russell <
>> vincent.russell@gmail.com>
>> > wrote:
>> >
>> > > Hello,
>> > >
>> > > Are there any plans to release an accumulo 2.1 patch to fix this
>> issue?
>> > >
>> > > Thanks,
>> > >
>> > > On Sat, Dec 17, 2022 at 7:36 PM Vincent Russell <
>> vincent.russell@gmail.com
>> > > >
>> > > wrote:
>> > >
>> > > > No worries.  I'm glad I was able to help in some small way.
>> > > >
>> > > > Thank you for fixing the issue.
>> > > >
>> > > > On Sat, Dec 17, 2022 at 11:49 AM Christopher Shannon <
>> > > > christopher.l.shannon@gmail.com> wrote:
>> > > >
>> > > >> I created https://github.com/apache/accumulo/pull/3134 and that
>> should
>> > > >> fix
>> > > >> this issue.
>> > > >>
>> > > >> Thanks Vincent for pointing out the issue in TServerUtils, your
>> testing
>> > > >> made this easy to track down and fix.
>> > > >>
>> > > >>
>> > > >> On Sat, Dec 17, 2022 at 9:00 AM Christopher Shannon <
>> > > >> christopher.l.shannon@gmail.com> wrote:
>> > > >>
>> > > >> > I was able to reproduce the issue by setting the value size for a
>> > > >> mutation
>> > > >> > to size 16384001 to make sure it's greater than the default
>> value for
>> > > >> > Thrift and it fails immediately. I will work on a fix now that
>> we know
>> > > >> how
>> > > >> > to reproduce it.
>> > > >> >
>> > > >> > On Fri, Dec 16, 2022 at 2:31 PM Christopher <ctubbsii@apache.org
>> >
>> > > >> wrote:
>> > > >> >
>> > > >> >> I don't think it's intentional. This might be the source of the
>> > > >> problem.
>> > > >> >>
>> > > >> >> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
>> > > >> >> <vi...@gmail.com> wrote:
>> > > >> >> >
>> > > >> >> > Also in TserverUtils:270, when the TNonblockingServerSocket is
>> > > >> created
>> > > >> >> it
>> > > >> >> > looks like it ends up using the default frame size.  I am not
>> sure
>> > > if
>> > > >> >> this
>> > > >> >> > is intentional or not.
>> > > >> >> >
>> > > >> >> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
>> > > >> >> vincent.russell@gmail.com>
>> > > >> >> > wrote:
>> > > >> >> >
>> > > >> >> > > Christopher,
>> > > >> >> > >
>> > > >> >> > > I am not sure if this issue is related to 3042 or not.
>> > > >> >> > >
>> > > >> >> > > On the client side it does look like TConfiguration ends up
>> being
>> > > >> >> called
>> > > >> >> > > with the default constructor.  I am not sure if this is
>> > > intentional
>> > > >> >> or not.
>> > > >> >> > >
>> > > >> >> > > On the server side I see this stack, so it also looks like:
>> > > >> >> > >
>> > > >> >> > > at
>> > > org.apache.thrift.TConfiguration.<init>(TConfiguration.java:36)
>> > > >> >> > > at
>> > > >> >>
>> > > org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
>> > > >> >> > > at
>> > > >> org.apache.thrift.TConfiguration.<clinit>(TConfiguration.java:65)
>> > > >> >> > > at
>> > > >> >> > >
>> > > >> >>
>> > > >>
>> > >
>> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:74)
>> > > >> >> > > at
>> > > >> >> > >
>> > > >> >>
>> > > >>
>> > >
>> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:68)
>> > > >> >> > > at
>> > > >> >> > >
>> > > >> >>
>> > > >>
>> > >
>> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
>> > > >> >> > > at
>> > > >> >> > >
>> > > >> >>
>> > > >>
>> > >
>> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
>> > > >> >> > > at
>> > > >> >> > >
>> > > >> >>
>> > > >>
>> > >
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
>> > > >> >> > > at
>> > > >> >> > >
>> > > >> >>
>> > > >>
>> > >
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
>> > > >> >> > > at
>> > > >> >> > >
>> > > >> >>
>> > > >>
>> > >
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
>> > > >> >> > >
>> > > >> >> > >
>> > > >> >> > > I see this in the server log so it does look like it should
>> be
>> > > >> using
>> > > >> >> 1G:
>> > > >> >> > > 2022-09-01 16:59:41 INFO
>> > > >> [org.apache.accumulo.tserver.TabletServer]
>> > > >> >> > > ServerUtil:124 - general.server.message.size.max = 1G
>> > > >> >> > >
>> > > >> >> > > Thanks,
>> > > >> >> > > Vincent
>> > > >> >> > >
>> > > >> >> > > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
>> > > >> >> > > vincent.russell@gmail.com> wrote:
>> > > >> >> > >
>> > > >> >> > >>
>> > > >> >> > >>
>> > > >> >> > >> I had to make a stack trace with hacking together a remote
>> debug
>> > > >> >> instance:
>> > > >> >> > >>
>> > > >> >> > >> at
>> > > >> >> > >>
>> > > >> >>
>> > > >>
>> > >
>> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
>> > > >> >> > >> at
>> > > >> >> > >>
>> > > >> >>
>> > > >>
>> > >
>> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
>> > > >> >> > >> at
>> > > >> >> > >>
>> > > >> >>
>> > > >>
>> > >
>> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
>> > > >> >> > >> at
>> > > >> >> > >>
>> > > >> >>
>> > > >>
>> > >
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
>> > > >> >> > >> at
>> > > >> >> > >>
>> > > >> >>
>> > > >>
>> > >
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
>> > > >> >> > >>
>> > > >> >> > >> On Thu, Dec 15, 2022 at 12:52 AM Christopher <
>> > > ctubbsii@apache.org
>> > > >> >
>> > > >> >> wrote:
>> > > >> >> > >>
>> > > >> >> > >>> From the numbers in the message, it looks like you're
>> sending
>> > > an
>> > > >> >> 18MB
>> > > >> >> > >>> payload but something in Thrift is limiting things to
>> 16384000
>> > > >> >> > >>> (16000KB). I doubt you've overridden the default
>> > > >> >> > >>> general.server.message.size.max to be anything that low
>> (the
>> > > >> default
>> > > >> >> > >>> is 1G). Unless you're flushing after every mutation, it
>> would
>> > > >> not be
>> > > >> >> > >>> surprising to exceed the 16MB max frame size indicated in
>> the
>> > > >> error
>> > > >> >> > >>> message quite quickly.
>> > > >> >> > >>>
>> > > >> >> > >>> This value of 16384000 seemed weird. It looks like it's
>> not
>> > > using
>> > > >> >> our
>> > > >> >> > >>> configuration, but using the built-in default value of
>> > > >> >> > >>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE.
>> It
>> > > looks
>> > > >> >> like
>> > > >> >> > >>> this can happen whenever `new TConfiguration()` is called
>> > > without
>> > > >> >> > >>> parameters... and there's a fair amount of internal code,
>> > > mostly
>> > > >> in
>> > > >> >> > >>> libthrift itself, that does that. It's a bit tricky to
>> track
>> > > down
>> > > >> >> the
>> > > >> >> > >>> one causing this particular issue. If you have a full
>> stack
>> > > >> trace,
>> > > >> >> it
>> > > >> >> > >>> could help.
>> > > >> >> > >>>
>> > > >> >> > >>> Also, this might be the same issue seen reported in
>> > > >> >> > >>> https://github.com/apache/accumulo/issues/3042
>> > > >> >> > >>>
>> > > >> >> > >>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
>> > > >> >> > >>> <vi...@gmail.com> wrote:
>> > > >> >> > >>> >
>> > > >> >> > >>> > I was able to work out all of my compilation issues;
>> however
>> > > >> when
>> > > >> >> I
>> > > >> >> > >>> run an
>> > > >> >> > >>> > integration test with the Mini Accumulo Cluster that
>> tests
>> > > >> writing
>> > > >> >> > >>> > mutations with values of 5mb the flush hangs forever
>> > > >> >> > >>> > and I see  the following logs in the TabletServer logs:
>> > > >> >> > >>> >
>> > > >> >> > >>> > 20:41:02.306 [Thread-7] ERROR
>> > > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer -
>> Read a
>> > > >> frame
>> > > >> >> > >>> size of
>> > > >> >> > >>> > 18874697, which is bigger than the maximum allowable
>> frame
>> > > size
>> > > >> >> > >>> 16384000
>> > > >> >> > >>> > for ALL connections.
>> > > >> >> > >>> > 20:41:03.582 [Thread-7] ERROR
>> > > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer -
>> Read a
>> > > >> frame
>> > > >> >> > >>> size of
>> > > >> >> > >>> > 18874697, which is bigger than the maximum allowable
>> frame
>> > > size
>> > > >> >> > >>> 16384000
>> > > >> >> > >>> > for ALL connections.
>> > > >> >> > >>> > 20:41:05.079 [Thread-7] ERROR
>> > > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer -
>> Read a
>> > > >> frame
>> > > >> >> > >>> size of
>> > > >> >> > >>> > 18874697, which is bigger than the maximum allowable
>> frame
>> > > size
>> > > >> >> > >>> 16384000
>> > > >> >> > >>> > for ALL connections.
>> > > >> >> > >>> >
>> > > >> >> > >>> > Other tests that write smaller amounts of data appear
>> to work
>> > > >> >> fine.
>> > > >> >> > >>> >
>> > > >> >> > >>> > Any idea what the issue might be?
>> > > >> >> > >>> >
>> > > >> >> > >>> > Thank you,
>> > > >> >> > >>> > Vincent
>> > > >> >> > >>> >
>> > > >> >> > >>> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
>> > > >> >> > >>> vincent.russell@gmail.com>
>> > > >> >> > >>> > wrote:
>> > > >> >> > >>> >
>> > > >> >> > >>> > > Thank you both for your responses.
>> > > >> >> > >>> > >
>> > > >> >> > >>> > > We are using an event store library from a sister
>> project
>> > > >> that
>> > > >> >> was
>> > > >> >> > >>> written
>> > > >> >> > >>> > > for accumulo 1.10., which I have already upgraded to
>> 2.0.
>> > > >> >> > >>> > >
>> > > >> >> > >>> > > I'll spend some time investigating how bad the usage
>> of the
>> > > >> >> internal
>> > > >> >> > >>> > > packages are and get back to you.
>> > > >> >> > >>> > >
>> > > >> >> > >>> > > Thanks again,
>> > > >> >> > >>> > >
>> > > >> >> > >>> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <
>> > > >> >> ctubbsii@apache.org>
>> > > >> >> > >>> wrote:
>> > > >> >> > >>> > >
>> > > >> >> > >>> > >> To add to Dave's answer, the public API is defined at
>> > > >> >> > >>> > >> https://accumulo.apache.org/api/
>> > > >> >> > >>> > >> Anything else is not public and is subject to change
>> > > without
>> > > >> >> notice
>> > > >> >> > >>> on
>> > > >> >> > >>> > >> any release without any attempt to retain
>> compatibility.
>> > > >> >> > >>> > >>
>> > > >> >> > >>> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <
>> > > >> >> dmarion18@gmail.com>
>> > > >> >> > >>> wrote:
>> > > >> >> > >>> > >> >
>> > > >> >> > >>> > >> > There is no guide. You are using implementation
>> classes
>> > > >> (see
>> > > >> >> > >>> clientImpl
>> > > >> >> > >>> > >> in
>> > > >> >> > >>> > >> > the package name) vs. using the client api. If you
>> can
>> > > use
>> > > >> >> the
>> > > >> >> > >>> client
>> > > >> >> > >>> > >> api
>> > > >> >> > >>> > >> > directly, then this should insulate you from
>> changes in
>> > > >> the
>> > > >> >> future
>> > > >> >> > >>> > >> (except
>> > > >> >> > >>> > >> > during major versions). We can try and find where
>> things
>> > > >> >> might
>> > > >> >> > >>> have
>> > > >> >> > >>> > >> moved,
>> > > >> >> > >>> > >> > but a class may have been split into multiple
>> pieces. If
>> > > >> you
>> > > >> >> could
>> > > >> >> > >>> > >> provide
>> > > >> >> > >>> > >> > class and method, that would be easier.
>> > > >> >> > >>> > >> >
>> > > >> >> > >>> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
>> > > >> >> > >>> > >> vincent.russell@gmail.com>
>> > > >> >> > >>> > >> > wrote:
>> > > >> >> > >>> > >> >
>> > > >> >> > >>> > >> > > Is there a guide that shows where classes may
>> have
>> > > been
>> > > >> >> moved
>> > > >> >> > >>> with
>> > > >> >> > >>> > >> moving
>> > > >> >> > >>> > >> > > from 2.0 to 2.1?  For instance, I am having
>> issues
>> > > >> >> compiling,
>> > > >> >> > >>> because
>> > > >> >> > >>> > >> the
>> > > >> >> > >>> > >> > > following class doesn't exist:
>> > > >> >> > >>> > >> > > import
>> org.apache.accumulo.core.clientImpl.Tables;
>> > > >> >> > >>> > >> > >
>> > > >> >> > >>> > >> > > I'm just getting started so I'm sure there are
>> others.
>> > > >> >> > >>> > >> > >
>> > > >> >> > >>> > >> > > Thanks,
>> > > >> >> > >>> > >> > > Vincent
>> > > >> >> > >>> > >> > >
>> > > >> >> > >>> > >> > >
>> > > >> >> > >>> > >> > >
>> > > >> >> > >>> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
>> > > >> >> > >>> > >> vincent.russell@gmail.com>
>> > > >> >> > >>> > >> > > wrote:
>> > > >> >> > >>> > >> > >
>> > > >> >> > >>> > >> > > > I mean Christopher.
>> > > >> >> > >>> > >> > > >
>> > > >> >> > >>> > >> > > > Thanks again.
>> > > >> >> > >>> > >> > > >
>> > > >> >> > >>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell
>> <
>> > > >> >> > >>> > >> > > vincent.russell@gmail.com>
>> > > >> >> > >>> > >> > > > wrote:
>> > > >> >> > >>> > >> > > >
>> > > >> >> > >>> > >> > > >> Thank you Chris.
>> > > >> >> > >>> > >> > > >>
>> > > >> >> > >>> > >> > > >> Will will upgrade to Accumulo 2.1 and
>> ZooKeeper
>> > > 3.7
>> > > >> or
>> > > >> >> > >>> later as
>> > > >> >> > >>> > >> soon as
>> > > >> >> > >>> > >> > > >> possible.
>> > > >> >> > >>> > >> > > >>
>> > > >> >> > >>> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <
>> > > >> >> > >>> ctubbsii@apache.org>
>> > > >> >> > >>> > >> wrote:
>> > > >> >> > >>> > >> > > >>
>> > > >> >> > >>> > >> > > >>> Hi Vincent,
>> > > >> >> > >>> > >> > > >>>
>> > > >> >> > >>> > >> > > >>> Version 2.0.1 is end of life as of the 2.1.0
>> LTM
>> > > >> >> release,
>> > > >> >> > >>> and 2.0
>> > > >> >> > >>> > >> is
>> > > >> >> > >>> > >> > > >>> not expected to receive any further updates.
>> > > Version
>> > > >> >> 2.1.0
>> > > >> >> > >>> may
>> > > >> >> > >>> > >> work
>> > > >> >> > >>> > >> > > >>> with ZooKeeper 3.4, but was developed and
>> tested
>> > > >> >> against
>> > > >> >> > >>> 3.5 and
>> > > >> >> > >>> > >> later
>> > > >> >> > >>> > >> > > >>> versions. I believe the ZooKeeper community
>> is
>> > > >> >> currently
>> > > >> >> > >>> > >> considering
>> > > >> >> > >>> > >> > > >>> whether to make 3.6 end-of-life themselves,
>> so I
>> > > >> would
>> > > >> >> > >>> recommend
>> > > >> >> > >>> > >> using
>> > > >> >> > >>> > >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7
>> or
>> > > >> later
>> > > >> >> to
>> > > >> >> > >>> have the
>> > > >> >> > >>> > >> best
>> > > >> >> > >>> > >> > > >>> chance of any kind of support, including JDK
>> 17
>> > > >> >> support.
>> > > >> >> > >>> > >> > > >>>
>> > > >> >> > >>> > >> > > >>> As for your specific issues:
>> > > >> >> > >>> > >> > > >>>
>> > > >> >> > >>> > >> > > >>> 1. This is already fixed in 2.1.0
>> > > >> >> > >>> > >> > > >>> 2/3. These issues are likely fixed in newer
>> > > >> ZooKeeper
>> > > >> >> > >>> versions. I
>> > > >> >> > >>> > >> > > >>> haven't seen them anytime recently, anyway.
>> Bugs
>> > > in
>> > > >> >> > >>> ZooKeeper
>> > > >> >> > >>> > >> itself
>> > > >> >> > >>> > >> > > >>> are out of scope for the Accumulo
>> developers, but
>> > > I
>> > > >> >> have
>> > > >> >> > >>> tried
>> > > >> >> > >>> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and
>> ZooKeeper
>> > > >> >> 3.8.0 and
>> > > >> >> > >>> > >> haven't
>> > > >> >> > >>> > >> > > >>> observed any unresolved issues. However, it's
>> > > >> >> difficult to
>> > > >> >> > >>> > >> actually
>> > > >> >> > >>> > >> > > >>> run it because I don't think Hadoop has good
>> JDK
>> > > 17
>> > > >> >> support
>> > > >> >> > >>> yet.
>> > > >> >> > >>> > >> So,
>> > > >> >> > >>> > >> > > >>> MiniAccumuloCluster seems to work with JDK
>> 17, as
>> > > >> does
>> > > >> >> > >>> Accumulo
>> > > >> >> > >>> > >> and ZK
>> > > >> >> > >>> > >> > > >>> 3.8, but I don't think a full Hadoop cluster
>> would
>> > > >> >> (yet).
>> > > >> >> > >>> > >> > > >>>
>> > > >> >> > >>> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent
>> Russell
>> > > >> >> > >>> > >> > > >>> <vi...@gmail.com> wrote:
>> > > >> >> > >>> > >> > > >>> >
>> > > >> >> > >>> > >> > > >>> > Hello,
>> > > >> >> > >>> > >> > > >>> >
>> > > >> >> > >>> > >> > > >>> > We are currently using accumulo 2.0.1.
>> > > >> >> > >>> > >> > > >>> >
>> > > >> >> > >>> > >> > > >>> > We are in the process of upgrading our
>> source
>> > > code
>> > > >> >> to use
>> > > >> >> > >>> jdk 17
>> > > >> >> > >>> > >> > > >>> however we
>> > > >> >> > >>> > >> > > >>> > are running into some problems with our
>> tests
>> > > and
>> > > >> the
>> > > >> >> > >>> > >> > > >>> MiniAccumuloCluster.
>> > > >> >> > >>> > >> > > >>> >
>> > > >> >> > >>> > >> > > >>> > One of our developer encountered the
>> following
>> > > >> >> issues:
>> > > >> >> > >>> > >> > > >>> >
>> > > >> >> > >>> > >> > > >>> >    1. The MiniAccumumluoClusterImpl._exec
>> is
>> > > >> >> hardcoded
>> > > >> >> > >>> with the
>> > > >> >> > >>> > >> JVM
>> > > >> >> > >>> > >> > > arg
>> > > >> >> > >>> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no
>> longer
>> > > >> >> tolerated
>> > > >> >> > >>> with
>> > > >> >> > >>> > >> JDK17.
>> > > >> >> > >>> > >> > > >>> >    2. In Zookeeper 3.4.14,
>> ConetStringParser
>> > > uses
>> > > >> >> > >>> > >> createUnresolved to
>> > > >> >> > >>> > >> > > >>> >    make IPAddresses.
>> > > >> >> > >>> > >> > > >>>
>> > > >> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
>> > > >> >> > >>> > >> > > >>> >    uses InetSocketAddess.getAddress, which
>> > > returns
>> > > >> >> null
>> > > >> >> > >>> because
>> > > >> >> > >>> > >> it's
>> > > >> >> > >>> > >> > > >>> not
>> > > >> >> > >>> > >> > > >>> >    resolved, resulting in a failure to
>> connect
>> > > to
>> > > >> the
>> > > >> >> > >>> > >> newly-started
>> > > >> >> > >>> > >> > > >>> zookeeper.
>> > > >> >> > >>> > >> > > >>> >    3. StaticHostProvider.getHostString()
>> tries
>> > > to
>> > > >> >> extract
>> > > >> >> > >>> he
>> > > >> >> > >>> > >> hostname
>> > > >> >> > >>> > >> > > >>> by
>> > > >> >> > >>> > >> > > >>> >    calling toString on the address and
>> taking
>> > > >> >> everything
>> > > >> >> > >>> before
>> > > >> >> > >>> > >> the
>> > > >> >> > >>> > >> > > >>> colon, but
>> > > >> >> > >>> > >> > > >>> >    in JDK17, the string format changed to
>> > > >> >> > >>> > >> > > "localhost/<unresolved->:xx"
>> > > >> >> > >>> > >> > > >>> (where
>> > > >> >> > >>> > >> > > >>> >    XX is still the port number).  That's
>> > > incorrect
>> > > >> >> and it
>> > > >> >> > >>> can't
>> > > >> >> > >>> > >> > > >>> resolve the
>> > > >> >> > >>> > >> > > >>> >    names.
>> > > >> >> > >>> > >> > > >>> >
>> > > >> >> > >>> > >> > > >>> >
>> > > >> >> > >>> > >> > > >>> > Has anyone come across/resolved these
>> kinds of
>> > > >> >> issues?
>> > > >> >> > >>> Is it
>> > > >> >> > >>> > >> not
>> > > >> >> > >>> > >> > > >>> possible
>> > > >> >> > >>> > >> > > >>> > to use java17 from a client perspective?
>> Will
>> > > >> >> upgrading
>> > > >> >> > >>> to
>> > > >> >> > >>> > >> accumulo
>> > > >> >> > >>> > >> > > >>> 2.1
>> > > >> >> > >>> > >> > > >>> > help?
>> > > >> >> > >>> > >> > > >>> >
>> > > >> >> > >>> > >> > > >>> > Thanks,
>> > > >> >> > >>> > >> > > >>> > Vincent
>> > > >> >> > >>> > >> > > >>>
>> > > >> >> > >>> > >> > > >>
>> > > >> >> > >>> > >> > >
>> > > >> >> > >>> > >>
>> > > >> >> > >>> > >
>> > > >> >> > >>>
>> > > >> >> > >>
>> > > >> >>
>> > > >> >
>> > > >>
>> > > >
>> > >
>>
>

Re: jdk 17 and accumulo testing

Posted by Vincent Russell <vi...@gmail.com>.
Ok.. Thank you for the update.

On Fri, Dec 30, 2022 at 11:55 AM Christopher <ct...@apache.org> wrote:

> For reference, here's the PR working on the fix for 2.1.1:
> https://github.com/apache/accumulo/pull/3134
>
> On Fri, Dec 30, 2022 at 11:39 AM Christopher Shannon
> <ch...@gmail.com> wrote:
> >
> > Version 2.1.1 will be released with bug fixes and this fix (when finished
> > and merged) is planned to be included as part of that release. I don't
> know
> > the exact time frame yet though.
> >
> > On Fri, Dec 30, 2022 at 11:04 AM Vincent Russell <
> vincent.russell@gmail.com>
> > wrote:
> >
> > > Hello,
> > >
> > > Are there any plans to release an accumulo 2.1 patch to fix this issue?
> > >
> > > Thanks,
> > >
> > > On Sat, Dec 17, 2022 at 7:36 PM Vincent Russell <
> vincent.russell@gmail.com
> > > >
> > > wrote:
> > >
> > > > No worries.  I'm glad I was able to help in some small way.
> > > >
> > > > Thank you for fixing the issue.
> > > >
> > > > On Sat, Dec 17, 2022 at 11:49 AM Christopher Shannon <
> > > > christopher.l.shannon@gmail.com> wrote:
> > > >
> > > >> I created https://github.com/apache/accumulo/pull/3134 and that
> should
> > > >> fix
> > > >> this issue.
> > > >>
> > > >> Thanks Vincent for pointing out the issue in TServerUtils, your
> testing
> > > >> made this easy to track down and fix.
> > > >>
> > > >>
> > > >> On Sat, Dec 17, 2022 at 9:00 AM Christopher Shannon <
> > > >> christopher.l.shannon@gmail.com> wrote:
> > > >>
> > > >> > I was able to reproduce the issue by setting the value size for a
> > > >> mutation
> > > >> > to size 16384001 to make sure it's greater than the default value
> for
> > > >> > Thrift and it fails immediately. I will work on a fix now that we
> know
> > > >> how
> > > >> > to reproduce it.
> > > >> >
> > > >> > On Fri, Dec 16, 2022 at 2:31 PM Christopher <ct...@apache.org>
> > > >> wrote:
> > > >> >
> > > >> >> I don't think it's intentional. This might be the source of the
> > > >> problem.
> > > >> >>
> > > >> >> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
> > > >> >> <vi...@gmail.com> wrote:
> > > >> >> >
> > > >> >> > Also in TserverUtils:270, when the TNonblockingServerSocket is
> > > >> created
> > > >> >> it
> > > >> >> > looks like it ends up using the default frame size.  I am not
> sure
> > > if
> > > >> >> this
> > > >> >> > is intentional or not.
> > > >> >> >
> > > >> >> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
> > > >> >> vincent.russell@gmail.com>
> > > >> >> > wrote:
> > > >> >> >
> > > >> >> > > Christopher,
> > > >> >> > >
> > > >> >> > > I am not sure if this issue is related to 3042 or not.
> > > >> >> > >
> > > >> >> > > On the client side it does look like TConfiguration ends up
> being
> > > >> >> called
> > > >> >> > > with the default constructor.  I am not sure if this is
> > > intentional
> > > >> >> or not.
> > > >> >> > >
> > > >> >> > > On the server side I see this stack, so it also looks like:
> > > >> >> > >
> > > >> >> > > at
> > > org.apache.thrift.TConfiguration.<init>(TConfiguration.java:36)
> > > >> >> > > at
> > > >> >>
> > > org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
> > > >> >> > > at
> > > >> org.apache.thrift.TConfiguration.<clinit>(TConfiguration.java:65)
> > > >> >> > > at
> > > >> >> > >
> > > >> >>
> > > >>
> > >
> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:74)
> > > >> >> > > at
> > > >> >> > >
> > > >> >>
> > > >>
> > >
> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:68)
> > > >> >> > > at
> > > >> >> > >
> > > >> >>
> > > >>
> > >
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
> > > >> >> > > at
> > > >> >> > >
> > > >> >>
> > > >>
> > >
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
> > > >> >> > > at
> > > >> >> > >
> > > >> >>
> > > >>
> > >
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
> > > >> >> > > at
> > > >> >> > >
> > > >> >>
> > > >>
> > >
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
> > > >> >> > > at
> > > >> >> > >
> > > >> >>
> > > >>
> > >
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > I see this in the server log so it does look like it should
> be
> > > >> using
> > > >> >> 1G:
> > > >> >> > > 2022-09-01 16:59:41 INFO
> > > >> [org.apache.accumulo.tserver.TabletServer]
> > > >> >> > > ServerUtil:124 - general.server.message.size.max = 1G
> > > >> >> > >
> > > >> >> > > Thanks,
> > > >> >> > > Vincent
> > > >> >> > >
> > > >> >> > > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
> > > >> >> > > vincent.russell@gmail.com> wrote:
> > > >> >> > >
> > > >> >> > >>
> > > >> >> > >>
> > > >> >> > >> I had to make a stack trace with hacking together a remote
> debug
> > > >> >> instance:
> > > >> >> > >>
> > > >> >> > >> at
> > > >> >> > >>
> > > >> >>
> > > >>
> > >
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
> > > >> >> > >> at
> > > >> >> > >>
> > > >> >>
> > > >>
> > >
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
> > > >> >> > >> at
> > > >> >> > >>
> > > >> >>
> > > >>
> > >
> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
> > > >> >> > >> at
> > > >> >> > >>
> > > >> >>
> > > >>
> > >
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
> > > >> >> > >> at
> > > >> >> > >>
> > > >> >>
> > > >>
> > >
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> > > >> >> > >>
> > > >> >> > >> On Thu, Dec 15, 2022 at 12:52 AM Christopher <
> > > ctubbsii@apache.org
> > > >> >
> > > >> >> wrote:
> > > >> >> > >>
> > > >> >> > >>> From the numbers in the message, it looks like you're
> sending
> > > an
> > > >> >> 18MB
> > > >> >> > >>> payload but something in Thrift is limiting things to
> 16384000
> > > >> >> > >>> (16000KB). I doubt you've overridden the default
> > > >> >> > >>> general.server.message.size.max to be anything that low
> (the
> > > >> default
> > > >> >> > >>> is 1G). Unless you're flushing after every mutation, it
> would
> > > >> not be
> > > >> >> > >>> surprising to exceed the 16MB max frame size indicated in
> the
> > > >> error
> > > >> >> > >>> message quite quickly.
> > > >> >> > >>>
> > > >> >> > >>> This value of 16384000 seemed weird. It looks like it's not
> > > using
> > > >> >> our
> > > >> >> > >>> configuration, but using the built-in default value of
> > > >> >> > >>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It
> > > looks
> > > >> >> like
> > > >> >> > >>> this can happen whenever `new TConfiguration()` is called
> > > without
> > > >> >> > >>> parameters... and there's a fair amount of internal code,
> > > mostly
> > > >> in
> > > >> >> > >>> libthrift itself, that does that. It's a bit tricky to
> track
> > > down
> > > >> >> the
> > > >> >> > >>> one causing this particular issue. If you have a full stack
> > > >> trace,
> > > >> >> it
> > > >> >> > >>> could help.
> > > >> >> > >>>
> > > >> >> > >>> Also, this might be the same issue seen reported in
> > > >> >> > >>> https://github.com/apache/accumulo/issues/3042
> > > >> >> > >>>
> > > >> >> > >>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
> > > >> >> > >>> <vi...@gmail.com> wrote:
> > > >> >> > >>> >
> > > >> >> > >>> > I was able to work out all of my compilation issues;
> however
> > > >> when
> > > >> >> I
> > > >> >> > >>> run an
> > > >> >> > >>> > integration test with the Mini Accumulo Cluster that
> tests
> > > >> writing
> > > >> >> > >>> > mutations with values of 5mb the flush hangs forever
> > > >> >> > >>> > and I see  the following logs in the TabletServer logs:
> > > >> >> > >>> >
> > > >> >> > >>> > 20:41:02.306 [Thread-7] ERROR
> > > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer -
> Read a
> > > >> frame
> > > >> >> > >>> size of
> > > >> >> > >>> > 18874697, which is bigger than the maximum allowable
> frame
> > > size
> > > >> >> > >>> 16384000
> > > >> >> > >>> > for ALL connections.
> > > >> >> > >>> > 20:41:03.582 [Thread-7] ERROR
> > > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer -
> Read a
> > > >> frame
> > > >> >> > >>> size of
> > > >> >> > >>> > 18874697, which is bigger than the maximum allowable
> frame
> > > size
> > > >> >> > >>> 16384000
> > > >> >> > >>> > for ALL connections.
> > > >> >> > >>> > 20:41:05.079 [Thread-7] ERROR
> > > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer -
> Read a
> > > >> frame
> > > >> >> > >>> size of
> > > >> >> > >>> > 18874697, which is bigger than the maximum allowable
> frame
> > > size
> > > >> >> > >>> 16384000
> > > >> >> > >>> > for ALL connections.
> > > >> >> > >>> >
> > > >> >> > >>> > Other tests that write smaller amounts of data appear to
> work
> > > >> >> fine.
> > > >> >> > >>> >
> > > >> >> > >>> > Any idea what the issue might be?
> > > >> >> > >>> >
> > > >> >> > >>> > Thank you,
> > > >> >> > >>> > Vincent
> > > >> >> > >>> >
> > > >> >> > >>> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
> > > >> >> > >>> vincent.russell@gmail.com>
> > > >> >> > >>> > wrote:
> > > >> >> > >>> >
> > > >> >> > >>> > > Thank you both for your responses.
> > > >> >> > >>> > >
> > > >> >> > >>> > > We are using an event store library from a sister
> project
> > > >> that
> > > >> >> was
> > > >> >> > >>> written
> > > >> >> > >>> > > for accumulo 1.10., which I have already upgraded to
> 2.0.
> > > >> >> > >>> > >
> > > >> >> > >>> > > I'll spend some time investigating how bad the usage
> of the
> > > >> >> internal
> > > >> >> > >>> > > packages are and get back to you.
> > > >> >> > >>> > >
> > > >> >> > >>> > > Thanks again,
> > > >> >> > >>> > >
> > > >> >> > >>> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <
> > > >> >> ctubbsii@apache.org>
> > > >> >> > >>> wrote:
> > > >> >> > >>> > >
> > > >> >> > >>> > >> To add to Dave's answer, the public API is defined at
> > > >> >> > >>> > >> https://accumulo.apache.org/api/
> > > >> >> > >>> > >> Anything else is not public and is subject to change
> > > without
> > > >> >> notice
> > > >> >> > >>> on
> > > >> >> > >>> > >> any release without any attempt to retain
> compatibility.
> > > >> >> > >>> > >>
> > > >> >> > >>> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <
> > > >> >> dmarion18@gmail.com>
> > > >> >> > >>> wrote:
> > > >> >> > >>> > >> >
> > > >> >> > >>> > >> > There is no guide. You are using implementation
> classes
> > > >> (see
> > > >> >> > >>> clientImpl
> > > >> >> > >>> > >> in
> > > >> >> > >>> > >> > the package name) vs. using the client api. If you
> can
> > > use
> > > >> >> the
> > > >> >> > >>> client
> > > >> >> > >>> > >> api
> > > >> >> > >>> > >> > directly, then this should insulate you from
> changes in
> > > >> the
> > > >> >> future
> > > >> >> > >>> > >> (except
> > > >> >> > >>> > >> > during major versions). We can try and find where
> things
> > > >> >> might
> > > >> >> > >>> have
> > > >> >> > >>> > >> moved,
> > > >> >> > >>> > >> > but a class may have been split into multiple
> pieces. If
> > > >> you
> > > >> >> could
> > > >> >> > >>> > >> provide
> > > >> >> > >>> > >> > class and method, that would be easier.
> > > >> >> > >>> > >> >
> > > >> >> > >>> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
> > > >> >> > >>> > >> vincent.russell@gmail.com>
> > > >> >> > >>> > >> > wrote:
> > > >> >> > >>> > >> >
> > > >> >> > >>> > >> > > Is there a guide that shows where classes may have
> > > been
> > > >> >> moved
> > > >> >> > >>> with
> > > >> >> > >>> > >> moving
> > > >> >> > >>> > >> > > from 2.0 to 2.1?  For instance, I am having issues
> > > >> >> compiling,
> > > >> >> > >>> because
> > > >> >> > >>> > >> the
> > > >> >> > >>> > >> > > following class doesn't exist:
> > > >> >> > >>> > >> > > import org.apache.accumulo.core.clientImpl.Tables;
> > > >> >> > >>> > >> > >
> > > >> >> > >>> > >> > > I'm just getting started so I'm sure there are
> others.
> > > >> >> > >>> > >> > >
> > > >> >> > >>> > >> > > Thanks,
> > > >> >> > >>> > >> > > Vincent
> > > >> >> > >>> > >> > >
> > > >> >> > >>> > >> > >
> > > >> >> > >>> > >> > >
> > > >> >> > >>> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
> > > >> >> > >>> > >> vincent.russell@gmail.com>
> > > >> >> > >>> > >> > > wrote:
> > > >> >> > >>> > >> > >
> > > >> >> > >>> > >> > > > I mean Christopher.
> > > >> >> > >>> > >> > > >
> > > >> >> > >>> > >> > > > Thanks again.
> > > >> >> > >>> > >> > > >
> > > >> >> > >>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
> > > >> >> > >>> > >> > > vincent.russell@gmail.com>
> > > >> >> > >>> > >> > > > wrote:
> > > >> >> > >>> > >> > > >
> > > >> >> > >>> > >> > > >> Thank you Chris.
> > > >> >> > >>> > >> > > >>
> > > >> >> > >>> > >> > > >> Will will upgrade to Accumulo 2.1 and
> ZooKeeper
> > > 3.7
> > > >> or
> > > >> >> > >>> later as
> > > >> >> > >>> > >> soon as
> > > >> >> > >>> > >> > > >> possible.
> > > >> >> > >>> > >> > > >>
> > > >> >> > >>> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <
> > > >> >> > >>> ctubbsii@apache.org>
> > > >> >> > >>> > >> wrote:
> > > >> >> > >>> > >> > > >>
> > > >> >> > >>> > >> > > >>> Hi Vincent,
> > > >> >> > >>> > >> > > >>>
> > > >> >> > >>> > >> > > >>> Version 2.0.1 is end of life as of the 2.1.0
> LTM
> > > >> >> release,
> > > >> >> > >>> and 2.0
> > > >> >> > >>> > >> is
> > > >> >> > >>> > >> > > >>> not expected to receive any further updates.
> > > Version
> > > >> >> 2.1.0
> > > >> >> > >>> may
> > > >> >> > >>> > >> work
> > > >> >> > >>> > >> > > >>> with ZooKeeper 3.4, but was developed and
> tested
> > > >> >> against
> > > >> >> > >>> 3.5 and
> > > >> >> > >>> > >> later
> > > >> >> > >>> > >> > > >>> versions. I believe the ZooKeeper community is
> > > >> >> currently
> > > >> >> > >>> > >> considering
> > > >> >> > >>> > >> > > >>> whether to make 3.6 end-of-life themselves,
> so I
> > > >> would
> > > >> >> > >>> recommend
> > > >> >> > >>> > >> using
> > > >> >> > >>> > >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7
> or
> > > >> later
> > > >> >> to
> > > >> >> > >>> have the
> > > >> >> > >>> > >> best
> > > >> >> > >>> > >> > > >>> chance of any kind of support, including JDK
> 17
> > > >> >> support.
> > > >> >> > >>> > >> > > >>>
> > > >> >> > >>> > >> > > >>> As for your specific issues:
> > > >> >> > >>> > >> > > >>>
> > > >> >> > >>> > >> > > >>> 1. This is already fixed in 2.1.0
> > > >> >> > >>> > >> > > >>> 2/3. These issues are likely fixed in newer
> > > >> ZooKeeper
> > > >> >> > >>> versions. I
> > > >> >> > >>> > >> > > >>> haven't seen them anytime recently, anyway.
> Bugs
> > > in
> > > >> >> > >>> ZooKeeper
> > > >> >> > >>> > >> itself
> > > >> >> > >>> > >> > > >>> are out of scope for the Accumulo developers,
> but
> > > I
> > > >> >> have
> > > >> >> > >>> tried
> > > >> >> > >>> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and
> ZooKeeper
> > > >> >> 3.8.0 and
> > > >> >> > >>> > >> haven't
> > > >> >> > >>> > >> > > >>> observed any unresolved issues. However, it's
> > > >> >> difficult to
> > > >> >> > >>> > >> actually
> > > >> >> > >>> > >> > > >>> run it because I don't think Hadoop has good
> JDK
> > > 17
> > > >> >> support
> > > >> >> > >>> yet.
> > > >> >> > >>> > >> So,
> > > >> >> > >>> > >> > > >>> MiniAccumuloCluster seems to work with JDK
> 17, as
> > > >> does
> > > >> >> > >>> Accumulo
> > > >> >> > >>> > >> and ZK
> > > >> >> > >>> > >> > > >>> 3.8, but I don't think a full Hadoop cluster
> would
> > > >> >> (yet).
> > > >> >> > >>> > >> > > >>>
> > > >> >> > >>> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent
> Russell
> > > >> >> > >>> > >> > > >>> <vi...@gmail.com> wrote:
> > > >> >> > >>> > >> > > >>> >
> > > >> >> > >>> > >> > > >>> > Hello,
> > > >> >> > >>> > >> > > >>> >
> > > >> >> > >>> > >> > > >>> > We are currently using accumulo 2.0.1.
> > > >> >> > >>> > >> > > >>> >
> > > >> >> > >>> > >> > > >>> > We are in the process of upgrading our
> source
> > > code
> > > >> >> to use
> > > >> >> > >>> jdk 17
> > > >> >> > >>> > >> > > >>> however we
> > > >> >> > >>> > >> > > >>> > are running into some problems with our
> tests
> > > and
> > > >> the
> > > >> >> > >>> > >> > > >>> MiniAccumuloCluster.
> > > >> >> > >>> > >> > > >>> >
> > > >> >> > >>> > >> > > >>> > One of our developer encountered the
> following
> > > >> >> issues:
> > > >> >> > >>> > >> > > >>> >
> > > >> >> > >>> > >> > > >>> >    1. The MiniAccumumluoClusterImpl._exec is
> > > >> >> hardcoded
> > > >> >> > >>> with the
> > > >> >> > >>> > >> JVM
> > > >> >> > >>> > >> > > arg
> > > >> >> > >>> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no
> longer
> > > >> >> tolerated
> > > >> >> > >>> with
> > > >> >> > >>> > >> JDK17.
> > > >> >> > >>> > >> > > >>> >    2. In Zookeeper 3.4.14, ConetStringParser
> > > uses
> > > >> >> > >>> > >> createUnresolved to
> > > >> >> > >>> > >> > > >>> >    make IPAddresses.
> > > >> >> > >>> > >> > > >>>
> > > >> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> > > >> >> > >>> > >> > > >>> >    uses InetSocketAddess.getAddress, which
> > > returns
> > > >> >> null
> > > >> >> > >>> because
> > > >> >> > >>> > >> it's
> > > >> >> > >>> > >> > > >>> not
> > > >> >> > >>> > >> > > >>> >    resolved, resulting in a failure to
> connect
> > > to
> > > >> the
> > > >> >> > >>> > >> newly-started
> > > >> >> > >>> > >> > > >>> zookeeper.
> > > >> >> > >>> > >> > > >>> >    3. StaticHostProvider.getHostString()
> tries
> > > to
> > > >> >> extract
> > > >> >> > >>> he
> > > >> >> > >>> > >> hostname
> > > >> >> > >>> > >> > > >>> by
> > > >> >> > >>> > >> > > >>> >    calling toString on the address and
> taking
> > > >> >> everything
> > > >> >> > >>> before
> > > >> >> > >>> > >> the
> > > >> >> > >>> > >> > > >>> colon, but
> > > >> >> > >>> > >> > > >>> >    in JDK17, the string format changed to
> > > >> >> > >>> > >> > > "localhost/<unresolved->:xx"
> > > >> >> > >>> > >> > > >>> (where
> > > >> >> > >>> > >> > > >>> >    XX is still the port number).  That's
> > > incorrect
> > > >> >> and it
> > > >> >> > >>> can't
> > > >> >> > >>> > >> > > >>> resolve the
> > > >> >> > >>> > >> > > >>> >    names.
> > > >> >> > >>> > >> > > >>> >
> > > >> >> > >>> > >> > > >>> >
> > > >> >> > >>> > >> > > >>> > Has anyone come across/resolved these kinds
> of
> > > >> >> issues?
> > > >> >> > >>> Is it
> > > >> >> > >>> > >> not
> > > >> >> > >>> > >> > > >>> possible
> > > >> >> > >>> > >> > > >>> > to use java17 from a client perspective?
> Will
> > > >> >> upgrading
> > > >> >> > >>> to
> > > >> >> > >>> > >> accumulo
> > > >> >> > >>> > >> > > >>> 2.1
> > > >> >> > >>> > >> > > >>> > help?
> > > >> >> > >>> > >> > > >>> >
> > > >> >> > >>> > >> > > >>> > Thanks,
> > > >> >> > >>> > >> > > >>> > Vincent
> > > >> >> > >>> > >> > > >>>
> > > >> >> > >>> > >> > > >>
> > > >> >> > >>> > >> > >
> > > >> >> > >>> > >>
> > > >> >> > >>> > >
> > > >> >> > >>>
> > > >> >> > >>
> > > >> >>
> > > >> >
> > > >>
> > > >
> > >
>

Re: jdk 17 and accumulo testing

Posted by Christopher <ct...@apache.org>.
For reference, here's the PR working on the fix for 2.1.1:
https://github.com/apache/accumulo/pull/3134

On Fri, Dec 30, 2022 at 11:39 AM Christopher Shannon
<ch...@gmail.com> wrote:
>
> Version 2.1.1 will be released with bug fixes and this fix (when finished
> and merged) is planned to be included as part of that release. I don't know
> the exact time frame yet though.
>
> On Fri, Dec 30, 2022 at 11:04 AM Vincent Russell <vi...@gmail.com>
> wrote:
>
> > Hello,
> >
> > Are there any plans to release an accumulo 2.1 patch to fix this issue?
> >
> > Thanks,
> >
> > On Sat, Dec 17, 2022 at 7:36 PM Vincent Russell <vincent.russell@gmail.com
> > >
> > wrote:
> >
> > > No worries.  I'm glad I was able to help in some small way.
> > >
> > > Thank you for fixing the issue.
> > >
> > > On Sat, Dec 17, 2022 at 11:49 AM Christopher Shannon <
> > > christopher.l.shannon@gmail.com> wrote:
> > >
> > >> I created https://github.com/apache/accumulo/pull/3134 and that should
> > >> fix
> > >> this issue.
> > >>
> > >> Thanks Vincent for pointing out the issue in TServerUtils, your testing
> > >> made this easy to track down and fix.
> > >>
> > >>
> > >> On Sat, Dec 17, 2022 at 9:00 AM Christopher Shannon <
> > >> christopher.l.shannon@gmail.com> wrote:
> > >>
> > >> > I was able to reproduce the issue by setting the value size for a
> > >> mutation
> > >> > to size 16384001 to make sure it's greater than the default value for
> > >> > Thrift and it fails immediately. I will work on a fix now that we know
> > >> how
> > >> > to reproduce it.
> > >> >
> > >> > On Fri, Dec 16, 2022 at 2:31 PM Christopher <ct...@apache.org>
> > >> wrote:
> > >> >
> > >> >> I don't think it's intentional. This might be the source of the
> > >> problem.
> > >> >>
> > >> >> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
> > >> >> <vi...@gmail.com> wrote:
> > >> >> >
> > >> >> > Also in TserverUtils:270, when the TNonblockingServerSocket is
> > >> created
> > >> >> it
> > >> >> > looks like it ends up using the default frame size.  I am not sure
> > if
> > >> >> this
> > >> >> > is intentional or not.
> > >> >> >
> > >> >> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
> > >> >> vincent.russell@gmail.com>
> > >> >> > wrote:
> > >> >> >
> > >> >> > > Christopher,
> > >> >> > >
> > >> >> > > I am not sure if this issue is related to 3042 or not.
> > >> >> > >
> > >> >> > > On the client side it does look like TConfiguration ends up being
> > >> >> called
> > >> >> > > with the default constructor.  I am not sure if this is
> > intentional
> > >> >> or not.
> > >> >> > >
> > >> >> > > On the server side I see this stack, so it also looks like:
> > >> >> > >
> > >> >> > > at
> > org.apache.thrift.TConfiguration.<init>(TConfiguration.java:36)
> > >> >> > > at
> > >> >>
> > org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
> > >> >> > > at
> > >> org.apache.thrift.TConfiguration.<clinit>(TConfiguration.java:65)
> > >> >> > > at
> > >> >> > >
> > >> >>
> > >>
> > org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:74)
> > >> >> > > at
> > >> >> > >
> > >> >>
> > >>
> > org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:68)
> > >> >> > > at
> > >> >> > >
> > >> >>
> > >>
> > org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
> > >> >> > > at
> > >> >> > >
> > >> >>
> > >>
> > org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
> > >> >> > > at
> > >> >> > >
> > >> >>
> > >>
> > org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
> > >> >> > > at
> > >> >> > >
> > >> >>
> > >>
> > org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
> > >> >> > > at
> > >> >> > >
> > >> >>
> > >>
> > org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> > >> >> > >
> > >> >> > >
> > >> >> > > I see this in the server log so it does look like it should be
> > >> using
> > >> >> 1G:
> > >> >> > > 2022-09-01 16:59:41 INFO
> > >> [org.apache.accumulo.tserver.TabletServer]
> > >> >> > > ServerUtil:124 - general.server.message.size.max = 1G
> > >> >> > >
> > >> >> > > Thanks,
> > >> >> > > Vincent
> > >> >> > >
> > >> >> > > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
> > >> >> > > vincent.russell@gmail.com> wrote:
> > >> >> > >
> > >> >> > >>
> > >> >> > >>
> > >> >> > >> I had to make a stack trace with hacking together a remote debug
> > >> >> instance:
> > >> >> > >>
> > >> >> > >> at
> > >> >> > >>
> > >> >>
> > >>
> > org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
> > >> >> > >> at
> > >> >> > >>
> > >> >>
> > >>
> > org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
> > >> >> > >> at
> > >> >> > >>
> > >> >>
> > >>
> > org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
> > >> >> > >> at
> > >> >> > >>
> > >> >>
> > >>
> > org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
> > >> >> > >> at
> > >> >> > >>
> > >> >>
> > >>
> > org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> > >> >> > >>
> > >> >> > >> On Thu, Dec 15, 2022 at 12:52 AM Christopher <
> > ctubbsii@apache.org
> > >> >
> > >> >> wrote:
> > >> >> > >>
> > >> >> > >>> From the numbers in the message, it looks like you're sending
> > an
> > >> >> 18MB
> > >> >> > >>> payload but something in Thrift is limiting things to 16384000
> > >> >> > >>> (16000KB). I doubt you've overridden the default
> > >> >> > >>> general.server.message.size.max to be anything that low (the
> > >> default
> > >> >> > >>> is 1G). Unless you're flushing after every mutation, it would
> > >> not be
> > >> >> > >>> surprising to exceed the 16MB max frame size indicated in the
> > >> error
> > >> >> > >>> message quite quickly.
> > >> >> > >>>
> > >> >> > >>> This value of 16384000 seemed weird. It looks like it's not
> > using
> > >> >> our
> > >> >> > >>> configuration, but using the built-in default value of
> > >> >> > >>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It
> > looks
> > >> >> like
> > >> >> > >>> this can happen whenever `new TConfiguration()` is called
> > without
> > >> >> > >>> parameters... and there's a fair amount of internal code,
> > mostly
> > >> in
> > >> >> > >>> libthrift itself, that does that. It's a bit tricky to track
> > down
> > >> >> the
> > >> >> > >>> one causing this particular issue. If you have a full stack
> > >> trace,
> > >> >> it
> > >> >> > >>> could help.
> > >> >> > >>>
> > >> >> > >>> Also, this might be the same issue seen reported in
> > >> >> > >>> https://github.com/apache/accumulo/issues/3042
> > >> >> > >>>
> > >> >> > >>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
> > >> >> > >>> <vi...@gmail.com> wrote:
> > >> >> > >>> >
> > >> >> > >>> > I was able to work out all of my compilation issues; however
> > >> when
> > >> >> I
> > >> >> > >>> run an
> > >> >> > >>> > integration test with the Mini Accumulo Cluster that tests
> > >> writing
> > >> >> > >>> > mutations with values of 5mb the flush hangs forever
> > >> >> > >>> > and I see  the following logs in the TabletServer logs:
> > >> >> > >>> >
> > >> >> > >>> > 20:41:02.306 [Thread-7] ERROR
> > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a
> > >> frame
> > >> >> > >>> size of
> > >> >> > >>> > 18874697, which is bigger than the maximum allowable frame
> > size
> > >> >> > >>> 16384000
> > >> >> > >>> > for ALL connections.
> > >> >> > >>> > 20:41:03.582 [Thread-7] ERROR
> > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a
> > >> frame
> > >> >> > >>> size of
> > >> >> > >>> > 18874697, which is bigger than the maximum allowable frame
> > size
> > >> >> > >>> 16384000
> > >> >> > >>> > for ALL connections.
> > >> >> > >>> > 20:41:05.079 [Thread-7] ERROR
> > >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a
> > >> frame
> > >> >> > >>> size of
> > >> >> > >>> > 18874697, which is bigger than the maximum allowable frame
> > size
> > >> >> > >>> 16384000
> > >> >> > >>> > for ALL connections.
> > >> >> > >>> >
> > >> >> > >>> > Other tests that write smaller amounts of data appear to work
> > >> >> fine.
> > >> >> > >>> >
> > >> >> > >>> > Any idea what the issue might be?
> > >> >> > >>> >
> > >> >> > >>> > Thank you,
> > >> >> > >>> > Vincent
> > >> >> > >>> >
> > >> >> > >>> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
> > >> >> > >>> vincent.russell@gmail.com>
> > >> >> > >>> > wrote:
> > >> >> > >>> >
> > >> >> > >>> > > Thank you both for your responses.
> > >> >> > >>> > >
> > >> >> > >>> > > We are using an event store library from a sister project
> > >> that
> > >> >> was
> > >> >> > >>> written
> > >> >> > >>> > > for accumulo 1.10., which I have already upgraded to 2.0.
> > >> >> > >>> > >
> > >> >> > >>> > > I'll spend some time investigating how bad the usage of the
> > >> >> internal
> > >> >> > >>> > > packages are and get back to you.
> > >> >> > >>> > >
> > >> >> > >>> > > Thanks again,
> > >> >> > >>> > >
> > >> >> > >>> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <
> > >> >> ctubbsii@apache.org>
> > >> >> > >>> wrote:
> > >> >> > >>> > >
> > >> >> > >>> > >> To add to Dave's answer, the public API is defined at
> > >> >> > >>> > >> https://accumulo.apache.org/api/
> > >> >> > >>> > >> Anything else is not public and is subject to change
> > without
> > >> >> notice
> > >> >> > >>> on
> > >> >> > >>> > >> any release without any attempt to retain compatibility.
> > >> >> > >>> > >>
> > >> >> > >>> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <
> > >> >> dmarion18@gmail.com>
> > >> >> > >>> wrote:
> > >> >> > >>> > >> >
> > >> >> > >>> > >> > There is no guide. You are using implementation classes
> > >> (see
> > >> >> > >>> clientImpl
> > >> >> > >>> > >> in
> > >> >> > >>> > >> > the package name) vs. using the client api. If you can
> > use
> > >> >> the
> > >> >> > >>> client
> > >> >> > >>> > >> api
> > >> >> > >>> > >> > directly, then this should insulate you from changes in
> > >> the
> > >> >> future
> > >> >> > >>> > >> (except
> > >> >> > >>> > >> > during major versions). We can try and find where things
> > >> >> might
> > >> >> > >>> have
> > >> >> > >>> > >> moved,
> > >> >> > >>> > >> > but a class may have been split into multiple pieces. If
> > >> you
> > >> >> could
> > >> >> > >>> > >> provide
> > >> >> > >>> > >> > class and method, that would be easier.
> > >> >> > >>> > >> >
> > >> >> > >>> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
> > >> >> > >>> > >> vincent.russell@gmail.com>
> > >> >> > >>> > >> > wrote:
> > >> >> > >>> > >> >
> > >> >> > >>> > >> > > Is there a guide that shows where classes may have
> > been
> > >> >> moved
> > >> >> > >>> with
> > >> >> > >>> > >> moving
> > >> >> > >>> > >> > > from 2.0 to 2.1?  For instance, I am having issues
> > >> >> compiling,
> > >> >> > >>> because
> > >> >> > >>> > >> the
> > >> >> > >>> > >> > > following class doesn't exist:
> > >> >> > >>> > >> > > import org.apache.accumulo.core.clientImpl.Tables;
> > >> >> > >>> > >> > >
> > >> >> > >>> > >> > > I'm just getting started so I'm sure there are others.
> > >> >> > >>> > >> > >
> > >> >> > >>> > >> > > Thanks,
> > >> >> > >>> > >> > > Vincent
> > >> >> > >>> > >> > >
> > >> >> > >>> > >> > >
> > >> >> > >>> > >> > >
> > >> >> > >>> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
> > >> >> > >>> > >> vincent.russell@gmail.com>
> > >> >> > >>> > >> > > wrote:
> > >> >> > >>> > >> > >
> > >> >> > >>> > >> > > > I mean Christopher.
> > >> >> > >>> > >> > > >
> > >> >> > >>> > >> > > > Thanks again.
> > >> >> > >>> > >> > > >
> > >> >> > >>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
> > >> >> > >>> > >> > > vincent.russell@gmail.com>
> > >> >> > >>> > >> > > > wrote:
> > >> >> > >>> > >> > > >
> > >> >> > >>> > >> > > >> Thank you Chris.
> > >> >> > >>> > >> > > >>
> > >> >> > >>> > >> > > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper
> > 3.7
> > >> or
> > >> >> > >>> later as
> > >> >> > >>> > >> soon as
> > >> >> > >>> > >> > > >> possible.
> > >> >> > >>> > >> > > >>
> > >> >> > >>> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <
> > >> >> > >>> ctubbsii@apache.org>
> > >> >> > >>> > >> wrote:
> > >> >> > >>> > >> > > >>
> > >> >> > >>> > >> > > >>> Hi Vincent,
> > >> >> > >>> > >> > > >>>
> > >> >> > >>> > >> > > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM
> > >> >> release,
> > >> >> > >>> and 2.0
> > >> >> > >>> > >> is
> > >> >> > >>> > >> > > >>> not expected to receive any further updates.
> > Version
> > >> >> 2.1.0
> > >> >> > >>> may
> > >> >> > >>> > >> work
> > >> >> > >>> > >> > > >>> with ZooKeeper 3.4, but was developed and tested
> > >> >> against
> > >> >> > >>> 3.5 and
> > >> >> > >>> > >> later
> > >> >> > >>> > >> > > >>> versions. I believe the ZooKeeper community is
> > >> >> currently
> > >> >> > >>> > >> considering
> > >> >> > >>> > >> > > >>> whether to make 3.6 end-of-life themselves, so I
> > >> would
> > >> >> > >>> recommend
> > >> >> > >>> > >> using
> > >> >> > >>> > >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or
> > >> later
> > >> >> to
> > >> >> > >>> have the
> > >> >> > >>> > >> best
> > >> >> > >>> > >> > > >>> chance of any kind of support, including JDK 17
> > >> >> support.
> > >> >> > >>> > >> > > >>>
> > >> >> > >>> > >> > > >>> As for your specific issues:
> > >> >> > >>> > >> > > >>>
> > >> >> > >>> > >> > > >>> 1. This is already fixed in 2.1.0
> > >> >> > >>> > >> > > >>> 2/3. These issues are likely fixed in newer
> > >> ZooKeeper
> > >> >> > >>> versions. I
> > >> >> > >>> > >> > > >>> haven't seen them anytime recently, anyway. Bugs
> > in
> > >> >> > >>> ZooKeeper
> > >> >> > >>> > >> itself
> > >> >> > >>> > >> > > >>> are out of scope for the Accumulo developers, but
> > I
> > >> >> have
> > >> >> > >>> tried
> > >> >> > >>> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper
> > >> >> 3.8.0 and
> > >> >> > >>> > >> haven't
> > >> >> > >>> > >> > > >>> observed any unresolved issues. However, it's
> > >> >> difficult to
> > >> >> > >>> > >> actually
> > >> >> > >>> > >> > > >>> run it because I don't think Hadoop has good JDK
> > 17
> > >> >> support
> > >> >> > >>> yet.
> > >> >> > >>> > >> So,
> > >> >> > >>> > >> > > >>> MiniAccumuloCluster seems to work with JDK 17, as
> > >> does
> > >> >> > >>> Accumulo
> > >> >> > >>> > >> and ZK
> > >> >> > >>> > >> > > >>> 3.8, but I don't think a full Hadoop cluster would
> > >> >> (yet).
> > >> >> > >>> > >> > > >>>
> > >> >> > >>> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
> > >> >> > >>> > >> > > >>> <vi...@gmail.com> wrote:
> > >> >> > >>> > >> > > >>> >
> > >> >> > >>> > >> > > >>> > Hello,
> > >> >> > >>> > >> > > >>> >
> > >> >> > >>> > >> > > >>> > We are currently using accumulo 2.0.1.
> > >> >> > >>> > >> > > >>> >
> > >> >> > >>> > >> > > >>> > We are in the process of upgrading our source
> > code
> > >> >> to use
> > >> >> > >>> jdk 17
> > >> >> > >>> > >> > > >>> however we
> > >> >> > >>> > >> > > >>> > are running into some problems with our tests
> > and
> > >> the
> > >> >> > >>> > >> > > >>> MiniAccumuloCluster.
> > >> >> > >>> > >> > > >>> >
> > >> >> > >>> > >> > > >>> > One of our developer encountered the following
> > >> >> issues:
> > >> >> > >>> > >> > > >>> >
> > >> >> > >>> > >> > > >>> >    1. The MiniAccumumluoClusterImpl._exec is
> > >> >> hardcoded
> > >> >> > >>> with the
> > >> >> > >>> > >> JVM
> > >> >> > >>> > >> > > arg
> > >> >> > >>> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no longer
> > >> >> tolerated
> > >> >> > >>> with
> > >> >> > >>> > >> JDK17.
> > >> >> > >>> > >> > > >>> >    2. In Zookeeper 3.4.14, ConetStringParser
> > uses
> > >> >> > >>> > >> createUnresolved to
> > >> >> > >>> > >> > > >>> >    make IPAddresses.
> > >> >> > >>> > >> > > >>>
> > >> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> > >> >> > >>> > >> > > >>> >    uses InetSocketAddess.getAddress, which
> > returns
> > >> >> null
> > >> >> > >>> because
> > >> >> > >>> > >> it's
> > >> >> > >>> > >> > > >>> not
> > >> >> > >>> > >> > > >>> >    resolved, resulting in a failure to connect
> > to
> > >> the
> > >> >> > >>> > >> newly-started
> > >> >> > >>> > >> > > >>> zookeeper.
> > >> >> > >>> > >> > > >>> >    3. StaticHostProvider.getHostString() tries
> > to
> > >> >> extract
> > >> >> > >>> he
> > >> >> > >>> > >> hostname
> > >> >> > >>> > >> > > >>> by
> > >> >> > >>> > >> > > >>> >    calling toString on the address and taking
> > >> >> everything
> > >> >> > >>> before
> > >> >> > >>> > >> the
> > >> >> > >>> > >> > > >>> colon, but
> > >> >> > >>> > >> > > >>> >    in JDK17, the string format changed to
> > >> >> > >>> > >> > > "localhost/<unresolved->:xx"
> > >> >> > >>> > >> > > >>> (where
> > >> >> > >>> > >> > > >>> >    XX is still the port number).  That's
> > incorrect
> > >> >> and it
> > >> >> > >>> can't
> > >> >> > >>> > >> > > >>> resolve the
> > >> >> > >>> > >> > > >>> >    names.
> > >> >> > >>> > >> > > >>> >
> > >> >> > >>> > >> > > >>> >
> > >> >> > >>> > >> > > >>> > Has anyone come across/resolved these kinds of
> > >> >> issues?
> > >> >> > >>> Is it
> > >> >> > >>> > >> not
> > >> >> > >>> > >> > > >>> possible
> > >> >> > >>> > >> > > >>> > to use java17 from a client perspective?  Will
> > >> >> upgrading
> > >> >> > >>> to
> > >> >> > >>> > >> accumulo
> > >> >> > >>> > >> > > >>> 2.1
> > >> >> > >>> > >> > > >>> > help?
> > >> >> > >>> > >> > > >>> >
> > >> >> > >>> > >> > > >>> > Thanks,
> > >> >> > >>> > >> > > >>> > Vincent
> > >> >> > >>> > >> > > >>>
> > >> >> > >>> > >> > > >>
> > >> >> > >>> > >> > >
> > >> >> > >>> > >>
> > >> >> > >>> > >
> > >> >> > >>>
> > >> >> > >>
> > >> >>
> > >> >
> > >>
> > >
> >

Re: jdk 17 and accumulo testing

Posted by Christopher Shannon <ch...@gmail.com>.
Version 2.1.1 will be released with bug fixes and this fix (when finished
and merged) is planned to be included as part of that release. I don't know
the exact time frame yet though.

On Fri, Dec 30, 2022 at 11:04 AM Vincent Russell <vi...@gmail.com>
wrote:

> Hello,
>
> Are there any plans to release an accumulo 2.1 patch to fix this issue?
>
> Thanks,
>
> On Sat, Dec 17, 2022 at 7:36 PM Vincent Russell <vincent.russell@gmail.com
> >
> wrote:
>
> > No worries.  I'm glad I was able to help in some small way.
> >
> > Thank you for fixing the issue.
> >
> > On Sat, Dec 17, 2022 at 11:49 AM Christopher Shannon <
> > christopher.l.shannon@gmail.com> wrote:
> >
> >> I created https://github.com/apache/accumulo/pull/3134 and that should
> >> fix
> >> this issue.
> >>
> >> Thanks Vincent for pointing out the issue in TServerUtils, your testing
> >> made this easy to track down and fix.
> >>
> >>
> >> On Sat, Dec 17, 2022 at 9:00 AM Christopher Shannon <
> >> christopher.l.shannon@gmail.com> wrote:
> >>
> >> > I was able to reproduce the issue by setting the value size for a
> >> mutation
> >> > to size 16384001 to make sure it's greater than the default value for
> >> > Thrift and it fails immediately. I will work on a fix now that we know
> >> how
> >> > to reproduce it.
> >> >
> >> > On Fri, Dec 16, 2022 at 2:31 PM Christopher <ct...@apache.org>
> >> wrote:
> >> >
> >> >> I don't think it's intentional. This might be the source of the
> >> problem.
> >> >>
> >> >> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
> >> >> <vi...@gmail.com> wrote:
> >> >> >
> >> >> > Also in TserverUtils:270, when the TNonblockingServerSocket is
> >> created
> >> >> it
> >> >> > looks like it ends up using the default frame size.  I am not sure
> if
> >> >> this
> >> >> > is intentional or not.
> >> >> >
> >> >> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
> >> >> vincent.russell@gmail.com>
> >> >> > wrote:
> >> >> >
> >> >> > > Christopher,
> >> >> > >
> >> >> > > I am not sure if this issue is related to 3042 or not.
> >> >> > >
> >> >> > > On the client side it does look like TConfiguration ends up being
> >> >> called
> >> >> > > with the default constructor.  I am not sure if this is
> intentional
> >> >> or not.
> >> >> > >
> >> >> > > On the server side I see this stack, so it also looks like:
> >> >> > >
> >> >> > > at
> org.apache.thrift.TConfiguration.<init>(TConfiguration.java:36)
> >> >> > > at
> >> >>
> org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
> >> >> > > at
> >> org.apache.thrift.TConfiguration.<clinit>(TConfiguration.java:65)
> >> >> > > at
> >> >> > >
> >> >>
> >>
> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:74)
> >> >> > > at
> >> >> > >
> >> >>
> >>
> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:68)
> >> >> > > at
> >> >> > >
> >> >>
> >>
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
> >> >> > > at
> >> >> > >
> >> >>
> >>
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
> >> >> > > at
> >> >> > >
> >> >>
> >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
> >> >> > > at
> >> >> > >
> >> >>
> >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
> >> >> > > at
> >> >> > >
> >> >>
> >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> >> >> > >
> >> >> > >
> >> >> > > I see this in the server log so it does look like it should be
> >> using
> >> >> 1G:
> >> >> > > 2022-09-01 16:59:41 INFO
> >> [org.apache.accumulo.tserver.TabletServer]
> >> >> > > ServerUtil:124 - general.server.message.size.max = 1G
> >> >> > >
> >> >> > > Thanks,
> >> >> > > Vincent
> >> >> > >
> >> >> > > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
> >> >> > > vincent.russell@gmail.com> wrote:
> >> >> > >
> >> >> > >>
> >> >> > >>
> >> >> > >> I had to make a stack trace with hacking together a remote debug
> >> >> instance:
> >> >> > >>
> >> >> > >> at
> >> >> > >>
> >> >>
> >>
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
> >> >> > >> at
> >> >> > >>
> >> >>
> >>
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
> >> >> > >> at
> >> >> > >>
> >> >>
> >>
> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
> >> >> > >> at
> >> >> > >>
> >> >>
> >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
> >> >> > >> at
> >> >> > >>
> >> >>
> >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> >> >> > >>
> >> >> > >> On Thu, Dec 15, 2022 at 12:52 AM Christopher <
> ctubbsii@apache.org
> >> >
> >> >> wrote:
> >> >> > >>
> >> >> > >>> From the numbers in the message, it looks like you're sending
> an
> >> >> 18MB
> >> >> > >>> payload but something in Thrift is limiting things to 16384000
> >> >> > >>> (16000KB). I doubt you've overridden the default
> >> >> > >>> general.server.message.size.max to be anything that low (the
> >> default
> >> >> > >>> is 1G). Unless you're flushing after every mutation, it would
> >> not be
> >> >> > >>> surprising to exceed the 16MB max frame size indicated in the
> >> error
> >> >> > >>> message quite quickly.
> >> >> > >>>
> >> >> > >>> This value of 16384000 seemed weird. It looks like it's not
> using
> >> >> our
> >> >> > >>> configuration, but using the built-in default value of
> >> >> > >>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It
> looks
> >> >> like
> >> >> > >>> this can happen whenever `new TConfiguration()` is called
> without
> >> >> > >>> parameters... and there's a fair amount of internal code,
> mostly
> >> in
> >> >> > >>> libthrift itself, that does that. It's a bit tricky to track
> down
> >> >> the
> >> >> > >>> one causing this particular issue. If you have a full stack
> >> trace,
> >> >> it
> >> >> > >>> could help.
> >> >> > >>>
> >> >> > >>> Also, this might be the same issue seen reported in
> >> >> > >>> https://github.com/apache/accumulo/issues/3042
> >> >> > >>>
> >> >> > >>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
> >> >> > >>> <vi...@gmail.com> wrote:
> >> >> > >>> >
> >> >> > >>> > I was able to work out all of my compilation issues; however
> >> when
> >> >> I
> >> >> > >>> run an
> >> >> > >>> > integration test with the Mini Accumulo Cluster that tests
> >> writing
> >> >> > >>> > mutations with values of 5mb the flush hangs forever
> >> >> > >>> > and I see  the following logs in the TabletServer logs:
> >> >> > >>> >
> >> >> > >>> > 20:41:02.306 [Thread-7] ERROR
> >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a
> >> frame
> >> >> > >>> size of
> >> >> > >>> > 18874697, which is bigger than the maximum allowable frame
> size
> >> >> > >>> 16384000
> >> >> > >>> > for ALL connections.
> >> >> > >>> > 20:41:03.582 [Thread-7] ERROR
> >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a
> >> frame
> >> >> > >>> size of
> >> >> > >>> > 18874697, which is bigger than the maximum allowable frame
> size
> >> >> > >>> 16384000
> >> >> > >>> > for ALL connections.
> >> >> > >>> > 20:41:05.079 [Thread-7] ERROR
> >> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a
> >> frame
> >> >> > >>> size of
> >> >> > >>> > 18874697, which is bigger than the maximum allowable frame
> size
> >> >> > >>> 16384000
> >> >> > >>> > for ALL connections.
> >> >> > >>> >
> >> >> > >>> > Other tests that write smaller amounts of data appear to work
> >> >> fine.
> >> >> > >>> >
> >> >> > >>> > Any idea what the issue might be?
> >> >> > >>> >
> >> >> > >>> > Thank you,
> >> >> > >>> > Vincent
> >> >> > >>> >
> >> >> > >>> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
> >> >> > >>> vincent.russell@gmail.com>
> >> >> > >>> > wrote:
> >> >> > >>> >
> >> >> > >>> > > Thank you both for your responses.
> >> >> > >>> > >
> >> >> > >>> > > We are using an event store library from a sister project
> >> that
> >> >> was
> >> >> > >>> written
> >> >> > >>> > > for accumulo 1.10., which I have already upgraded to 2.0.
> >> >> > >>> > >
> >> >> > >>> > > I'll spend some time investigating how bad the usage of the
> >> >> internal
> >> >> > >>> > > packages are and get back to you.
> >> >> > >>> > >
> >> >> > >>> > > Thanks again,
> >> >> > >>> > >
> >> >> > >>> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <
> >> >> ctubbsii@apache.org>
> >> >> > >>> wrote:
> >> >> > >>> > >
> >> >> > >>> > >> To add to Dave's answer, the public API is defined at
> >> >> > >>> > >> https://accumulo.apache.org/api/
> >> >> > >>> > >> Anything else is not public and is subject to change
> without
> >> >> notice
> >> >> > >>> on
> >> >> > >>> > >> any release without any attempt to retain compatibility.
> >> >> > >>> > >>
> >> >> > >>> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <
> >> >> dmarion18@gmail.com>
> >> >> > >>> wrote:
> >> >> > >>> > >> >
> >> >> > >>> > >> > There is no guide. You are using implementation classes
> >> (see
> >> >> > >>> clientImpl
> >> >> > >>> > >> in
> >> >> > >>> > >> > the package name) vs. using the client api. If you can
> use
> >> >> the
> >> >> > >>> client
> >> >> > >>> > >> api
> >> >> > >>> > >> > directly, then this should insulate you from changes in
> >> the
> >> >> future
> >> >> > >>> > >> (except
> >> >> > >>> > >> > during major versions). We can try and find where things
> >> >> might
> >> >> > >>> have
> >> >> > >>> > >> moved,
> >> >> > >>> > >> > but a class may have been split into multiple pieces. If
> >> you
> >> >> could
> >> >> > >>> > >> provide
> >> >> > >>> > >> > class and method, that would be easier.
> >> >> > >>> > >> >
> >> >> > >>> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
> >> >> > >>> > >> vincent.russell@gmail.com>
> >> >> > >>> > >> > wrote:
> >> >> > >>> > >> >
> >> >> > >>> > >> > > Is there a guide that shows where classes may have
> been
> >> >> moved
> >> >> > >>> with
> >> >> > >>> > >> moving
> >> >> > >>> > >> > > from 2.0 to 2.1?  For instance, I am having issues
> >> >> compiling,
> >> >> > >>> because
> >> >> > >>> > >> the
> >> >> > >>> > >> > > following class doesn't exist:
> >> >> > >>> > >> > > import org.apache.accumulo.core.clientImpl.Tables;
> >> >> > >>> > >> > >
> >> >> > >>> > >> > > I'm just getting started so I'm sure there are others.
> >> >> > >>> > >> > >
> >> >> > >>> > >> > > Thanks,
> >> >> > >>> > >> > > Vincent
> >> >> > >>> > >> > >
> >> >> > >>> > >> > >
> >> >> > >>> > >> > >
> >> >> > >>> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
> >> >> > >>> > >> vincent.russell@gmail.com>
> >> >> > >>> > >> > > wrote:
> >> >> > >>> > >> > >
> >> >> > >>> > >> > > > I mean Christopher.
> >> >> > >>> > >> > > >
> >> >> > >>> > >> > > > Thanks again.
> >> >> > >>> > >> > > >
> >> >> > >>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
> >> >> > >>> > >> > > vincent.russell@gmail.com>
> >> >> > >>> > >> > > > wrote:
> >> >> > >>> > >> > > >
> >> >> > >>> > >> > > >> Thank you Chris.
> >> >> > >>> > >> > > >>
> >> >> > >>> > >> > > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper
> 3.7
> >> or
> >> >> > >>> later as
> >> >> > >>> > >> soon as
> >> >> > >>> > >> > > >> possible.
> >> >> > >>> > >> > > >>
> >> >> > >>> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <
> >> >> > >>> ctubbsii@apache.org>
> >> >> > >>> > >> wrote:
> >> >> > >>> > >> > > >>
> >> >> > >>> > >> > > >>> Hi Vincent,
> >> >> > >>> > >> > > >>>
> >> >> > >>> > >> > > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM
> >> >> release,
> >> >> > >>> and 2.0
> >> >> > >>> > >> is
> >> >> > >>> > >> > > >>> not expected to receive any further updates.
> Version
> >> >> 2.1.0
> >> >> > >>> may
> >> >> > >>> > >> work
> >> >> > >>> > >> > > >>> with ZooKeeper 3.4, but was developed and tested
> >> >> against
> >> >> > >>> 3.5 and
> >> >> > >>> > >> later
> >> >> > >>> > >> > > >>> versions. I believe the ZooKeeper community is
> >> >> currently
> >> >> > >>> > >> considering
> >> >> > >>> > >> > > >>> whether to make 3.6 end-of-life themselves, so I
> >> would
> >> >> > >>> recommend
> >> >> > >>> > >> using
> >> >> > >>> > >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or
> >> later
> >> >> to
> >> >> > >>> have the
> >> >> > >>> > >> best
> >> >> > >>> > >> > > >>> chance of any kind of support, including JDK 17
> >> >> support.
> >> >> > >>> > >> > > >>>
> >> >> > >>> > >> > > >>> As for your specific issues:
> >> >> > >>> > >> > > >>>
> >> >> > >>> > >> > > >>> 1. This is already fixed in 2.1.0
> >> >> > >>> > >> > > >>> 2/3. These issues are likely fixed in newer
> >> ZooKeeper
> >> >> > >>> versions. I
> >> >> > >>> > >> > > >>> haven't seen them anytime recently, anyway. Bugs
> in
> >> >> > >>> ZooKeeper
> >> >> > >>> > >> itself
> >> >> > >>> > >> > > >>> are out of scope for the Accumulo developers, but
> I
> >> >> have
> >> >> > >>> tried
> >> >> > >>> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper
> >> >> 3.8.0 and
> >> >> > >>> > >> haven't
> >> >> > >>> > >> > > >>> observed any unresolved issues. However, it's
> >> >> difficult to
> >> >> > >>> > >> actually
> >> >> > >>> > >> > > >>> run it because I don't think Hadoop has good JDK
> 17
> >> >> support
> >> >> > >>> yet.
> >> >> > >>> > >> So,
> >> >> > >>> > >> > > >>> MiniAccumuloCluster seems to work with JDK 17, as
> >> does
> >> >> > >>> Accumulo
> >> >> > >>> > >> and ZK
> >> >> > >>> > >> > > >>> 3.8, but I don't think a full Hadoop cluster would
> >> >> (yet).
> >> >> > >>> > >> > > >>>
> >> >> > >>> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
> >> >> > >>> > >> > > >>> <vi...@gmail.com> wrote:
> >> >> > >>> > >> > > >>> >
> >> >> > >>> > >> > > >>> > Hello,
> >> >> > >>> > >> > > >>> >
> >> >> > >>> > >> > > >>> > We are currently using accumulo 2.0.1.
> >> >> > >>> > >> > > >>> >
> >> >> > >>> > >> > > >>> > We are in the process of upgrading our source
> code
> >> >> to use
> >> >> > >>> jdk 17
> >> >> > >>> > >> > > >>> however we
> >> >> > >>> > >> > > >>> > are running into some problems with our tests
> and
> >> the
> >> >> > >>> > >> > > >>> MiniAccumuloCluster.
> >> >> > >>> > >> > > >>> >
> >> >> > >>> > >> > > >>> > One of our developer encountered the following
> >> >> issues:
> >> >> > >>> > >> > > >>> >
> >> >> > >>> > >> > > >>> >    1. The MiniAccumumluoClusterImpl._exec is
> >> >> hardcoded
> >> >> > >>> with the
> >> >> > >>> > >> JVM
> >> >> > >>> > >> > > arg
> >> >> > >>> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no longer
> >> >> tolerated
> >> >> > >>> with
> >> >> > >>> > >> JDK17.
> >> >> > >>> > >> > > >>> >    2. In Zookeeper 3.4.14, ConetStringParser
> uses
> >> >> > >>> > >> createUnresolved to
> >> >> > >>> > >> > > >>> >    make IPAddresses.
> >> >> > >>> > >> > > >>>
> >> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> >> >> > >>> > >> > > >>> >    uses InetSocketAddess.getAddress, which
> returns
> >> >> null
> >> >> > >>> because
> >> >> > >>> > >> it's
> >> >> > >>> > >> > > >>> not
> >> >> > >>> > >> > > >>> >    resolved, resulting in a failure to connect
> to
> >> the
> >> >> > >>> > >> newly-started
> >> >> > >>> > >> > > >>> zookeeper.
> >> >> > >>> > >> > > >>> >    3. StaticHostProvider.getHostString() tries
> to
> >> >> extract
> >> >> > >>> he
> >> >> > >>> > >> hostname
> >> >> > >>> > >> > > >>> by
> >> >> > >>> > >> > > >>> >    calling toString on the address and taking
> >> >> everything
> >> >> > >>> before
> >> >> > >>> > >> the
> >> >> > >>> > >> > > >>> colon, but
> >> >> > >>> > >> > > >>> >    in JDK17, the string format changed to
> >> >> > >>> > >> > > "localhost/<unresolved->:xx"
> >> >> > >>> > >> > > >>> (where
> >> >> > >>> > >> > > >>> >    XX is still the port number).  That's
> incorrect
> >> >> and it
> >> >> > >>> can't
> >> >> > >>> > >> > > >>> resolve the
> >> >> > >>> > >> > > >>> >    names.
> >> >> > >>> > >> > > >>> >
> >> >> > >>> > >> > > >>> >
> >> >> > >>> > >> > > >>> > Has anyone come across/resolved these kinds of
> >> >> issues?
> >> >> > >>> Is it
> >> >> > >>> > >> not
> >> >> > >>> > >> > > >>> possible
> >> >> > >>> > >> > > >>> > to use java17 from a client perspective?  Will
> >> >> upgrading
> >> >> > >>> to
> >> >> > >>> > >> accumulo
> >> >> > >>> > >> > > >>> 2.1
> >> >> > >>> > >> > > >>> > help?
> >> >> > >>> > >> > > >>> >
> >> >> > >>> > >> > > >>> > Thanks,
> >> >> > >>> > >> > > >>> > Vincent
> >> >> > >>> > >> > > >>>
> >> >> > >>> > >> > > >>
> >> >> > >>> > >> > >
> >> >> > >>> > >>
> >> >> > >>> > >
> >> >> > >>>
> >> >> > >>
> >> >>
> >> >
> >>
> >
>

Re: jdk 17 and accumulo testing

Posted by Vincent Russell <vi...@gmail.com>.
Hello,

Are there any plans to release an accumulo 2.1 patch to fix this issue?

Thanks,

On Sat, Dec 17, 2022 at 7:36 PM Vincent Russell <vi...@gmail.com>
wrote:

> No worries.  I'm glad I was able to help in some small way.
>
> Thank you for fixing the issue.
>
> On Sat, Dec 17, 2022 at 11:49 AM Christopher Shannon <
> christopher.l.shannon@gmail.com> wrote:
>
>> I created https://github.com/apache/accumulo/pull/3134 and that should
>> fix
>> this issue.
>>
>> Thanks Vincent for pointing out the issue in TServerUtils, your testing
>> made this easy to track down and fix.
>>
>>
>> On Sat, Dec 17, 2022 at 9:00 AM Christopher Shannon <
>> christopher.l.shannon@gmail.com> wrote:
>>
>> > I was able to reproduce the issue by setting the value size for a
>> mutation
>> > to size 16384001 to make sure it's greater than the default value for
>> > Thrift and it fails immediately. I will work on a fix now that we know
>> how
>> > to reproduce it.
>> >
>> > On Fri, Dec 16, 2022 at 2:31 PM Christopher <ct...@apache.org>
>> wrote:
>> >
>> >> I don't think it's intentional. This might be the source of the
>> problem.
>> >>
>> >> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
>> >> <vi...@gmail.com> wrote:
>> >> >
>> >> > Also in TserverUtils:270, when the TNonblockingServerSocket is
>> created
>> >> it
>> >> > looks like it ends up using the default frame size.  I am not sure if
>> >> this
>> >> > is intentional or not.
>> >> >
>> >> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
>> >> vincent.russell@gmail.com>
>> >> > wrote:
>> >> >
>> >> > > Christopher,
>> >> > >
>> >> > > I am not sure if this issue is related to 3042 or not.
>> >> > >
>> >> > > On the client side it does look like TConfiguration ends up being
>> >> called
>> >> > > with the default constructor.  I am not sure if this is intentional
>> >> or not.
>> >> > >
>> >> > > On the server side I see this stack, so it also looks like:
>> >> > >
>> >> > > at org.apache.thrift.TConfiguration.<init>(TConfiguration.java:36)
>> >> > > at
>> >> org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
>> >> > > at
>> org.apache.thrift.TConfiguration.<clinit>(TConfiguration.java:65)
>> >> > > at
>> >> > >
>> >>
>> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:74)
>> >> > > at
>> >> > >
>> >>
>> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:68)
>> >> > > at
>> >> > >
>> >>
>> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
>> >> > > at
>> >> > >
>> >>
>> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
>> >> > > at
>> >> > >
>> >>
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
>> >> > > at
>> >> > >
>> >>
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
>> >> > > at
>> >> > >
>> >>
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
>> >> > >
>> >> > >
>> >> > > I see this in the server log so it does look like it should be
>> using
>> >> 1G:
>> >> > > 2022-09-01 16:59:41 INFO
>> [org.apache.accumulo.tserver.TabletServer]
>> >> > > ServerUtil:124 - general.server.message.size.max = 1G
>> >> > >
>> >> > > Thanks,
>> >> > > Vincent
>> >> > >
>> >> > > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
>> >> > > vincent.russell@gmail.com> wrote:
>> >> > >
>> >> > >>
>> >> > >>
>> >> > >> I had to make a stack trace with hacking together a remote debug
>> >> instance:
>> >> > >>
>> >> > >> at
>> >> > >>
>> >>
>> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
>> >> > >> at
>> >> > >>
>> >>
>> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
>> >> > >> at
>> >> > >>
>> >>
>> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
>> >> > >> at
>> >> > >>
>> >>
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
>> >> > >> at
>> >> > >>
>> >>
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
>> >> > >>
>> >> > >> On Thu, Dec 15, 2022 at 12:52 AM Christopher <ctubbsii@apache.org
>> >
>> >> wrote:
>> >> > >>
>> >> > >>> From the numbers in the message, it looks like you're sending an
>> >> 18MB
>> >> > >>> payload but something in Thrift is limiting things to 16384000
>> >> > >>> (16000KB). I doubt you've overridden the default
>> >> > >>> general.server.message.size.max to be anything that low (the
>> default
>> >> > >>> is 1G). Unless you're flushing after every mutation, it would
>> not be
>> >> > >>> surprising to exceed the 16MB max frame size indicated in the
>> error
>> >> > >>> message quite quickly.
>> >> > >>>
>> >> > >>> This value of 16384000 seemed weird. It looks like it's not using
>> >> our
>> >> > >>> configuration, but using the built-in default value of
>> >> > >>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It looks
>> >> like
>> >> > >>> this can happen whenever `new TConfiguration()` is called without
>> >> > >>> parameters... and there's a fair amount of internal code, mostly
>> in
>> >> > >>> libthrift itself, that does that. It's a bit tricky to track down
>> >> the
>> >> > >>> one causing this particular issue. If you have a full stack
>> trace,
>> >> it
>> >> > >>> could help.
>> >> > >>>
>> >> > >>> Also, this might be the same issue seen reported in
>> >> > >>> https://github.com/apache/accumulo/issues/3042
>> >> > >>>
>> >> > >>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
>> >> > >>> <vi...@gmail.com> wrote:
>> >> > >>> >
>> >> > >>> > I was able to work out all of my compilation issues; however
>> when
>> >> I
>> >> > >>> run an
>> >> > >>> > integration test with the Mini Accumulo Cluster that tests
>> writing
>> >> > >>> > mutations with values of 5mb the flush hangs forever
>> >> > >>> > and I see  the following logs in the TabletServer logs:
>> >> > >>> >
>> >> > >>> > 20:41:02.306 [Thread-7] ERROR
>> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a
>> frame
>> >> > >>> size of
>> >> > >>> > 18874697, which is bigger than the maximum allowable frame size
>> >> > >>> 16384000
>> >> > >>> > for ALL connections.
>> >> > >>> > 20:41:03.582 [Thread-7] ERROR
>> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a
>> frame
>> >> > >>> size of
>> >> > >>> > 18874697, which is bigger than the maximum allowable frame size
>> >> > >>> 16384000
>> >> > >>> > for ALL connections.
>> >> > >>> > 20:41:05.079 [Thread-7] ERROR
>> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a
>> frame
>> >> > >>> size of
>> >> > >>> > 18874697, which is bigger than the maximum allowable frame size
>> >> > >>> 16384000
>> >> > >>> > for ALL connections.
>> >> > >>> >
>> >> > >>> > Other tests that write smaller amounts of data appear to work
>> >> fine.
>> >> > >>> >
>> >> > >>> > Any idea what the issue might be?
>> >> > >>> >
>> >> > >>> > Thank you,
>> >> > >>> > Vincent
>> >> > >>> >
>> >> > >>> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
>> >> > >>> vincent.russell@gmail.com>
>> >> > >>> > wrote:
>> >> > >>> >
>> >> > >>> > > Thank you both for your responses.
>> >> > >>> > >
>> >> > >>> > > We are using an event store library from a sister project
>> that
>> >> was
>> >> > >>> written
>> >> > >>> > > for accumulo 1.10., which I have already upgraded to 2.0.
>> >> > >>> > >
>> >> > >>> > > I'll spend some time investigating how bad the usage of the
>> >> internal
>> >> > >>> > > packages are and get back to you.
>> >> > >>> > >
>> >> > >>> > > Thanks again,
>> >> > >>> > >
>> >> > >>> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <
>> >> ctubbsii@apache.org>
>> >> > >>> wrote:
>> >> > >>> > >
>> >> > >>> > >> To add to Dave's answer, the public API is defined at
>> >> > >>> > >> https://accumulo.apache.org/api/
>> >> > >>> > >> Anything else is not public and is subject to change without
>> >> notice
>> >> > >>> on
>> >> > >>> > >> any release without any attempt to retain compatibility.
>> >> > >>> > >>
>> >> > >>> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <
>> >> dmarion18@gmail.com>
>> >> > >>> wrote:
>> >> > >>> > >> >
>> >> > >>> > >> > There is no guide. You are using implementation classes
>> (see
>> >> > >>> clientImpl
>> >> > >>> > >> in
>> >> > >>> > >> > the package name) vs. using the client api. If you can use
>> >> the
>> >> > >>> client
>> >> > >>> > >> api
>> >> > >>> > >> > directly, then this should insulate you from changes in
>> the
>> >> future
>> >> > >>> > >> (except
>> >> > >>> > >> > during major versions). We can try and find where things
>> >> might
>> >> > >>> have
>> >> > >>> > >> moved,
>> >> > >>> > >> > but a class may have been split into multiple pieces. If
>> you
>> >> could
>> >> > >>> > >> provide
>> >> > >>> > >> > class and method, that would be easier.
>> >> > >>> > >> >
>> >> > >>> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
>> >> > >>> > >> vincent.russell@gmail.com>
>> >> > >>> > >> > wrote:
>> >> > >>> > >> >
>> >> > >>> > >> > > Is there a guide that shows where classes may have been
>> >> moved
>> >> > >>> with
>> >> > >>> > >> moving
>> >> > >>> > >> > > from 2.0 to 2.1?  For instance, I am having issues
>> >> compiling,
>> >> > >>> because
>> >> > >>> > >> the
>> >> > >>> > >> > > following class doesn't exist:
>> >> > >>> > >> > > import org.apache.accumulo.core.clientImpl.Tables;
>> >> > >>> > >> > >
>> >> > >>> > >> > > I'm just getting started so I'm sure there are others.
>> >> > >>> > >> > >
>> >> > >>> > >> > > Thanks,
>> >> > >>> > >> > > Vincent
>> >> > >>> > >> > >
>> >> > >>> > >> > >
>> >> > >>> > >> > >
>> >> > >>> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
>> >> > >>> > >> vincent.russell@gmail.com>
>> >> > >>> > >> > > wrote:
>> >> > >>> > >> > >
>> >> > >>> > >> > > > I mean Christopher.
>> >> > >>> > >> > > >
>> >> > >>> > >> > > > Thanks again.
>> >> > >>> > >> > > >
>> >> > >>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
>> >> > >>> > >> > > vincent.russell@gmail.com>
>> >> > >>> > >> > > > wrote:
>> >> > >>> > >> > > >
>> >> > >>> > >> > > >> Thank you Chris.
>> >> > >>> > >> > > >>
>> >> > >>> > >> > > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7
>> or
>> >> > >>> later as
>> >> > >>> > >> soon as
>> >> > >>> > >> > > >> possible.
>> >> > >>> > >> > > >>
>> >> > >>> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <
>> >> > >>> ctubbsii@apache.org>
>> >> > >>> > >> wrote:
>> >> > >>> > >> > > >>
>> >> > >>> > >> > > >>> Hi Vincent,
>> >> > >>> > >> > > >>>
>> >> > >>> > >> > > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM
>> >> release,
>> >> > >>> and 2.0
>> >> > >>> > >> is
>> >> > >>> > >> > > >>> not expected to receive any further updates. Version
>> >> 2.1.0
>> >> > >>> may
>> >> > >>> > >> work
>> >> > >>> > >> > > >>> with ZooKeeper 3.4, but was developed and tested
>> >> against
>> >> > >>> 3.5 and
>> >> > >>> > >> later
>> >> > >>> > >> > > >>> versions. I believe the ZooKeeper community is
>> >> currently
>> >> > >>> > >> considering
>> >> > >>> > >> > > >>> whether to make 3.6 end-of-life themselves, so I
>> would
>> >> > >>> recommend
>> >> > >>> > >> using
>> >> > >>> > >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or
>> later
>> >> to
>> >> > >>> have the
>> >> > >>> > >> best
>> >> > >>> > >> > > >>> chance of any kind of support, including JDK 17
>> >> support.
>> >> > >>> > >> > > >>>
>> >> > >>> > >> > > >>> As for your specific issues:
>> >> > >>> > >> > > >>>
>> >> > >>> > >> > > >>> 1. This is already fixed in 2.1.0
>> >> > >>> > >> > > >>> 2/3. These issues are likely fixed in newer
>> ZooKeeper
>> >> > >>> versions. I
>> >> > >>> > >> > > >>> haven't seen them anytime recently, anyway. Bugs in
>> >> > >>> ZooKeeper
>> >> > >>> > >> itself
>> >> > >>> > >> > > >>> are out of scope for the Accumulo developers, but I
>> >> have
>> >> > >>> tried
>> >> > >>> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper
>> >> 3.8.0 and
>> >> > >>> > >> haven't
>> >> > >>> > >> > > >>> observed any unresolved issues. However, it's
>> >> difficult to
>> >> > >>> > >> actually
>> >> > >>> > >> > > >>> run it because I don't think Hadoop has good JDK 17
>> >> support
>> >> > >>> yet.
>> >> > >>> > >> So,
>> >> > >>> > >> > > >>> MiniAccumuloCluster seems to work with JDK 17, as
>> does
>> >> > >>> Accumulo
>> >> > >>> > >> and ZK
>> >> > >>> > >> > > >>> 3.8, but I don't think a full Hadoop cluster would
>> >> (yet).
>> >> > >>> > >> > > >>>
>> >> > >>> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
>> >> > >>> > >> > > >>> <vi...@gmail.com> wrote:
>> >> > >>> > >> > > >>> >
>> >> > >>> > >> > > >>> > Hello,
>> >> > >>> > >> > > >>> >
>> >> > >>> > >> > > >>> > We are currently using accumulo 2.0.1.
>> >> > >>> > >> > > >>> >
>> >> > >>> > >> > > >>> > We are in the process of upgrading our source code
>> >> to use
>> >> > >>> jdk 17
>> >> > >>> > >> > > >>> however we
>> >> > >>> > >> > > >>> > are running into some problems with our tests and
>> the
>> >> > >>> > >> > > >>> MiniAccumuloCluster.
>> >> > >>> > >> > > >>> >
>> >> > >>> > >> > > >>> > One of our developer encountered the following
>> >> issues:
>> >> > >>> > >> > > >>> >
>> >> > >>> > >> > > >>> >    1. The MiniAccumumluoClusterImpl._exec is
>> >> hardcoded
>> >> > >>> with the
>> >> > >>> > >> JVM
>> >> > >>> > >> > > arg
>> >> > >>> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no longer
>> >> tolerated
>> >> > >>> with
>> >> > >>> > >> JDK17.
>> >> > >>> > >> > > >>> >    2. In Zookeeper 3.4.14, ConetStringParser uses
>> >> > >>> > >> createUnresolved to
>> >> > >>> > >> > > >>> >    make IPAddresses.
>> >> > >>> > >> > > >>>
>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
>> >> > >>> > >> > > >>> >    uses InetSocketAddess.getAddress, which returns
>> >> null
>> >> > >>> because
>> >> > >>> > >> it's
>> >> > >>> > >> > > >>> not
>> >> > >>> > >> > > >>> >    resolved, resulting in a failure to connect to
>> the
>> >> > >>> > >> newly-started
>> >> > >>> > >> > > >>> zookeeper.
>> >> > >>> > >> > > >>> >    3. StaticHostProvider.getHostString() tries to
>> >> extract
>> >> > >>> he
>> >> > >>> > >> hostname
>> >> > >>> > >> > > >>> by
>> >> > >>> > >> > > >>> >    calling toString on the address and taking
>> >> everything
>> >> > >>> before
>> >> > >>> > >> the
>> >> > >>> > >> > > >>> colon, but
>> >> > >>> > >> > > >>> >    in JDK17, the string format changed to
>> >> > >>> > >> > > "localhost/<unresolved->:xx"
>> >> > >>> > >> > > >>> (where
>> >> > >>> > >> > > >>> >    XX is still the port number).  That's incorrect
>> >> and it
>> >> > >>> can't
>> >> > >>> > >> > > >>> resolve the
>> >> > >>> > >> > > >>> >    names.
>> >> > >>> > >> > > >>> >
>> >> > >>> > >> > > >>> >
>> >> > >>> > >> > > >>> > Has anyone come across/resolved these kinds of
>> >> issues?
>> >> > >>> Is it
>> >> > >>> > >> not
>> >> > >>> > >> > > >>> possible
>> >> > >>> > >> > > >>> > to use java17 from a client perspective?  Will
>> >> upgrading
>> >> > >>> to
>> >> > >>> > >> accumulo
>> >> > >>> > >> > > >>> 2.1
>> >> > >>> > >> > > >>> > help?
>> >> > >>> > >> > > >>> >
>> >> > >>> > >> > > >>> > Thanks,
>> >> > >>> > >> > > >>> > Vincent
>> >> > >>> > >> > > >>>
>> >> > >>> > >> > > >>
>> >> > >>> > >> > >
>> >> > >>> > >>
>> >> > >>> > >
>> >> > >>>
>> >> > >>
>> >>
>> >
>>
>

Re: jdk 17 and accumulo testing

Posted by Vincent Russell <vi...@gmail.com>.
No worries.  I'm glad I was able to help in some small way.

Thank you for fixing the issue.

On Sat, Dec 17, 2022 at 11:49 AM Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:

> I created https://github.com/apache/accumulo/pull/3134 and that should fix
> this issue.
>
> Thanks Vincent for pointing out the issue in TServerUtils, your testing
> made this easy to track down and fix.
>
>
> On Sat, Dec 17, 2022 at 9:00 AM Christopher Shannon <
> christopher.l.shannon@gmail.com> wrote:
>
> > I was able to reproduce the issue by setting the value size for a
> mutation
> > to size 16384001 to make sure it's greater than the default value for
> > Thrift and it fails immediately. I will work on a fix now that we know
> how
> > to reproduce it.
> >
> > On Fri, Dec 16, 2022 at 2:31 PM Christopher <ct...@apache.org> wrote:
> >
> >> I don't think it's intentional. This might be the source of the problem.
> >>
> >> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
> >> <vi...@gmail.com> wrote:
> >> >
> >> > Also in TserverUtils:270, when the TNonblockingServerSocket is created
> >> it
> >> > looks like it ends up using the default frame size.  I am not sure if
> >> this
> >> > is intentional or not.
> >> >
> >> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
> >> vincent.russell@gmail.com>
> >> > wrote:
> >> >
> >> > > Christopher,
> >> > >
> >> > > I am not sure if this issue is related to 3042 or not.
> >> > >
> >> > > On the client side it does look like TConfiguration ends up being
> >> called
> >> > > with the default constructor.  I am not sure if this is intentional
> >> or not.
> >> > >
> >> > > On the server side I see this stack, so it also looks like:
> >> > >
> >> > > at org.apache.thrift.TConfiguration.<init>(TConfiguration.java:36)
> >> > > at
> >> org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
> >> > > at org.apache.thrift.TConfiguration.<clinit>(TConfiguration.java:65)
> >> > > at
> >> > >
> >>
> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:74)
> >> > > at
> >> > >
> >>
> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:68)
> >> > > at
> >> > >
> >>
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
> >> > > at
> >> > >
> >>
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
> >> > > at
> >> > >
> >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
> >> > > at
> >> > >
> >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
> >> > > at
> >> > >
> >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> >> > >
> >> > >
> >> > > I see this in the server log so it does look like it should be using
> >> 1G:
> >> > > 2022-09-01 16:59:41 INFO  [org.apache.accumulo.tserver.TabletServer]
> >> > > ServerUtil:124 - general.server.message.size.max = 1G
> >> > >
> >> > > Thanks,
> >> > > Vincent
> >> > >
> >> > > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
> >> > > vincent.russell@gmail.com> wrote:
> >> > >
> >> > >>
> >> > >>
> >> > >> I had to make a stack trace with hacking together a remote debug
> >> instance:
> >> > >>
> >> > >> at
> >> > >>
> >>
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
> >> > >> at
> >> > >>
> >>
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
> >> > >> at
> >> > >>
> >>
> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
> >> > >> at
> >> > >>
> >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
> >> > >> at
> >> > >>
> >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> >> > >>
> >> > >> On Thu, Dec 15, 2022 at 12:52 AM Christopher <ct...@apache.org>
> >> wrote:
> >> > >>
> >> > >>> From the numbers in the message, it looks like you're sending an
> >> 18MB
> >> > >>> payload but something in Thrift is limiting things to 16384000
> >> > >>> (16000KB). I doubt you've overridden the default
> >> > >>> general.server.message.size.max to be anything that low (the
> default
> >> > >>> is 1G). Unless you're flushing after every mutation, it would not
> be
> >> > >>> surprising to exceed the 16MB max frame size indicated in the
> error
> >> > >>> message quite quickly.
> >> > >>>
> >> > >>> This value of 16384000 seemed weird. It looks like it's not using
> >> our
> >> > >>> configuration, but using the built-in default value of
> >> > >>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It looks
> >> like
> >> > >>> this can happen whenever `new TConfiguration()` is called without
> >> > >>> parameters... and there's a fair amount of internal code, mostly
> in
> >> > >>> libthrift itself, that does that. It's a bit tricky to track down
> >> the
> >> > >>> one causing this particular issue. If you have a full stack trace,
> >> it
> >> > >>> could help.
> >> > >>>
> >> > >>> Also, this might be the same issue seen reported in
> >> > >>> https://github.com/apache/accumulo/issues/3042
> >> > >>>
> >> > >>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
> >> > >>> <vi...@gmail.com> wrote:
> >> > >>> >
> >> > >>> > I was able to work out all of my compilation issues; however
> when
> >> I
> >> > >>> run an
> >> > >>> > integration test with the Mini Accumulo Cluster that tests
> writing
> >> > >>> > mutations with values of 5mb the flush hangs forever
> >> > >>> > and I see  the following logs in the TabletServer logs:
> >> > >>> >
> >> > >>> > 20:41:02.306 [Thread-7] ERROR
> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a
> frame
> >> > >>> size of
> >> > >>> > 18874697, which is bigger than the maximum allowable frame size
> >> > >>> 16384000
> >> > >>> > for ALL connections.
> >> > >>> > 20:41:03.582 [Thread-7] ERROR
> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a
> frame
> >> > >>> size of
> >> > >>> > 18874697, which is bigger than the maximum allowable frame size
> >> > >>> 16384000
> >> > >>> > for ALL connections.
> >> > >>> > 20:41:05.079 [Thread-7] ERROR
> >> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a
> frame
> >> > >>> size of
> >> > >>> > 18874697, which is bigger than the maximum allowable frame size
> >> > >>> 16384000
> >> > >>> > for ALL connections.
> >> > >>> >
> >> > >>> > Other tests that write smaller amounts of data appear to work
> >> fine.
> >> > >>> >
> >> > >>> > Any idea what the issue might be?
> >> > >>> >
> >> > >>> > Thank you,
> >> > >>> > Vincent
> >> > >>> >
> >> > >>> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
> >> > >>> vincent.russell@gmail.com>
> >> > >>> > wrote:
> >> > >>> >
> >> > >>> > > Thank you both for your responses.
> >> > >>> > >
> >> > >>> > > We are using an event store library from a sister project that
> >> was
> >> > >>> written
> >> > >>> > > for accumulo 1.10., which I have already upgraded to 2.0.
> >> > >>> > >
> >> > >>> > > I'll spend some time investigating how bad the usage of the
> >> internal
> >> > >>> > > packages are and get back to you.
> >> > >>> > >
> >> > >>> > > Thanks again,
> >> > >>> > >
> >> > >>> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <
> >> ctubbsii@apache.org>
> >> > >>> wrote:
> >> > >>> > >
> >> > >>> > >> To add to Dave's answer, the public API is defined at
> >> > >>> > >> https://accumulo.apache.org/api/
> >> > >>> > >> Anything else is not public and is subject to change without
> >> notice
> >> > >>> on
> >> > >>> > >> any release without any attempt to retain compatibility.
> >> > >>> > >>
> >> > >>> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <
> >> dmarion18@gmail.com>
> >> > >>> wrote:
> >> > >>> > >> >
> >> > >>> > >> > There is no guide. You are using implementation classes
> (see
> >> > >>> clientImpl
> >> > >>> > >> in
> >> > >>> > >> > the package name) vs. using the client api. If you can use
> >> the
> >> > >>> client
> >> > >>> > >> api
> >> > >>> > >> > directly, then this should insulate you from changes in the
> >> future
> >> > >>> > >> (except
> >> > >>> > >> > during major versions). We can try and find where things
> >> might
> >> > >>> have
> >> > >>> > >> moved,
> >> > >>> > >> > but a class may have been split into multiple pieces. If
> you
> >> could
> >> > >>> > >> provide
> >> > >>> > >> > class and method, that would be easier.
> >> > >>> > >> >
> >> > >>> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
> >> > >>> > >> vincent.russell@gmail.com>
> >> > >>> > >> > wrote:
> >> > >>> > >> >
> >> > >>> > >> > > Is there a guide that shows where classes may have been
> >> moved
> >> > >>> with
> >> > >>> > >> moving
> >> > >>> > >> > > from 2.0 to 2.1?  For instance, I am having issues
> >> compiling,
> >> > >>> because
> >> > >>> > >> the
> >> > >>> > >> > > following class doesn't exist:
> >> > >>> > >> > > import org.apache.accumulo.core.clientImpl.Tables;
> >> > >>> > >> > >
> >> > >>> > >> > > I'm just getting started so I'm sure there are others.
> >> > >>> > >> > >
> >> > >>> > >> > > Thanks,
> >> > >>> > >> > > Vincent
> >> > >>> > >> > >
> >> > >>> > >> > >
> >> > >>> > >> > >
> >> > >>> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
> >> > >>> > >> vincent.russell@gmail.com>
> >> > >>> > >> > > wrote:
> >> > >>> > >> > >
> >> > >>> > >> > > > I mean Christopher.
> >> > >>> > >> > > >
> >> > >>> > >> > > > Thanks again.
> >> > >>> > >> > > >
> >> > >>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
> >> > >>> > >> > > vincent.russell@gmail.com>
> >> > >>> > >> > > > wrote:
> >> > >>> > >> > > >
> >> > >>> > >> > > >> Thank you Chris.
> >> > >>> > >> > > >>
> >> > >>> > >> > > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7
> or
> >> > >>> later as
> >> > >>> > >> soon as
> >> > >>> > >> > > >> possible.
> >> > >>> > >> > > >>
> >> > >>> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <
> >> > >>> ctubbsii@apache.org>
> >> > >>> > >> wrote:
> >> > >>> > >> > > >>
> >> > >>> > >> > > >>> Hi Vincent,
> >> > >>> > >> > > >>>
> >> > >>> > >> > > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM
> >> release,
> >> > >>> and 2.0
> >> > >>> > >> is
> >> > >>> > >> > > >>> not expected to receive any further updates. Version
> >> 2.1.0
> >> > >>> may
> >> > >>> > >> work
> >> > >>> > >> > > >>> with ZooKeeper 3.4, but was developed and tested
> >> against
> >> > >>> 3.5 and
> >> > >>> > >> later
> >> > >>> > >> > > >>> versions. I believe the ZooKeeper community is
> >> currently
> >> > >>> > >> considering
> >> > >>> > >> > > >>> whether to make 3.6 end-of-life themselves, so I
> would
> >> > >>> recommend
> >> > >>> > >> using
> >> > >>> > >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later
> >> to
> >> > >>> have the
> >> > >>> > >> best
> >> > >>> > >> > > >>> chance of any kind of support, including JDK 17
> >> support.
> >> > >>> > >> > > >>>
> >> > >>> > >> > > >>> As for your specific issues:
> >> > >>> > >> > > >>>
> >> > >>> > >> > > >>> 1. This is already fixed in 2.1.0
> >> > >>> > >> > > >>> 2/3. These issues are likely fixed in newer ZooKeeper
> >> > >>> versions. I
> >> > >>> > >> > > >>> haven't seen them anytime recently, anyway. Bugs in
> >> > >>> ZooKeeper
> >> > >>> > >> itself
> >> > >>> > >> > > >>> are out of scope for the Accumulo developers, but I
> >> have
> >> > >>> tried
> >> > >>> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper
> >> 3.8.0 and
> >> > >>> > >> haven't
> >> > >>> > >> > > >>> observed any unresolved issues. However, it's
> >> difficult to
> >> > >>> > >> actually
> >> > >>> > >> > > >>> run it because I don't think Hadoop has good JDK 17
> >> support
> >> > >>> yet.
> >> > >>> > >> So,
> >> > >>> > >> > > >>> MiniAccumuloCluster seems to work with JDK 17, as
> does
> >> > >>> Accumulo
> >> > >>> > >> and ZK
> >> > >>> > >> > > >>> 3.8, but I don't think a full Hadoop cluster would
> >> (yet).
> >> > >>> > >> > > >>>
> >> > >>> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
> >> > >>> > >> > > >>> <vi...@gmail.com> wrote:
> >> > >>> > >> > > >>> >
> >> > >>> > >> > > >>> > Hello,
> >> > >>> > >> > > >>> >
> >> > >>> > >> > > >>> > We are currently using accumulo 2.0.1.
> >> > >>> > >> > > >>> >
> >> > >>> > >> > > >>> > We are in the process of upgrading our source code
> >> to use
> >> > >>> jdk 17
> >> > >>> > >> > > >>> however we
> >> > >>> > >> > > >>> > are running into some problems with our tests and
> the
> >> > >>> > >> > > >>> MiniAccumuloCluster.
> >> > >>> > >> > > >>> >
> >> > >>> > >> > > >>> > One of our developer encountered the following
> >> issues:
> >> > >>> > >> > > >>> >
> >> > >>> > >> > > >>> >    1. The MiniAccumumluoClusterImpl._exec is
> >> hardcoded
> >> > >>> with the
> >> > >>> > >> JVM
> >> > >>> > >> > > arg
> >> > >>> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no longer
> >> tolerated
> >> > >>> with
> >> > >>> > >> JDK17.
> >> > >>> > >> > > >>> >    2. In Zookeeper 3.4.14, ConetStringParser uses
> >> > >>> > >> createUnresolved to
> >> > >>> > >> > > >>> >    make IPAddresses.
> >> > >>> > >> > > >>>
> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> >> > >>> > >> > > >>> >    uses InetSocketAddess.getAddress, which returns
> >> null
> >> > >>> because
> >> > >>> > >> it's
> >> > >>> > >> > > >>> not
> >> > >>> > >> > > >>> >    resolved, resulting in a failure to connect to
> the
> >> > >>> > >> newly-started
> >> > >>> > >> > > >>> zookeeper.
> >> > >>> > >> > > >>> >    3. StaticHostProvider.getHostString() tries to
> >> extract
> >> > >>> he
> >> > >>> > >> hostname
> >> > >>> > >> > > >>> by
> >> > >>> > >> > > >>> >    calling toString on the address and taking
> >> everything
> >> > >>> before
> >> > >>> > >> the
> >> > >>> > >> > > >>> colon, but
> >> > >>> > >> > > >>> >    in JDK17, the string format changed to
> >> > >>> > >> > > "localhost/<unresolved->:xx"
> >> > >>> > >> > > >>> (where
> >> > >>> > >> > > >>> >    XX is still the port number).  That's incorrect
> >> and it
> >> > >>> can't
> >> > >>> > >> > > >>> resolve the
> >> > >>> > >> > > >>> >    names.
> >> > >>> > >> > > >>> >
> >> > >>> > >> > > >>> >
> >> > >>> > >> > > >>> > Has anyone come across/resolved these kinds of
> >> issues?
> >> > >>> Is it
> >> > >>> > >> not
> >> > >>> > >> > > >>> possible
> >> > >>> > >> > > >>> > to use java17 from a client perspective?  Will
> >> upgrading
> >> > >>> to
> >> > >>> > >> accumulo
> >> > >>> > >> > > >>> 2.1
> >> > >>> > >> > > >>> > help?
> >> > >>> > >> > > >>> >
> >> > >>> > >> > > >>> > Thanks,
> >> > >>> > >> > > >>> > Vincent
> >> > >>> > >> > > >>>
> >> > >>> > >> > > >>
> >> > >>> > >> > >
> >> > >>> > >>
> >> > >>> > >
> >> > >>>
> >> > >>
> >>
> >
>

Re: jdk 17 and accumulo testing

Posted by Christopher Shannon <ch...@gmail.com>.
I created https://github.com/apache/accumulo/pull/3134 and that should fix
this issue.

Thanks Vincent for pointing out the issue in TServerUtils, your testing
made this easy to track down and fix.


On Sat, Dec 17, 2022 at 9:00 AM Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:

> I was able to reproduce the issue by setting the value size for a mutation
> to size 16384001 to make sure it's greater than the default value for
> Thrift and it fails immediately. I will work on a fix now that we know how
> to reproduce it.
>
> On Fri, Dec 16, 2022 at 2:31 PM Christopher <ct...@apache.org> wrote:
>
>> I don't think it's intentional. This might be the source of the problem.
>>
>> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
>> <vi...@gmail.com> wrote:
>> >
>> > Also in TserverUtils:270, when the TNonblockingServerSocket is created
>> it
>> > looks like it ends up using the default frame size.  I am not sure if
>> this
>> > is intentional or not.
>> >
>> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
>> vincent.russell@gmail.com>
>> > wrote:
>> >
>> > > Christopher,
>> > >
>> > > I am not sure if this issue is related to 3042 or not.
>> > >
>> > > On the client side it does look like TConfiguration ends up being
>> called
>> > > with the default constructor.  I am not sure if this is intentional
>> or not.
>> > >
>> > > On the server side I see this stack, so it also looks like:
>> > >
>> > > at org.apache.thrift.TConfiguration.<init>(TConfiguration.java:36)
>> > > at
>> org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
>> > > at org.apache.thrift.TConfiguration.<clinit>(TConfiguration.java:65)
>> > > at
>> > >
>> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:74)
>> > > at
>> > >
>> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:68)
>> > > at
>> > >
>> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
>> > > at
>> > >
>> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
>> > > at
>> > >
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
>> > > at
>> > >
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
>> > > at
>> > >
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
>> > >
>> > >
>> > > I see this in the server log so it does look like it should be using
>> 1G:
>> > > 2022-09-01 16:59:41 INFO  [org.apache.accumulo.tserver.TabletServer]
>> > > ServerUtil:124 - general.server.message.size.max = 1G
>> > >
>> > > Thanks,
>> > > Vincent
>> > >
>> > > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
>> > > vincent.russell@gmail.com> wrote:
>> > >
>> > >>
>> > >>
>> > >> I had to make a stack trace with hacking together a remote debug
>> instance:
>> > >>
>> > >> at
>> > >>
>> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
>> > >> at
>> > >>
>> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
>> > >> at
>> > >>
>> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
>> > >> at
>> > >>
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
>> > >> at
>> > >>
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
>> > >>
>> > >> On Thu, Dec 15, 2022 at 12:52 AM Christopher <ct...@apache.org>
>> wrote:
>> > >>
>> > >>> From the numbers in the message, it looks like you're sending an
>> 18MB
>> > >>> payload but something in Thrift is limiting things to 16384000
>> > >>> (16000KB). I doubt you've overridden the default
>> > >>> general.server.message.size.max to be anything that low (the default
>> > >>> is 1G). Unless you're flushing after every mutation, it would not be
>> > >>> surprising to exceed the 16MB max frame size indicated in the error
>> > >>> message quite quickly.
>> > >>>
>> > >>> This value of 16384000 seemed weird. It looks like it's not using
>> our
>> > >>> configuration, but using the built-in default value of
>> > >>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It looks
>> like
>> > >>> this can happen whenever `new TConfiguration()` is called without
>> > >>> parameters... and there's a fair amount of internal code, mostly in
>> > >>> libthrift itself, that does that. It's a bit tricky to track down
>> the
>> > >>> one causing this particular issue. If you have a full stack trace,
>> it
>> > >>> could help.
>> > >>>
>> > >>> Also, this might be the same issue seen reported in
>> > >>> https://github.com/apache/accumulo/issues/3042
>> > >>>
>> > >>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
>> > >>> <vi...@gmail.com> wrote:
>> > >>> >
>> > >>> > I was able to work out all of my compilation issues; however when
>> I
>> > >>> run an
>> > >>> > integration test with the Mini Accumulo Cluster that tests writing
>> > >>> > mutations with values of 5mb the flush hangs forever
>> > >>> > and I see  the following logs in the TabletServer logs:
>> > >>> >
>> > >>> > 20:41:02.306 [Thread-7] ERROR
>> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame
>> > >>> size of
>> > >>> > 18874697, which is bigger than the maximum allowable frame size
>> > >>> 16384000
>> > >>> > for ALL connections.
>> > >>> > 20:41:03.582 [Thread-7] ERROR
>> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame
>> > >>> size of
>> > >>> > 18874697, which is bigger than the maximum allowable frame size
>> > >>> 16384000
>> > >>> > for ALL connections.
>> > >>> > 20:41:05.079 [Thread-7] ERROR
>> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame
>> > >>> size of
>> > >>> > 18874697, which is bigger than the maximum allowable frame size
>> > >>> 16384000
>> > >>> > for ALL connections.
>> > >>> >
>> > >>> > Other tests that write smaller amounts of data appear to work
>> fine.
>> > >>> >
>> > >>> > Any idea what the issue might be?
>> > >>> >
>> > >>> > Thank you,
>> > >>> > Vincent
>> > >>> >
>> > >>> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
>> > >>> vincent.russell@gmail.com>
>> > >>> > wrote:
>> > >>> >
>> > >>> > > Thank you both for your responses.
>> > >>> > >
>> > >>> > > We are using an event store library from a sister project that
>> was
>> > >>> written
>> > >>> > > for accumulo 1.10., which I have already upgraded to 2.0.
>> > >>> > >
>> > >>> > > I'll spend some time investigating how bad the usage of the
>> internal
>> > >>> > > packages are and get back to you.
>> > >>> > >
>> > >>> > > Thanks again,
>> > >>> > >
>> > >>> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <
>> ctubbsii@apache.org>
>> > >>> wrote:
>> > >>> > >
>> > >>> > >> To add to Dave's answer, the public API is defined at
>> > >>> > >> https://accumulo.apache.org/api/
>> > >>> > >> Anything else is not public and is subject to change without
>> notice
>> > >>> on
>> > >>> > >> any release without any attempt to retain compatibility.
>> > >>> > >>
>> > >>> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <
>> dmarion18@gmail.com>
>> > >>> wrote:
>> > >>> > >> >
>> > >>> > >> > There is no guide. You are using implementation classes (see
>> > >>> clientImpl
>> > >>> > >> in
>> > >>> > >> > the package name) vs. using the client api. If you can use
>> the
>> > >>> client
>> > >>> > >> api
>> > >>> > >> > directly, then this should insulate you from changes in the
>> future
>> > >>> > >> (except
>> > >>> > >> > during major versions). We can try and find where things
>> might
>> > >>> have
>> > >>> > >> moved,
>> > >>> > >> > but a class may have been split into multiple pieces. If you
>> could
>> > >>> > >> provide
>> > >>> > >> > class and method, that would be easier.
>> > >>> > >> >
>> > >>> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
>> > >>> > >> vincent.russell@gmail.com>
>> > >>> > >> > wrote:
>> > >>> > >> >
>> > >>> > >> > > Is there a guide that shows where classes may have been
>> moved
>> > >>> with
>> > >>> > >> moving
>> > >>> > >> > > from 2.0 to 2.1?  For instance, I am having issues
>> compiling,
>> > >>> because
>> > >>> > >> the
>> > >>> > >> > > following class doesn't exist:
>> > >>> > >> > > import org.apache.accumulo.core.clientImpl.Tables;
>> > >>> > >> > >
>> > >>> > >> > > I'm just getting started so I'm sure there are others.
>> > >>> > >> > >
>> > >>> > >> > > Thanks,
>> > >>> > >> > > Vincent
>> > >>> > >> > >
>> > >>> > >> > >
>> > >>> > >> > >
>> > >>> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
>> > >>> > >> vincent.russell@gmail.com>
>> > >>> > >> > > wrote:
>> > >>> > >> > >
>> > >>> > >> > > > I mean Christopher.
>> > >>> > >> > > >
>> > >>> > >> > > > Thanks again.
>> > >>> > >> > > >
>> > >>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
>> > >>> > >> > > vincent.russell@gmail.com>
>> > >>> > >> > > > wrote:
>> > >>> > >> > > >
>> > >>> > >> > > >> Thank you Chris.
>> > >>> > >> > > >>
>> > >>> > >> > > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or
>> > >>> later as
>> > >>> > >> soon as
>> > >>> > >> > > >> possible.
>> > >>> > >> > > >>
>> > >>> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <
>> > >>> ctubbsii@apache.org>
>> > >>> > >> wrote:
>> > >>> > >> > > >>
>> > >>> > >> > > >>> Hi Vincent,
>> > >>> > >> > > >>>
>> > >>> > >> > > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM
>> release,
>> > >>> and 2.0
>> > >>> > >> is
>> > >>> > >> > > >>> not expected to receive any further updates. Version
>> 2.1.0
>> > >>> may
>> > >>> > >> work
>> > >>> > >> > > >>> with ZooKeeper 3.4, but was developed and tested
>> against
>> > >>> 3.5 and
>> > >>> > >> later
>> > >>> > >> > > >>> versions. I believe the ZooKeeper community is
>> currently
>> > >>> > >> considering
>> > >>> > >> > > >>> whether to make 3.6 end-of-life themselves, so I would
>> > >>> recommend
>> > >>> > >> using
>> > >>> > >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later
>> to
>> > >>> have the
>> > >>> > >> best
>> > >>> > >> > > >>> chance of any kind of support, including JDK 17
>> support.
>> > >>> > >> > > >>>
>> > >>> > >> > > >>> As for your specific issues:
>> > >>> > >> > > >>>
>> > >>> > >> > > >>> 1. This is already fixed in 2.1.0
>> > >>> > >> > > >>> 2/3. These issues are likely fixed in newer ZooKeeper
>> > >>> versions. I
>> > >>> > >> > > >>> haven't seen them anytime recently, anyway. Bugs in
>> > >>> ZooKeeper
>> > >>> > >> itself
>> > >>> > >> > > >>> are out of scope for the Accumulo developers, but I
>> have
>> > >>> tried
>> > >>> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper
>> 3.8.0 and
>> > >>> > >> haven't
>> > >>> > >> > > >>> observed any unresolved issues. However, it's
>> difficult to
>> > >>> > >> actually
>> > >>> > >> > > >>> run it because I don't think Hadoop has good JDK 17
>> support
>> > >>> yet.
>> > >>> > >> So,
>> > >>> > >> > > >>> MiniAccumuloCluster seems to work with JDK 17, as does
>> > >>> Accumulo
>> > >>> > >> and ZK
>> > >>> > >> > > >>> 3.8, but I don't think a full Hadoop cluster would
>> (yet).
>> > >>> > >> > > >>>
>> > >>> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
>> > >>> > >> > > >>> <vi...@gmail.com> wrote:
>> > >>> > >> > > >>> >
>> > >>> > >> > > >>> > Hello,
>> > >>> > >> > > >>> >
>> > >>> > >> > > >>> > We are currently using accumulo 2.0.1.
>> > >>> > >> > > >>> >
>> > >>> > >> > > >>> > We are in the process of upgrading our source code
>> to use
>> > >>> jdk 17
>> > >>> > >> > > >>> however we
>> > >>> > >> > > >>> > are running into some problems with our tests and the
>> > >>> > >> > > >>> MiniAccumuloCluster.
>> > >>> > >> > > >>> >
>> > >>> > >> > > >>> > One of our developer encountered the following
>> issues:
>> > >>> > >> > > >>> >
>> > >>> > >> > > >>> >    1. The MiniAccumumluoClusterImpl._exec is
>> hardcoded
>> > >>> with the
>> > >>> > >> JVM
>> > >>> > >> > > arg
>> > >>> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no longer
>> tolerated
>> > >>> with
>> > >>> > >> JDK17.
>> > >>> > >> > > >>> >    2. In Zookeeper 3.4.14, ConetStringParser uses
>> > >>> > >> createUnresolved to
>> > >>> > >> > > >>> >    make IPAddresses.
>> > >>> > >> > > >>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
>> > >>> > >> > > >>> >    uses InetSocketAddess.getAddress, which returns
>> null
>> > >>> because
>> > >>> > >> it's
>> > >>> > >> > > >>> not
>> > >>> > >> > > >>> >    resolved, resulting in a failure to connect to the
>> > >>> > >> newly-started
>> > >>> > >> > > >>> zookeeper.
>> > >>> > >> > > >>> >    3. StaticHostProvider.getHostString() tries to
>> extract
>> > >>> he
>> > >>> > >> hostname
>> > >>> > >> > > >>> by
>> > >>> > >> > > >>> >    calling toString on the address and taking
>> everything
>> > >>> before
>> > >>> > >> the
>> > >>> > >> > > >>> colon, but
>> > >>> > >> > > >>> >    in JDK17, the string format changed to
>> > >>> > >> > > "localhost/<unresolved->:xx"
>> > >>> > >> > > >>> (where
>> > >>> > >> > > >>> >    XX is still the port number).  That's incorrect
>> and it
>> > >>> can't
>> > >>> > >> > > >>> resolve the
>> > >>> > >> > > >>> >    names.
>> > >>> > >> > > >>> >
>> > >>> > >> > > >>> >
>> > >>> > >> > > >>> > Has anyone come across/resolved these kinds of
>> issues?
>> > >>> Is it
>> > >>> > >> not
>> > >>> > >> > > >>> possible
>> > >>> > >> > > >>> > to use java17 from a client perspective?  Will
>> upgrading
>> > >>> to
>> > >>> > >> accumulo
>> > >>> > >> > > >>> 2.1
>> > >>> > >> > > >>> > help?
>> > >>> > >> > > >>> >
>> > >>> > >> > > >>> > Thanks,
>> > >>> > >> > > >>> > Vincent
>> > >>> > >> > > >>>
>> > >>> > >> > > >>
>> > >>> > >> > >
>> > >>> > >>
>> > >>> > >
>> > >>>
>> > >>
>>
>

Re: jdk 17 and accumulo testing

Posted by Christopher Shannon <ch...@gmail.com>.
I was able to reproduce the issue by setting the value size for a mutation
to size 16384001 to make sure it's greater than the default value for
Thrift and it fails immediately. I will work on a fix now that we know how
to reproduce it.

On Fri, Dec 16, 2022 at 2:31 PM Christopher <ct...@apache.org> wrote:

> I don't think it's intentional. This might be the source of the problem.
>
> On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
> <vi...@gmail.com> wrote:
> >
> > Also in TserverUtils:270, when the TNonblockingServerSocket is created it
> > looks like it ends up using the default frame size.  I am not sure if
> this
> > is intentional or not.
> >
> > On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <
> vincent.russell@gmail.com>
> > wrote:
> >
> > > Christopher,
> > >
> > > I am not sure if this issue is related to 3042 or not.
> > >
> > > On the client side it does look like TConfiguration ends up being
> called
> > > with the default constructor.  I am not sure if this is intentional or
> not.
> > >
> > > On the server side I see this stack, so it also looks like:
> > >
> > > at org.apache.thrift.TConfiguration.<init>(TConfiguration.java:36)
> > > at
> org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
> > > at org.apache.thrift.TConfiguration.<clinit>(TConfiguration.java:65)
> > > at
> > >
> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:74)
> > > at
> > >
> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:68)
> > > at
> > >
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
> > > at
> > >
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
> > > at
> > >
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
> > > at
> > >
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
> > > at
> > >
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> > >
> > >
> > > I see this in the server log so it does look like it should be using
> 1G:
> > > 2022-09-01 16:59:41 INFO  [org.apache.accumulo.tserver.TabletServer]
> > > ServerUtil:124 - general.server.message.size.max = 1G
> > >
> > > Thanks,
> > > Vincent
> > >
> > > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
> > > vincent.russell@gmail.com> wrote:
> > >
> > >>
> > >>
> > >> I had to make a stack trace with hacking together a remote debug
> instance:
> > >>
> > >> at
> > >>
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
> > >> at
> > >>
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
> > >> at
> > >>
> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
> > >> at
> > >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
> > >> at
> > >>
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> > >>
> > >> On Thu, Dec 15, 2022 at 12:52 AM Christopher <ct...@apache.org>
> wrote:
> > >>
> > >>> From the numbers in the message, it looks like you're sending an 18MB
> > >>> payload but something in Thrift is limiting things to 16384000
> > >>> (16000KB). I doubt you've overridden the default
> > >>> general.server.message.size.max to be anything that low (the default
> > >>> is 1G). Unless you're flushing after every mutation, it would not be
> > >>> surprising to exceed the 16MB max frame size indicated in the error
> > >>> message quite quickly.
> > >>>
> > >>> This value of 16384000 seemed weird. It looks like it's not using our
> > >>> configuration, but using the built-in default value of
> > >>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It looks
> like
> > >>> this can happen whenever `new TConfiguration()` is called without
> > >>> parameters... and there's a fair amount of internal code, mostly in
> > >>> libthrift itself, that does that. It's a bit tricky to track down the
> > >>> one causing this particular issue. If you have a full stack trace, it
> > >>> could help.
> > >>>
> > >>> Also, this might be the same issue seen reported in
> > >>> https://github.com/apache/accumulo/issues/3042
> > >>>
> > >>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
> > >>> <vi...@gmail.com> wrote:
> > >>> >
> > >>> > I was able to work out all of my compilation issues; however when I
> > >>> run an
> > >>> > integration test with the Mini Accumulo Cluster that tests writing
> > >>> > mutations with values of 5mb the flush hangs forever
> > >>> > and I see  the following logs in the TabletServer logs:
> > >>> >
> > >>> > 20:41:02.306 [Thread-7] ERROR
> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame
> > >>> size of
> > >>> > 18874697, which is bigger than the maximum allowable frame size
> > >>> 16384000
> > >>> > for ALL connections.
> > >>> > 20:41:03.582 [Thread-7] ERROR
> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame
> > >>> size of
> > >>> > 18874697, which is bigger than the maximum allowable frame size
> > >>> 16384000
> > >>> > for ALL connections.
> > >>> > 20:41:05.079 [Thread-7] ERROR
> > >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame
> > >>> size of
> > >>> > 18874697, which is bigger than the maximum allowable frame size
> > >>> 16384000
> > >>> > for ALL connections.
> > >>> >
> > >>> > Other tests that write smaller amounts of data appear to work fine.
> > >>> >
> > >>> > Any idea what the issue might be?
> > >>> >
> > >>> > Thank you,
> > >>> > Vincent
> > >>> >
> > >>> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
> > >>> vincent.russell@gmail.com>
> > >>> > wrote:
> > >>> >
> > >>> > > Thank you both for your responses.
> > >>> > >
> > >>> > > We are using an event store library from a sister project that
> was
> > >>> written
> > >>> > > for accumulo 1.10., which I have already upgraded to 2.0.
> > >>> > >
> > >>> > > I'll spend some time investigating how bad the usage of the
> internal
> > >>> > > packages are and get back to you.
> > >>> > >
> > >>> > > Thanks again,
> > >>> > >
> > >>> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <ctubbsii@apache.org
> >
> > >>> wrote:
> > >>> > >
> > >>> > >> To add to Dave's answer, the public API is defined at
> > >>> > >> https://accumulo.apache.org/api/
> > >>> > >> Anything else is not public and is subject to change without
> notice
> > >>> on
> > >>> > >> any release without any attempt to retain compatibility.
> > >>> > >>
> > >>> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <
> dmarion18@gmail.com>
> > >>> wrote:
> > >>> > >> >
> > >>> > >> > There is no guide. You are using implementation classes (see
> > >>> clientImpl
> > >>> > >> in
> > >>> > >> > the package name) vs. using the client api. If you can use the
> > >>> client
> > >>> > >> api
> > >>> > >> > directly, then this should insulate you from changes in the
> future
> > >>> > >> (except
> > >>> > >> > during major versions). We can try and find where things might
> > >>> have
> > >>> > >> moved,
> > >>> > >> > but a class may have been split into multiple pieces. If you
> could
> > >>> > >> provide
> > >>> > >> > class and method, that would be easier.
> > >>> > >> >
> > >>> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
> > >>> > >> vincent.russell@gmail.com>
> > >>> > >> > wrote:
> > >>> > >> >
> > >>> > >> > > Is there a guide that shows where classes may have been
> moved
> > >>> with
> > >>> > >> moving
> > >>> > >> > > from 2.0 to 2.1?  For instance, I am having issues
> compiling,
> > >>> because
> > >>> > >> the
> > >>> > >> > > following class doesn't exist:
> > >>> > >> > > import org.apache.accumulo.core.clientImpl.Tables;
> > >>> > >> > >
> > >>> > >> > > I'm just getting started so I'm sure there are others.
> > >>> > >> > >
> > >>> > >> > > Thanks,
> > >>> > >> > > Vincent
> > >>> > >> > >
> > >>> > >> > >
> > >>> > >> > >
> > >>> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
> > >>> > >> vincent.russell@gmail.com>
> > >>> > >> > > wrote:
> > >>> > >> > >
> > >>> > >> > > > I mean Christopher.
> > >>> > >> > > >
> > >>> > >> > > > Thanks again.
> > >>> > >> > > >
> > >>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
> > >>> > >> > > vincent.russell@gmail.com>
> > >>> > >> > > > wrote:
> > >>> > >> > > >
> > >>> > >> > > >> Thank you Chris.
> > >>> > >> > > >>
> > >>> > >> > > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or
> > >>> later as
> > >>> > >> soon as
> > >>> > >> > > >> possible.
> > >>> > >> > > >>
> > >>> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <
> > >>> ctubbsii@apache.org>
> > >>> > >> wrote:
> > >>> > >> > > >>
> > >>> > >> > > >>> Hi Vincent,
> > >>> > >> > > >>>
> > >>> > >> > > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM
> release,
> > >>> and 2.0
> > >>> > >> is
> > >>> > >> > > >>> not expected to receive any further updates. Version
> 2.1.0
> > >>> may
> > >>> > >> work
> > >>> > >> > > >>> with ZooKeeper 3.4, but was developed and tested against
> > >>> 3.5 and
> > >>> > >> later
> > >>> > >> > > >>> versions. I believe the ZooKeeper community is currently
> > >>> > >> considering
> > >>> > >> > > >>> whether to make 3.6 end-of-life themselves, so I would
> > >>> recommend
> > >>> > >> using
> > >>> > >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to
> > >>> have the
> > >>> > >> best
> > >>> > >> > > >>> chance of any kind of support, including JDK 17 support.
> > >>> > >> > > >>>
> > >>> > >> > > >>> As for your specific issues:
> > >>> > >> > > >>>
> > >>> > >> > > >>> 1. This is already fixed in 2.1.0
> > >>> > >> > > >>> 2/3. These issues are likely fixed in newer ZooKeeper
> > >>> versions. I
> > >>> > >> > > >>> haven't seen them anytime recently, anyway. Bugs in
> > >>> ZooKeeper
> > >>> > >> itself
> > >>> > >> > > >>> are out of scope for the Accumulo developers, but I have
> > >>> tried
> > >>> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0
> and
> > >>> > >> haven't
> > >>> > >> > > >>> observed any unresolved issues. However, it's difficult
> to
> > >>> > >> actually
> > >>> > >> > > >>> run it because I don't think Hadoop has good JDK 17
> support
> > >>> yet.
> > >>> > >> So,
> > >>> > >> > > >>> MiniAccumuloCluster seems to work with JDK 17, as does
> > >>> Accumulo
> > >>> > >> and ZK
> > >>> > >> > > >>> 3.8, but I don't think a full Hadoop cluster would
> (yet).
> > >>> > >> > > >>>
> > >>> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
> > >>> > >> > > >>> <vi...@gmail.com> wrote:
> > >>> > >> > > >>> >
> > >>> > >> > > >>> > Hello,
> > >>> > >> > > >>> >
> > >>> > >> > > >>> > We are currently using accumulo 2.0.1.
> > >>> > >> > > >>> >
> > >>> > >> > > >>> > We are in the process of upgrading our source code to
> use
> > >>> jdk 17
> > >>> > >> > > >>> however we
> > >>> > >> > > >>> > are running into some problems with our tests and the
> > >>> > >> > > >>> MiniAccumuloCluster.
> > >>> > >> > > >>> >
> > >>> > >> > > >>> > One of our developer encountered the following issues:
> > >>> > >> > > >>> >
> > >>> > >> > > >>> >    1. The MiniAccumumluoClusterImpl._exec is hardcoded
> > >>> with the
> > >>> > >> JVM
> > >>> > >> > > arg
> > >>> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no longer
> tolerated
> > >>> with
> > >>> > >> JDK17.
> > >>> > >> > > >>> >    2. In Zookeeper 3.4.14, ConetStringParser uses
> > >>> > >> createUnresolved to
> > >>> > >> > > >>> >    make IPAddresses.
> > >>> > >> > > >>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> > >>> > >> > > >>> >    uses InetSocketAddess.getAddress, which returns
> null
> > >>> because
> > >>> > >> it's
> > >>> > >> > > >>> not
> > >>> > >> > > >>> >    resolved, resulting in a failure to connect to the
> > >>> > >> newly-started
> > >>> > >> > > >>> zookeeper.
> > >>> > >> > > >>> >    3. StaticHostProvider.getHostString() tries to
> extract
> > >>> he
> > >>> > >> hostname
> > >>> > >> > > >>> by
> > >>> > >> > > >>> >    calling toString on the address and taking
> everything
> > >>> before
> > >>> > >> the
> > >>> > >> > > >>> colon, but
> > >>> > >> > > >>> >    in JDK17, the string format changed to
> > >>> > >> > > "localhost/<unresolved->:xx"
> > >>> > >> > > >>> (where
> > >>> > >> > > >>> >    XX is still the port number).  That's incorrect
> and it
> > >>> can't
> > >>> > >> > > >>> resolve the
> > >>> > >> > > >>> >    names.
> > >>> > >> > > >>> >
> > >>> > >> > > >>> >
> > >>> > >> > > >>> > Has anyone come across/resolved these kinds of issues?
> > >>> Is it
> > >>> > >> not
> > >>> > >> > > >>> possible
> > >>> > >> > > >>> > to use java17 from a client perspective?  Will
> upgrading
> > >>> to
> > >>> > >> accumulo
> > >>> > >> > > >>> 2.1
> > >>> > >> > > >>> > help?
> > >>> > >> > > >>> >
> > >>> > >> > > >>> > Thanks,
> > >>> > >> > > >>> > Vincent
> > >>> > >> > > >>>
> > >>> > >> > > >>
> > >>> > >> > >
> > >>> > >>
> > >>> > >
> > >>>
> > >>
>

Re: jdk 17 and accumulo testing

Posted by Christopher <ct...@apache.org>.
I don't think it's intentional. This might be the source of the problem.

On Thu, Dec 15, 2022 at 3:39 PM Vincent Russell
<vi...@gmail.com> wrote:
>
> Also in TserverUtils:270, when the TNonblockingServerSocket is created it
> looks like it ends up using the default frame size.  I am not sure if this
> is intentional or not.
>
> On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <vi...@gmail.com>
> wrote:
>
> > Christopher,
> >
> > I am not sure if this issue is related to 3042 or not.
> >
> > On the client side it does look like TConfiguration ends up being called
> > with the default constructor.  I am not sure if this is intentional or not.
> >
> > On the server side I see this stack, so it also looks like:
> >
> > at org.apache.thrift.TConfiguration.<init>(TConfiguration.java:36)
> > at org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
> > at org.apache.thrift.TConfiguration.<clinit>(TConfiguration.java:65)
> > at
> > org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:74)
> > at
> > org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:68)
> > at
> > org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
> > at
> > org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
> > at
> > org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
> > at
> > org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
> > at
> > org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> >
> >
> > I see this in the server log so it does look like it should be using 1G:
> > 2022-09-01 16:59:41 INFO  [org.apache.accumulo.tserver.TabletServer]
> > ServerUtil:124 - general.server.message.size.max = 1G
> >
> > Thanks,
> > Vincent
> >
> > On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
> > vincent.russell@gmail.com> wrote:
> >
> >>
> >>
> >> I had to make a stack trace with hacking together a remote debug instance:
> >>
> >> at
> >> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
> >> at
> >> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
> >> at
> >> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
> >> at
> >> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
> >> at
> >> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
> >>
> >> On Thu, Dec 15, 2022 at 12:52 AM Christopher <ct...@apache.org> wrote:
> >>
> >>> From the numbers in the message, it looks like you're sending an 18MB
> >>> payload but something in Thrift is limiting things to 16384000
> >>> (16000KB). I doubt you've overridden the default
> >>> general.server.message.size.max to be anything that low (the default
> >>> is 1G). Unless you're flushing after every mutation, it would not be
> >>> surprising to exceed the 16MB max frame size indicated in the error
> >>> message quite quickly.
> >>>
> >>> This value of 16384000 seemed weird. It looks like it's not using our
> >>> configuration, but using the built-in default value of
> >>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It looks like
> >>> this can happen whenever `new TConfiguration()` is called without
> >>> parameters... and there's a fair amount of internal code, mostly in
> >>> libthrift itself, that does that. It's a bit tricky to track down the
> >>> one causing this particular issue. If you have a full stack trace, it
> >>> could help.
> >>>
> >>> Also, this might be the same issue seen reported in
> >>> https://github.com/apache/accumulo/issues/3042
> >>>
> >>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
> >>> <vi...@gmail.com> wrote:
> >>> >
> >>> > I was able to work out all of my compilation issues; however when I
> >>> run an
> >>> > integration test with the Mini Accumulo Cluster that tests writing
> >>> > mutations with values of 5mb the flush hangs forever
> >>> > and I see  the following logs in the TabletServer logs:
> >>> >
> >>> > 20:41:02.306 [Thread-7] ERROR
> >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame
> >>> size of
> >>> > 18874697, which is bigger than the maximum allowable frame size
> >>> 16384000
> >>> > for ALL connections.
> >>> > 20:41:03.582 [Thread-7] ERROR
> >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame
> >>> size of
> >>> > 18874697, which is bigger than the maximum allowable frame size
> >>> 16384000
> >>> > for ALL connections.
> >>> > 20:41:05.079 [Thread-7] ERROR
> >>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame
> >>> size of
> >>> > 18874697, which is bigger than the maximum allowable frame size
> >>> 16384000
> >>> > for ALL connections.
> >>> >
> >>> > Other tests that write smaller amounts of data appear to work fine.
> >>> >
> >>> > Any idea what the issue might be?
> >>> >
> >>> > Thank you,
> >>> > Vincent
> >>> >
> >>> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
> >>> vincent.russell@gmail.com>
> >>> > wrote:
> >>> >
> >>> > > Thank you both for your responses.
> >>> > >
> >>> > > We are using an event store library from a sister project that was
> >>> written
> >>> > > for accumulo 1.10., which I have already upgraded to 2.0.
> >>> > >
> >>> > > I'll spend some time investigating how bad the usage of the internal
> >>> > > packages are and get back to you.
> >>> > >
> >>> > > Thanks again,
> >>> > >
> >>> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <ct...@apache.org>
> >>> wrote:
> >>> > >
> >>> > >> To add to Dave's answer, the public API is defined at
> >>> > >> https://accumulo.apache.org/api/
> >>> > >> Anything else is not public and is subject to change without notice
> >>> on
> >>> > >> any release without any attempt to retain compatibility.
> >>> > >>
> >>> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <dm...@gmail.com>
> >>> wrote:
> >>> > >> >
> >>> > >> > There is no guide. You are using implementation classes (see
> >>> clientImpl
> >>> > >> in
> >>> > >> > the package name) vs. using the client api. If you can use the
> >>> client
> >>> > >> api
> >>> > >> > directly, then this should insulate you from changes in the future
> >>> > >> (except
> >>> > >> > during major versions). We can try and find where things might
> >>> have
> >>> > >> moved,
> >>> > >> > but a class may have been split into multiple pieces. If you could
> >>> > >> provide
> >>> > >> > class and method, that would be easier.
> >>> > >> >
> >>> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
> >>> > >> vincent.russell@gmail.com>
> >>> > >> > wrote:
> >>> > >> >
> >>> > >> > > Is there a guide that shows where classes may have been moved
> >>> with
> >>> > >> moving
> >>> > >> > > from 2.0 to 2.1?  For instance, I am having issues compiling,
> >>> because
> >>> > >> the
> >>> > >> > > following class doesn't exist:
> >>> > >> > > import org.apache.accumulo.core.clientImpl.Tables;
> >>> > >> > >
> >>> > >> > > I'm just getting started so I'm sure there are others.
> >>> > >> > >
> >>> > >> > > Thanks,
> >>> > >> > > Vincent
> >>> > >> > >
> >>> > >> > >
> >>> > >> > >
> >>> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
> >>> > >> vincent.russell@gmail.com>
> >>> > >> > > wrote:
> >>> > >> > >
> >>> > >> > > > I mean Christopher.
> >>> > >> > > >
> >>> > >> > > > Thanks again.
> >>> > >> > > >
> >>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
> >>> > >> > > vincent.russell@gmail.com>
> >>> > >> > > > wrote:
> >>> > >> > > >
> >>> > >> > > >> Thank you Chris.
> >>> > >> > > >>
> >>> > >> > > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or
> >>> later as
> >>> > >> soon as
> >>> > >> > > >> possible.
> >>> > >> > > >>
> >>> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <
> >>> ctubbsii@apache.org>
> >>> > >> wrote:
> >>> > >> > > >>
> >>> > >> > > >>> Hi Vincent,
> >>> > >> > > >>>
> >>> > >> > > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM release,
> >>> and 2.0
> >>> > >> is
> >>> > >> > > >>> not expected to receive any further updates. Version 2.1.0
> >>> may
> >>> > >> work
> >>> > >> > > >>> with ZooKeeper 3.4, but was developed and tested against
> >>> 3.5 and
> >>> > >> later
> >>> > >> > > >>> versions. I believe the ZooKeeper community is currently
> >>> > >> considering
> >>> > >> > > >>> whether to make 3.6 end-of-life themselves, so I would
> >>> recommend
> >>> > >> using
> >>> > >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to
> >>> have the
> >>> > >> best
> >>> > >> > > >>> chance of any kind of support, including JDK 17 support.
> >>> > >> > > >>>
> >>> > >> > > >>> As for your specific issues:
> >>> > >> > > >>>
> >>> > >> > > >>> 1. This is already fixed in 2.1.0
> >>> > >> > > >>> 2/3. These issues are likely fixed in newer ZooKeeper
> >>> versions. I
> >>> > >> > > >>> haven't seen them anytime recently, anyway. Bugs in
> >>> ZooKeeper
> >>> > >> itself
> >>> > >> > > >>> are out of scope for the Accumulo developers, but I have
> >>> tried
> >>> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and
> >>> > >> haven't
> >>> > >> > > >>> observed any unresolved issues. However, it's difficult to
> >>> > >> actually
> >>> > >> > > >>> run it because I don't think Hadoop has good JDK 17 support
> >>> yet.
> >>> > >> So,
> >>> > >> > > >>> MiniAccumuloCluster seems to work with JDK 17, as does
> >>> Accumulo
> >>> > >> and ZK
> >>> > >> > > >>> 3.8, but I don't think a full Hadoop cluster would (yet).
> >>> > >> > > >>>
> >>> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
> >>> > >> > > >>> <vi...@gmail.com> wrote:
> >>> > >> > > >>> >
> >>> > >> > > >>> > Hello,
> >>> > >> > > >>> >
> >>> > >> > > >>> > We are currently using accumulo 2.0.1.
> >>> > >> > > >>> >
> >>> > >> > > >>> > We are in the process of upgrading our source code to use
> >>> jdk 17
> >>> > >> > > >>> however we
> >>> > >> > > >>> > are running into some problems with our tests and the
> >>> > >> > > >>> MiniAccumuloCluster.
> >>> > >> > > >>> >
> >>> > >> > > >>> > One of our developer encountered the following issues:
> >>> > >> > > >>> >
> >>> > >> > > >>> >    1. The MiniAccumumluoClusterImpl._exec is hardcoded
> >>> with the
> >>> > >> JVM
> >>> > >> > > arg
> >>> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no longer tolerated
> >>> with
> >>> > >> JDK17.
> >>> > >> > > >>> >    2. In Zookeeper 3.4.14, ConetStringParser uses
> >>> > >> createUnresolved to
> >>> > >> > > >>> >    make IPAddresses.
> >>> > >> > > >>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> >>> > >> > > >>> >    uses InetSocketAddess.getAddress, which returns null
> >>> because
> >>> > >> it's
> >>> > >> > > >>> not
> >>> > >> > > >>> >    resolved, resulting in a failure to connect to the
> >>> > >> newly-started
> >>> > >> > > >>> zookeeper.
> >>> > >> > > >>> >    3. StaticHostProvider.getHostString() tries to extract
> >>> he
> >>> > >> hostname
> >>> > >> > > >>> by
> >>> > >> > > >>> >    calling toString on the address and taking everything
> >>> before
> >>> > >> the
> >>> > >> > > >>> colon, but
> >>> > >> > > >>> >    in JDK17, the string format changed to
> >>> > >> > > "localhost/<unresolved->:xx"
> >>> > >> > > >>> (where
> >>> > >> > > >>> >    XX is still the port number).  That's incorrect and it
> >>> can't
> >>> > >> > > >>> resolve the
> >>> > >> > > >>> >    names.
> >>> > >> > > >>> >
> >>> > >> > > >>> >
> >>> > >> > > >>> > Has anyone come across/resolved these kinds of issues?
> >>> Is it
> >>> > >> not
> >>> > >> > > >>> possible
> >>> > >> > > >>> > to use java17 from a client perspective?  Will upgrading
> >>> to
> >>> > >> accumulo
> >>> > >> > > >>> 2.1
> >>> > >> > > >>> > help?
> >>> > >> > > >>> >
> >>> > >> > > >>> > Thanks,
> >>> > >> > > >>> > Vincent
> >>> > >> > > >>>
> >>> > >> > > >>
> >>> > >> > >
> >>> > >>
> >>> > >
> >>>
> >>

Re: jdk 17 and accumulo testing

Posted by Vincent Russell <vi...@gmail.com>.
Also in TserverUtils:270, when the TNonblockingServerSocket is created it
looks like it ends up using the default frame size.  I am not sure if this
is intentional or not.

On Thu, Dec 15, 2022 at 3:26 PM Vincent Russell <vi...@gmail.com>
wrote:

> Christopher,
>
> I am not sure if this issue is related to 3042 or not.
>
> On the client side it does look like TConfiguration ends up being called
> with the default constructor.  I am not sure if this is intentional or not.
>
> On the server side I see this stack, so it also looks like:
>
> at org.apache.thrift.TConfiguration.<init>(TConfiguration.java:36)
> at org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
> at org.apache.thrift.TConfiguration.<clinit>(TConfiguration.java:65)
> at
> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:74)
> at
> org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:68)
> at
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
> at
> org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
> at
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
> at
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
> at
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
>
>
> I see this in the server log so it does look like it should be using 1G:
> 2022-09-01 16:59:41 INFO  [org.apache.accumulo.tserver.TabletServer]
> ServerUtil:124 - general.server.message.size.max = 1G
>
> Thanks,
> Vincent
>
> On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <
> vincent.russell@gmail.com> wrote:
>
>>
>>
>> I had to make a stack trace with hacking together a remote debug instance:
>>
>> at
>> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
>> at
>> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
>> at
>> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
>> at
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
>> at
>> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
>>
>> On Thu, Dec 15, 2022 at 12:52 AM Christopher <ct...@apache.org> wrote:
>>
>>> From the numbers in the message, it looks like you're sending an 18MB
>>> payload but something in Thrift is limiting things to 16384000
>>> (16000KB). I doubt you've overridden the default
>>> general.server.message.size.max to be anything that low (the default
>>> is 1G). Unless you're flushing after every mutation, it would not be
>>> surprising to exceed the 16MB max frame size indicated in the error
>>> message quite quickly.
>>>
>>> This value of 16384000 seemed weird. It looks like it's not using our
>>> configuration, but using the built-in default value of
>>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It looks like
>>> this can happen whenever `new TConfiguration()` is called without
>>> parameters... and there's a fair amount of internal code, mostly in
>>> libthrift itself, that does that. It's a bit tricky to track down the
>>> one causing this particular issue. If you have a full stack trace, it
>>> could help.
>>>
>>> Also, this might be the same issue seen reported in
>>> https://github.com/apache/accumulo/issues/3042
>>>
>>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
>>> <vi...@gmail.com> wrote:
>>> >
>>> > I was able to work out all of my compilation issues; however when I
>>> run an
>>> > integration test with the Mini Accumulo Cluster that tests writing
>>> > mutations with values of 5mb the flush hangs forever
>>> > and I see  the following logs in the TabletServer logs:
>>> >
>>> > 20:41:02.306 [Thread-7] ERROR
>>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame
>>> size of
>>> > 18874697, which is bigger than the maximum allowable frame size
>>> 16384000
>>> > for ALL connections.
>>> > 20:41:03.582 [Thread-7] ERROR
>>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame
>>> size of
>>> > 18874697, which is bigger than the maximum allowable frame size
>>> 16384000
>>> > for ALL connections.
>>> > 20:41:05.079 [Thread-7] ERROR
>>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame
>>> size of
>>> > 18874697, which is bigger than the maximum allowable frame size
>>> 16384000
>>> > for ALL connections.
>>> >
>>> > Other tests that write smaller amounts of data appear to work fine.
>>> >
>>> > Any idea what the issue might be?
>>> >
>>> > Thank you,
>>> > Vincent
>>> >
>>> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
>>> vincent.russell@gmail.com>
>>> > wrote:
>>> >
>>> > > Thank you both for your responses.
>>> > >
>>> > > We are using an event store library from a sister project that was
>>> written
>>> > > for accumulo 1.10., which I have already upgraded to 2.0.
>>> > >
>>> > > I'll spend some time investigating how bad the usage of the internal
>>> > > packages are and get back to you.
>>> > >
>>> > > Thanks again,
>>> > >
>>> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <ct...@apache.org>
>>> wrote:
>>> > >
>>> > >> To add to Dave's answer, the public API is defined at
>>> > >> https://accumulo.apache.org/api/
>>> > >> Anything else is not public and is subject to change without notice
>>> on
>>> > >> any release without any attempt to retain compatibility.
>>> > >>
>>> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <dm...@gmail.com>
>>> wrote:
>>> > >> >
>>> > >> > There is no guide. You are using implementation classes (see
>>> clientImpl
>>> > >> in
>>> > >> > the package name) vs. using the client api. If you can use the
>>> client
>>> > >> api
>>> > >> > directly, then this should insulate you from changes in the future
>>> > >> (except
>>> > >> > during major versions). We can try and find where things might
>>> have
>>> > >> moved,
>>> > >> > but a class may have been split into multiple pieces. If you could
>>> > >> provide
>>> > >> > class and method, that would be easier.
>>> > >> >
>>> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
>>> > >> vincent.russell@gmail.com>
>>> > >> > wrote:
>>> > >> >
>>> > >> > > Is there a guide that shows where classes may have been moved
>>> with
>>> > >> moving
>>> > >> > > from 2.0 to 2.1?  For instance, I am having issues compiling,
>>> because
>>> > >> the
>>> > >> > > following class doesn't exist:
>>> > >> > > import org.apache.accumulo.core.clientImpl.Tables;
>>> > >> > >
>>> > >> > > I'm just getting started so I'm sure there are others.
>>> > >> > >
>>> > >> > > Thanks,
>>> > >> > > Vincent
>>> > >> > >
>>> > >> > >
>>> > >> > >
>>> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
>>> > >> vincent.russell@gmail.com>
>>> > >> > > wrote:
>>> > >> > >
>>> > >> > > > I mean Christopher.
>>> > >> > > >
>>> > >> > > > Thanks again.
>>> > >> > > >
>>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
>>> > >> > > vincent.russell@gmail.com>
>>> > >> > > > wrote:
>>> > >> > > >
>>> > >> > > >> Thank you Chris.
>>> > >> > > >>
>>> > >> > > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or
>>> later as
>>> > >> soon as
>>> > >> > > >> possible.
>>> > >> > > >>
>>> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <
>>> ctubbsii@apache.org>
>>> > >> wrote:
>>> > >> > > >>
>>> > >> > > >>> Hi Vincent,
>>> > >> > > >>>
>>> > >> > > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM release,
>>> and 2.0
>>> > >> is
>>> > >> > > >>> not expected to receive any further updates. Version 2.1.0
>>> may
>>> > >> work
>>> > >> > > >>> with ZooKeeper 3.4, but was developed and tested against
>>> 3.5 and
>>> > >> later
>>> > >> > > >>> versions. I believe the ZooKeeper community is currently
>>> > >> considering
>>> > >> > > >>> whether to make 3.6 end-of-life themselves, so I would
>>> recommend
>>> > >> using
>>> > >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to
>>> have the
>>> > >> best
>>> > >> > > >>> chance of any kind of support, including JDK 17 support.
>>> > >> > > >>>
>>> > >> > > >>> As for your specific issues:
>>> > >> > > >>>
>>> > >> > > >>> 1. This is already fixed in 2.1.0
>>> > >> > > >>> 2/3. These issues are likely fixed in newer ZooKeeper
>>> versions. I
>>> > >> > > >>> haven't seen them anytime recently, anyway. Bugs in
>>> ZooKeeper
>>> > >> itself
>>> > >> > > >>> are out of scope for the Accumulo developers, but I have
>>> tried
>>> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and
>>> > >> haven't
>>> > >> > > >>> observed any unresolved issues. However, it's difficult to
>>> > >> actually
>>> > >> > > >>> run it because I don't think Hadoop has good JDK 17 support
>>> yet.
>>> > >> So,
>>> > >> > > >>> MiniAccumuloCluster seems to work with JDK 17, as does
>>> Accumulo
>>> > >> and ZK
>>> > >> > > >>> 3.8, but I don't think a full Hadoop cluster would (yet).
>>> > >> > > >>>
>>> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
>>> > >> > > >>> <vi...@gmail.com> wrote:
>>> > >> > > >>> >
>>> > >> > > >>> > Hello,
>>> > >> > > >>> >
>>> > >> > > >>> > We are currently using accumulo 2.0.1.
>>> > >> > > >>> >
>>> > >> > > >>> > We are in the process of upgrading our source code to use
>>> jdk 17
>>> > >> > > >>> however we
>>> > >> > > >>> > are running into some problems with our tests and the
>>> > >> > > >>> MiniAccumuloCluster.
>>> > >> > > >>> >
>>> > >> > > >>> > One of our developer encountered the following issues:
>>> > >> > > >>> >
>>> > >> > > >>> >    1. The MiniAccumumluoClusterImpl._exec is hardcoded
>>> with the
>>> > >> JVM
>>> > >> > > arg
>>> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no longer tolerated
>>> with
>>> > >> JDK17.
>>> > >> > > >>> >    2. In Zookeeper 3.4.14, ConetStringParser uses
>>> > >> createUnresolved to
>>> > >> > > >>> >    make IPAddresses.
>>> > >> > > >>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
>>> > >> > > >>> >    uses InetSocketAddess.getAddress, which returns null
>>> because
>>> > >> it's
>>> > >> > > >>> not
>>> > >> > > >>> >    resolved, resulting in a failure to connect to the
>>> > >> newly-started
>>> > >> > > >>> zookeeper.
>>> > >> > > >>> >    3. StaticHostProvider.getHostString() tries to extract
>>> he
>>> > >> hostname
>>> > >> > > >>> by
>>> > >> > > >>> >    calling toString on the address and taking everything
>>> before
>>> > >> the
>>> > >> > > >>> colon, but
>>> > >> > > >>> >    in JDK17, the string format changed to
>>> > >> > > "localhost/<unresolved->:xx"
>>> > >> > > >>> (where
>>> > >> > > >>> >    XX is still the port number).  That's incorrect and it
>>> can't
>>> > >> > > >>> resolve the
>>> > >> > > >>> >    names.
>>> > >> > > >>> >
>>> > >> > > >>> >
>>> > >> > > >>> > Has anyone come across/resolved these kinds of issues?
>>> Is it
>>> > >> not
>>> > >> > > >>> possible
>>> > >> > > >>> > to use java17 from a client perspective?  Will upgrading
>>> to
>>> > >> accumulo
>>> > >> > > >>> 2.1
>>> > >> > > >>> > help?
>>> > >> > > >>> >
>>> > >> > > >>> > Thanks,
>>> > >> > > >>> > Vincent
>>> > >> > > >>>
>>> > >> > > >>
>>> > >> > >
>>> > >>
>>> > >
>>>
>>

Re: jdk 17 and accumulo testing

Posted by Vincent Russell <vi...@gmail.com>.
Christopher,

I am not sure if this issue is related to 3042 or not.

On the client side it does look like TConfiguration ends up being called
with the default constructor.  I am not sure if this is intentional or not.

On the server side I see this stack, so it also looks like:

at org.apache.thrift.TConfiguration.<init>(TConfiguration.java:36)
at org.apache.thrift.TConfiguration$Builder.build(TConfiguration.java:99)
at org.apache.thrift.TConfiguration.<clinit>(TConfiguration.java:65)
at
org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:74)
at
org.apache.thrift.transport.TNonblockingSocket.<init>(TNonblockingSocket.java:68)
at
org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:135)
at
org.apache.thrift.transport.TNonblockingServerSocket.accept(TNonblockingServerSocket.java:36)
at
org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.handleAccept(TNonblockingServer.java:218)
at
org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:186)
at
org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)


I see this in the server log so it does look like it should be using 1G:
2022-09-01 16:59:41 INFO  [org.apache.accumulo.tserver.TabletServer]
ServerUtil:124 - general.server.message.size.max = 1G

Thanks,
Vincent

On Thu, Dec 15, 2022 at 12:26 PM Vincent Russell <vi...@gmail.com>
wrote:

>
>
> I had to make a stack trace with hacking together a remote debug instance:
>
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
> at
> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
> at
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
> at
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)
>
> On Thu, Dec 15, 2022 at 12:52 AM Christopher <ct...@apache.org> wrote:
>
>> From the numbers in the message, it looks like you're sending an 18MB
>> payload but something in Thrift is limiting things to 16384000
>> (16000KB). I doubt you've overridden the default
>> general.server.message.size.max to be anything that low (the default
>> is 1G). Unless you're flushing after every mutation, it would not be
>> surprising to exceed the 16MB max frame size indicated in the error
>> message quite quickly.
>>
>> This value of 16384000 seemed weird. It looks like it's not using our
>> configuration, but using the built-in default value of
>> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It looks like
>> this can happen whenever `new TConfiguration()` is called without
>> parameters... and there's a fair amount of internal code, mostly in
>> libthrift itself, that does that. It's a bit tricky to track down the
>> one causing this particular issue. If you have a full stack trace, it
>> could help.
>>
>> Also, this might be the same issue seen reported in
>> https://github.com/apache/accumulo/issues/3042
>>
>> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
>> <vi...@gmail.com> wrote:
>> >
>> > I was able to work out all of my compilation issues; however when I run
>> an
>> > integration test with the Mini Accumulo Cluster that tests writing
>> > mutations with values of 5mb the flush hangs forever
>> > and I see  the following logs in the TabletServer logs:
>> >
>> > 20:41:02.306 [Thread-7] ERROR
>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size
>> of
>> > 18874697, which is bigger than the maximum allowable frame size 16384000
>> > for ALL connections.
>> > 20:41:03.582 [Thread-7] ERROR
>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size
>> of
>> > 18874697, which is bigger than the maximum allowable frame size 16384000
>> > for ALL connections.
>> > 20:41:05.079 [Thread-7] ERROR
>> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size
>> of
>> > 18874697, which is bigger than the maximum allowable frame size 16384000
>> > for ALL connections.
>> >
>> > Other tests that write smaller amounts of data appear to work fine.
>> >
>> > Any idea what the issue might be?
>> >
>> > Thank you,
>> > Vincent
>> >
>> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
>> vincent.russell@gmail.com>
>> > wrote:
>> >
>> > > Thank you both for your responses.
>> > >
>> > > We are using an event store library from a sister project that was
>> written
>> > > for accumulo 1.10., which I have already upgraded to 2.0.
>> > >
>> > > I'll spend some time investigating how bad the usage of the internal
>> > > packages are and get back to you.
>> > >
>> > > Thanks again,
>> > >
>> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <ct...@apache.org>
>> wrote:
>> > >
>> > >> To add to Dave's answer, the public API is defined at
>> > >> https://accumulo.apache.org/api/
>> > >> Anything else is not public and is subject to change without notice
>> on
>> > >> any release without any attempt to retain compatibility.
>> > >>
>> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <dm...@gmail.com>
>> wrote:
>> > >> >
>> > >> > There is no guide. You are using implementation classes (see
>> clientImpl
>> > >> in
>> > >> > the package name) vs. using the client api. If you can use the
>> client
>> > >> api
>> > >> > directly, then this should insulate you from changes in the future
>> > >> (except
>> > >> > during major versions). We can try and find where things might have
>> > >> moved,
>> > >> > but a class may have been split into multiple pieces. If you could
>> > >> provide
>> > >> > class and method, that would be easier.
>> > >> >
>> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
>> > >> vincent.russell@gmail.com>
>> > >> > wrote:
>> > >> >
>> > >> > > Is there a guide that shows where classes may have been moved
>> with
>> > >> moving
>> > >> > > from 2.0 to 2.1?  For instance, I am having issues compiling,
>> because
>> > >> the
>> > >> > > following class doesn't exist:
>> > >> > > import org.apache.accumulo.core.clientImpl.Tables;
>> > >> > >
>> > >> > > I'm just getting started so I'm sure there are others.
>> > >> > >
>> > >> > > Thanks,
>> > >> > > Vincent
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
>> > >> vincent.russell@gmail.com>
>> > >> > > wrote:
>> > >> > >
>> > >> > > > I mean Christopher.
>> > >> > > >
>> > >> > > > Thanks again.
>> > >> > > >
>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
>> > >> > > vincent.russell@gmail.com>
>> > >> > > > wrote:
>> > >> > > >
>> > >> > > >> Thank you Chris.
>> > >> > > >>
>> > >> > > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or later
>> as
>> > >> soon as
>> > >> > > >> possible.
>> > >> > > >>
>> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <
>> ctubbsii@apache.org>
>> > >> wrote:
>> > >> > > >>
>> > >> > > >>> Hi Vincent,
>> > >> > > >>>
>> > >> > > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM release,
>> and 2.0
>> > >> is
>> > >> > > >>> not expected to receive any further updates. Version 2.1.0
>> may
>> > >> work
>> > >> > > >>> with ZooKeeper 3.4, but was developed and tested against 3.5
>> and
>> > >> later
>> > >> > > >>> versions. I believe the ZooKeeper community is currently
>> > >> considering
>> > >> > > >>> whether to make 3.6 end-of-life themselves, so I would
>> recommend
>> > >> using
>> > >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to
>> have the
>> > >> best
>> > >> > > >>> chance of any kind of support, including JDK 17 support.
>> > >> > > >>>
>> > >> > > >>> As for your specific issues:
>> > >> > > >>>
>> > >> > > >>> 1. This is already fixed in 2.1.0
>> > >> > > >>> 2/3. These issues are likely fixed in newer ZooKeeper
>> versions. I
>> > >> > > >>> haven't seen them anytime recently, anyway. Bugs in ZooKeeper
>> > >> itself
>> > >> > > >>> are out of scope for the Accumulo developers, but I have
>> tried
>> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and
>> > >> haven't
>> > >> > > >>> observed any unresolved issues. However, it's difficult to
>> > >> actually
>> > >> > > >>> run it because I don't think Hadoop has good JDK 17 support
>> yet.
>> > >> So,
>> > >> > > >>> MiniAccumuloCluster seems to work with JDK 17, as does
>> Accumulo
>> > >> and ZK
>> > >> > > >>> 3.8, but I don't think a full Hadoop cluster would (yet).
>> > >> > > >>>
>> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
>> > >> > > >>> <vi...@gmail.com> wrote:
>> > >> > > >>> >
>> > >> > > >>> > Hello,
>> > >> > > >>> >
>> > >> > > >>> > We are currently using accumulo 2.0.1.
>> > >> > > >>> >
>> > >> > > >>> > We are in the process of upgrading our source code to use
>> jdk 17
>> > >> > > >>> however we
>> > >> > > >>> > are running into some problems with our tests and the
>> > >> > > >>> MiniAccumuloCluster.
>> > >> > > >>> >
>> > >> > > >>> > One of our developer encountered the following issues:
>> > >> > > >>> >
>> > >> > > >>> >    1. The MiniAccumumluoClusterImpl._exec is hardcoded
>> with the
>> > >> JVM
>> > >> > > arg
>> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no longer tolerated
>> with
>> > >> JDK17.
>> > >> > > >>> >    2. In Zookeeper 3.4.14, ConetStringParser uses
>> > >> createUnresolved to
>> > >> > > >>> >    make IPAddresses.
>> > >> > > >>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
>> > >> > > >>> >    uses InetSocketAddess.getAddress, which returns null
>> because
>> > >> it's
>> > >> > > >>> not
>> > >> > > >>> >    resolved, resulting in a failure to connect to the
>> > >> newly-started
>> > >> > > >>> zookeeper.
>> > >> > > >>> >    3. StaticHostProvider.getHostString() tries to extract
>> he
>> > >> hostname
>> > >> > > >>> by
>> > >> > > >>> >    calling toString on the address and taking everything
>> before
>> > >> the
>> > >> > > >>> colon, but
>> > >> > > >>> >    in JDK17, the string format changed to
>> > >> > > "localhost/<unresolved->:xx"
>> > >> > > >>> (where
>> > >> > > >>> >    XX is still the port number).  That's incorrect and it
>> can't
>> > >> > > >>> resolve the
>> > >> > > >>> >    names.
>> > >> > > >>> >
>> > >> > > >>> >
>> > >> > > >>> > Has anyone come across/resolved these kinds of issues?  Is
>> it
>> > >> not
>> > >> > > >>> possible
>> > >> > > >>> > to use java17 from a client perspective?  Will upgrading to
>> > >> accumulo
>> > >> > > >>> 2.1
>> > >> > > >>> > help?
>> > >> > > >>> >
>> > >> > > >>> > Thanks,
>> > >> > > >>> > Vincent
>> > >> > > >>>
>> > >> > > >>
>> > >> > >
>> > >>
>> > >
>>
>

Re: jdk 17 and accumulo testing

Posted by Vincent Russell <vi...@gmail.com>.
I had to make a stack trace with hacking together a remote debug instance:

at
org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:334)
at
org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.read(CustomNonBlockingServer.java:134)
at
org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:187)
at
org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:189)
at
org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:142)

On Thu, Dec 15, 2022 at 12:52 AM Christopher <ct...@apache.org> wrote:

> From the numbers in the message, it looks like you're sending an 18MB
> payload but something in Thrift is limiting things to 16384000
> (16000KB). I doubt you've overridden the default
> general.server.message.size.max to be anything that low (the default
> is 1G). Unless you're flushing after every mutation, it would not be
> surprising to exceed the 16MB max frame size indicated in the error
> message quite quickly.
>
> This value of 16384000 seemed weird. It looks like it's not using our
> configuration, but using the built-in default value of
> org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It looks like
> this can happen whenever `new TConfiguration()` is called without
> parameters... and there's a fair amount of internal code, mostly in
> libthrift itself, that does that. It's a bit tricky to track down the
> one causing this particular issue. If you have a full stack trace, it
> could help.
>
> Also, this might be the same issue seen reported in
> https://github.com/apache/accumulo/issues/3042
>
> On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
> <vi...@gmail.com> wrote:
> >
> > I was able to work out all of my compilation issues; however when I run
> an
> > integration test with the Mini Accumulo Cluster that tests writing
> > mutations with values of 5mb the flush hangs forever
> > and I see  the following logs in the TabletServer logs:
> >
> > 20:41:02.306 [Thread-7] ERROR
> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size
> of
> > 18874697, which is bigger than the maximum allowable frame size 16384000
> > for ALL connections.
> > 20:41:03.582 [Thread-7] ERROR
> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size
> of
> > 18874697, which is bigger than the maximum allowable frame size 16384000
> > for ALL connections.
> > 20:41:05.079 [Thread-7] ERROR
> > o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size
> of
> > 18874697, which is bigger than the maximum allowable frame size 16384000
> > for ALL connections.
> >
> > Other tests that write smaller amounts of data appear to work fine.
> >
> > Any idea what the issue might be?
> >
> > Thank you,
> > Vincent
> >
> > On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <
> vincent.russell@gmail.com>
> > wrote:
> >
> > > Thank you both for your responses.
> > >
> > > We are using an event store library from a sister project that was
> written
> > > for accumulo 1.10., which I have already upgraded to 2.0.
> > >
> > > I'll spend some time investigating how bad the usage of the internal
> > > packages are and get back to you.
> > >
> > > Thanks again,
> > >
> > > On Tue, Dec 13, 2022 at 3:20 PM Christopher <ct...@apache.org>
> wrote:
> > >
> > >> To add to Dave's answer, the public API is defined at
> > >> https://accumulo.apache.org/api/
> > >> Anything else is not public and is subject to change without notice on
> > >> any release without any attempt to retain compatibility.
> > >>
> > >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <dm...@gmail.com>
> wrote:
> > >> >
> > >> > There is no guide. You are using implementation classes (see
> clientImpl
> > >> in
> > >> > the package name) vs. using the client api. If you can use the
> client
> > >> api
> > >> > directly, then this should insulate you from changes in the future
> > >> (except
> > >> > during major versions). We can try and find where things might have
> > >> moved,
> > >> > but a class may have been split into multiple pieces. If you could
> > >> provide
> > >> > class and method, that would be easier.
> > >> >
> > >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
> > >> vincent.russell@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Is there a guide that shows where classes may have been moved with
> > >> moving
> > >> > > from 2.0 to 2.1?  For instance, I am having issues compiling,
> because
> > >> the
> > >> > > following class doesn't exist:
> > >> > > import org.apache.accumulo.core.clientImpl.Tables;
> > >> > >
> > >> > > I'm just getting started so I'm sure there are others.
> > >> > >
> > >> > > Thanks,
> > >> > > Vincent
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
> > >> vincent.russell@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > I mean Christopher.
> > >> > > >
> > >> > > > Thanks again.
> > >> > > >
> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
> > >> > > vincent.russell@gmail.com>
> > >> > > > wrote:
> > >> > > >
> > >> > > >> Thank you Chris.
> > >> > > >>
> > >> > > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or later
> as
> > >> soon as
> > >> > > >> possible.
> > >> > > >>
> > >> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <
> ctubbsii@apache.org>
> > >> wrote:
> > >> > > >>
> > >> > > >>> Hi Vincent,
> > >> > > >>>
> > >> > > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM release, and
> 2.0
> > >> is
> > >> > > >>> not expected to receive any further updates. Version 2.1.0 may
> > >> work
> > >> > > >>> with ZooKeeper 3.4, but was developed and tested against 3.5
> and
> > >> later
> > >> > > >>> versions. I believe the ZooKeeper community is currently
> > >> considering
> > >> > > >>> whether to make 3.6 end-of-life themselves, so I would
> recommend
> > >> using
> > >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to have
> the
> > >> best
> > >> > > >>> chance of any kind of support, including JDK 17 support.
> > >> > > >>>
> > >> > > >>> As for your specific issues:
> > >> > > >>>
> > >> > > >>> 1. This is already fixed in 2.1.0
> > >> > > >>> 2/3. These issues are likely fixed in newer ZooKeeper
> versions. I
> > >> > > >>> haven't seen them anytime recently, anyway. Bugs in ZooKeeper
> > >> itself
> > >> > > >>> are out of scope for the Accumulo developers, but I have tried
> > >> > > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and
> > >> haven't
> > >> > > >>> observed any unresolved issues. However, it's difficult to
> > >> actually
> > >> > > >>> run it because I don't think Hadoop has good JDK 17 support
> yet.
> > >> So,
> > >> > > >>> MiniAccumuloCluster seems to work with JDK 17, as does
> Accumulo
> > >> and ZK
> > >> > > >>> 3.8, but I don't think a full Hadoop cluster would (yet).
> > >> > > >>>
> > >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
> > >> > > >>> <vi...@gmail.com> wrote:
> > >> > > >>> >
> > >> > > >>> > Hello,
> > >> > > >>> >
> > >> > > >>> > We are currently using accumulo 2.0.1.
> > >> > > >>> >
> > >> > > >>> > We are in the process of upgrading our source code to use
> jdk 17
> > >> > > >>> however we
> > >> > > >>> > are running into some problems with our tests and the
> > >> > > >>> MiniAccumuloCluster.
> > >> > > >>> >
> > >> > > >>> > One of our developer encountered the following issues:
> > >> > > >>> >
> > >> > > >>> >    1. The MiniAccumumluoClusterImpl._exec is hardcoded with
> the
> > >> JVM
> > >> > > arg
> > >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no longer tolerated
> with
> > >> JDK17.
> > >> > > >>> >    2. In Zookeeper 3.4.14, ConetStringParser uses
> > >> createUnresolved to
> > >> > > >>> >    make IPAddresses.
> > >> > > >>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> > >> > > >>> >    uses InetSocketAddess.getAddress, which returns null
> because
> > >> it's
> > >> > > >>> not
> > >> > > >>> >    resolved, resulting in a failure to connect to the
> > >> newly-started
> > >> > > >>> zookeeper.
> > >> > > >>> >    3. StaticHostProvider.getHostString() tries to extract he
> > >> hostname
> > >> > > >>> by
> > >> > > >>> >    calling toString on the address and taking everything
> before
> > >> the
> > >> > > >>> colon, but
> > >> > > >>> >    in JDK17, the string format changed to
> > >> > > "localhost/<unresolved->:xx"
> > >> > > >>> (where
> > >> > > >>> >    XX is still the port number).  That's incorrect and it
> can't
> > >> > > >>> resolve the
> > >> > > >>> >    names.
> > >> > > >>> >
> > >> > > >>> >
> > >> > > >>> > Has anyone come across/resolved these kinds of issues?  Is
> it
> > >> not
> > >> > > >>> possible
> > >> > > >>> > to use java17 from a client perspective?  Will upgrading to
> > >> accumulo
> > >> > > >>> 2.1
> > >> > > >>> > help?
> > >> > > >>> >
> > >> > > >>> > Thanks,
> > >> > > >>> > Vincent
> > >> > > >>>
> > >> > > >>
> > >> > >
> > >>
> > >
>

Re: jdk 17 and accumulo testing

Posted by Christopher <ct...@apache.org>.
From the numbers in the message, it looks like you're sending an 18MB
payload but something in Thrift is limiting things to 16384000
(16000KB). I doubt you've overridden the default
general.server.message.size.max to be anything that low (the default
is 1G). Unless you're flushing after every mutation, it would not be
surprising to exceed the 16MB max frame size indicated in the error
message quite quickly.

This value of 16384000 seemed weird. It looks like it's not using our
configuration, but using the built-in default value of
org.apache.thrift.TConfiguration.DEFAULT_MAX_FRAME_SIZE. It looks like
this can happen whenever `new TConfiguration()` is called without
parameters... and there's a fair amount of internal code, mostly in
libthrift itself, that does that. It's a bit tricky to track down the
one causing this particular issue. If you have a full stack trace, it
could help.

Also, this might be the same issue seen reported in
https://github.com/apache/accumulo/issues/3042

On Wed, Dec 14, 2022 at 8:53 PM Vincent Russell
<vi...@gmail.com> wrote:
>
> I was able to work out all of my compilation issues; however when I run an
> integration test with the Mini Accumulo Cluster that tests writing
> mutations with values of 5mb the flush hangs forever
> and I see  the following logs in the TabletServer logs:
>
> 20:41:02.306 [Thread-7] ERROR
> o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size of
> 18874697, which is bigger than the maximum allowable frame size 16384000
> for ALL connections.
> 20:41:03.582 [Thread-7] ERROR
> o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size of
> 18874697, which is bigger than the maximum allowable frame size 16384000
> for ALL connections.
> 20:41:05.079 [Thread-7] ERROR
> o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size of
> 18874697, which is bigger than the maximum allowable frame size 16384000
> for ALL connections.
>
> Other tests that write smaller amounts of data appear to work fine.
>
> Any idea what the issue might be?
>
> Thank you,
> Vincent
>
> On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <vi...@gmail.com>
> wrote:
>
> > Thank you both for your responses.
> >
> > We are using an event store library from a sister project that was written
> > for accumulo 1.10., which I have already upgraded to 2.0.
> >
> > I'll spend some time investigating how bad the usage of the internal
> > packages are and get back to you.
> >
> > Thanks again,
> >
> > On Tue, Dec 13, 2022 at 3:20 PM Christopher <ct...@apache.org> wrote:
> >
> >> To add to Dave's answer, the public API is defined at
> >> https://accumulo.apache.org/api/
> >> Anything else is not public and is subject to change without notice on
> >> any release without any attempt to retain compatibility.
> >>
> >> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <dm...@gmail.com> wrote:
> >> >
> >> > There is no guide. You are using implementation classes (see clientImpl
> >> in
> >> > the package name) vs. using the client api. If you can use the client
> >> api
> >> > directly, then this should insulate you from changes in the future
> >> (except
> >> > during major versions). We can try and find where things might have
> >> moved,
> >> > but a class may have been split into multiple pieces. If you could
> >> provide
> >> > class and method, that would be easier.
> >> >
> >> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
> >> vincent.russell@gmail.com>
> >> > wrote:
> >> >
> >> > > Is there a guide that shows where classes may have been moved with
> >> moving
> >> > > from 2.0 to 2.1?  For instance, I am having issues compiling, because
> >> the
> >> > > following class doesn't exist:
> >> > > import org.apache.accumulo.core.clientImpl.Tables;
> >> > >
> >> > > I'm just getting started so I'm sure there are others.
> >> > >
> >> > > Thanks,
> >> > > Vincent
> >> > >
> >> > >
> >> > >
> >> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
> >> vincent.russell@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > I mean Christopher.
> >> > > >
> >> > > > Thanks again.
> >> > > >
> >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
> >> > > vincent.russell@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > >> Thank you Chris.
> >> > > >>
> >> > > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or later as
> >> soon as
> >> > > >> possible.
> >> > > >>
> >> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <ct...@apache.org>
> >> wrote:
> >> > > >>
> >> > > >>> Hi Vincent,
> >> > > >>>
> >> > > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM release, and 2.0
> >> is
> >> > > >>> not expected to receive any further updates. Version 2.1.0 may
> >> work
> >> > > >>> with ZooKeeper 3.4, but was developed and tested against 3.5 and
> >> later
> >> > > >>> versions. I believe the ZooKeeper community is currently
> >> considering
> >> > > >>> whether to make 3.6 end-of-life themselves, so I would recommend
> >> using
> >> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to have the
> >> best
> >> > > >>> chance of any kind of support, including JDK 17 support.
> >> > > >>>
> >> > > >>> As for your specific issues:
> >> > > >>>
> >> > > >>> 1. This is already fixed in 2.1.0
> >> > > >>> 2/3. These issues are likely fixed in newer ZooKeeper versions. I
> >> > > >>> haven't seen them anytime recently, anyway. Bugs in ZooKeeper
> >> itself
> >> > > >>> are out of scope for the Accumulo developers, but I have tried
> >> > > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and
> >> haven't
> >> > > >>> observed any unresolved issues. However, it's difficult to
> >> actually
> >> > > >>> run it because I don't think Hadoop has good JDK 17 support yet.
> >> So,
> >> > > >>> MiniAccumuloCluster seems to work with JDK 17, as does Accumulo
> >> and ZK
> >> > > >>> 3.8, but I don't think a full Hadoop cluster would (yet).
> >> > > >>>
> >> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
> >> > > >>> <vi...@gmail.com> wrote:
> >> > > >>> >
> >> > > >>> > Hello,
> >> > > >>> >
> >> > > >>> > We are currently using accumulo 2.0.1.
> >> > > >>> >
> >> > > >>> > We are in the process of upgrading our source code to use jdk 17
> >> > > >>> however we
> >> > > >>> > are running into some problems with our tests and the
> >> > > >>> MiniAccumuloCluster.
> >> > > >>> >
> >> > > >>> > One of our developer encountered the following issues:
> >> > > >>> >
> >> > > >>> >    1. The MiniAccumumluoClusterImpl._exec is hardcoded with the
> >> JVM
> >> > > arg
> >> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no longer tolerated with
> >> JDK17.
> >> > > >>> >    2. In Zookeeper 3.4.14, ConetStringParser uses
> >> createUnresolved to
> >> > > >>> >    make IPAddresses.
> >> > > >>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> >> > > >>> >    uses InetSocketAddess.getAddress, which returns null because
> >> it's
> >> > > >>> not
> >> > > >>> >    resolved, resulting in a failure to connect to the
> >> newly-started
> >> > > >>> zookeeper.
> >> > > >>> >    3. StaticHostProvider.getHostString() tries to extract he
> >> hostname
> >> > > >>> by
> >> > > >>> >    calling toString on the address and taking everything before
> >> the
> >> > > >>> colon, but
> >> > > >>> >    in JDK17, the string format changed to
> >> > > "localhost/<unresolved->:xx"
> >> > > >>> (where
> >> > > >>> >    XX is still the port number).  That's incorrect and it can't
> >> > > >>> resolve the
> >> > > >>> >    names.
> >> > > >>> >
> >> > > >>> >
> >> > > >>> > Has anyone come across/resolved these kinds of issues?  Is it
> >> not
> >> > > >>> possible
> >> > > >>> > to use java17 from a client perspective?  Will upgrading to
> >> accumulo
> >> > > >>> 2.1
> >> > > >>> > help?
> >> > > >>> >
> >> > > >>> > Thanks,
> >> > > >>> > Vincent
> >> > > >>>
> >> > > >>
> >> > >
> >>
> >

Re: jdk 17 and accumulo testing

Posted by Vincent Russell <vi...@gmail.com>.
I was able to work out all of my compilation issues; however when I run an
integration test with the Mini Accumulo Cluster that tests writing
mutations with values of 5mb the flush hangs forever
and I see  the following logs in the TabletServer logs:

20:41:02.306 [Thread-7] ERROR
o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size of
18874697, which is bigger than the maximum allowable frame size 16384000
for ALL connections.
20:41:03.582 [Thread-7] ERROR
o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size of
18874697, which is bigger than the maximum allowable frame size 16384000
for ALL connections.
20:41:05.079 [Thread-7] ERROR
o.a.a.s.r.CustomNonBlockingServer$CustomFrameBuffer - Read a frame size of
18874697, which is bigger than the maximum allowable frame size 16384000
for ALL connections.

Other tests that write smaller amounts of data appear to work fine.

Any idea what the issue might be?

Thank you,
Vincent

On Tue, Dec 13, 2022 at 4:43 PM Vincent Russell <vi...@gmail.com>
wrote:

> Thank you both for your responses.
>
> We are using an event store library from a sister project that was written
> for accumulo 1.10., which I have already upgraded to 2.0.
>
> I'll spend some time investigating how bad the usage of the internal
> packages are and get back to you.
>
> Thanks again,
>
> On Tue, Dec 13, 2022 at 3:20 PM Christopher <ct...@apache.org> wrote:
>
>> To add to Dave's answer, the public API is defined at
>> https://accumulo.apache.org/api/
>> Anything else is not public and is subject to change without notice on
>> any release without any attempt to retain compatibility.
>>
>> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <dm...@gmail.com> wrote:
>> >
>> > There is no guide. You are using implementation classes (see clientImpl
>> in
>> > the package name) vs. using the client api. If you can use the client
>> api
>> > directly, then this should insulate you from changes in the future
>> (except
>> > during major versions). We can try and find where things might have
>> moved,
>> > but a class may have been split into multiple pieces. If you could
>> provide
>> > class and method, that would be easier.
>> >
>> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
>> vincent.russell@gmail.com>
>> > wrote:
>> >
>> > > Is there a guide that shows where classes may have been moved with
>> moving
>> > > from 2.0 to 2.1?  For instance, I am having issues compiling, because
>> the
>> > > following class doesn't exist:
>> > > import org.apache.accumulo.core.clientImpl.Tables;
>> > >
>> > > I'm just getting started so I'm sure there are others.
>> > >
>> > > Thanks,
>> > > Vincent
>> > >
>> > >
>> > >
>> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
>> vincent.russell@gmail.com>
>> > > wrote:
>> > >
>> > > > I mean Christopher.
>> > > >
>> > > > Thanks again.
>> > > >
>> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
>> > > vincent.russell@gmail.com>
>> > > > wrote:
>> > > >
>> > > >> Thank you Chris.
>> > > >>
>> > > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or later as
>> soon as
>> > > >> possible.
>> > > >>
>> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <ct...@apache.org>
>> wrote:
>> > > >>
>> > > >>> Hi Vincent,
>> > > >>>
>> > > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM release, and 2.0
>> is
>> > > >>> not expected to receive any further updates. Version 2.1.0 may
>> work
>> > > >>> with ZooKeeper 3.4, but was developed and tested against 3.5 and
>> later
>> > > >>> versions. I believe the ZooKeeper community is currently
>> considering
>> > > >>> whether to make 3.6 end-of-life themselves, so I would recommend
>> using
>> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to have the
>> best
>> > > >>> chance of any kind of support, including JDK 17 support.
>> > > >>>
>> > > >>> As for your specific issues:
>> > > >>>
>> > > >>> 1. This is already fixed in 2.1.0
>> > > >>> 2/3. These issues are likely fixed in newer ZooKeeper versions. I
>> > > >>> haven't seen them anytime recently, anyway. Bugs in ZooKeeper
>> itself
>> > > >>> are out of scope for the Accumulo developers, but I have tried
>> > > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and
>> haven't
>> > > >>> observed any unresolved issues. However, it's difficult to
>> actually
>> > > >>> run it because I don't think Hadoop has good JDK 17 support yet.
>> So,
>> > > >>> MiniAccumuloCluster seems to work with JDK 17, as does Accumulo
>> and ZK
>> > > >>> 3.8, but I don't think a full Hadoop cluster would (yet).
>> > > >>>
>> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
>> > > >>> <vi...@gmail.com> wrote:
>> > > >>> >
>> > > >>> > Hello,
>> > > >>> >
>> > > >>> > We are currently using accumulo 2.0.1.
>> > > >>> >
>> > > >>> > We are in the process of upgrading our source code to use jdk 17
>> > > >>> however we
>> > > >>> > are running into some problems with our tests and the
>> > > >>> MiniAccumuloCluster.
>> > > >>> >
>> > > >>> > One of our developer encountered the following issues:
>> > > >>> >
>> > > >>> >    1. The MiniAccumumluoClusterImpl._exec is hardcoded with the
>> JVM
>> > > arg
>> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no longer tolerated with
>> JDK17.
>> > > >>> >    2. In Zookeeper 3.4.14, ConetStringParser uses
>> createUnresolved to
>> > > >>> >    make IPAddresses.
>> > > >>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
>> > > >>> >    uses InetSocketAddess.getAddress, which returns null because
>> it's
>> > > >>> not
>> > > >>> >    resolved, resulting in a failure to connect to the
>> newly-started
>> > > >>> zookeeper.
>> > > >>> >    3. StaticHostProvider.getHostString() tries to extract he
>> hostname
>> > > >>> by
>> > > >>> >    calling toString on the address and taking everything before
>> the
>> > > >>> colon, but
>> > > >>> >    in JDK17, the string format changed to
>> > > "localhost/<unresolved->:xx"
>> > > >>> (where
>> > > >>> >    XX is still the port number).  That's incorrect and it can't
>> > > >>> resolve the
>> > > >>> >    names.
>> > > >>> >
>> > > >>> >
>> > > >>> > Has anyone come across/resolved these kinds of issues?  Is it
>> not
>> > > >>> possible
>> > > >>> > to use java17 from a client perspective?  Will upgrading to
>> accumulo
>> > > >>> 2.1
>> > > >>> > help?
>> > > >>> >
>> > > >>> > Thanks,
>> > > >>> > Vincent
>> > > >>>
>> > > >>
>> > >
>>
>

Re: jdk 17 and accumulo testing

Posted by Vincent Russell <vi...@gmail.com>.
Thank you both for your responses.

We are using an event store library from a sister project that was written
for accumulo 1.10., which I have already upgraded to 2.0.

I'll spend some time investigating how bad the usage of the internal
packages are and get back to you.

Thanks again,

On Tue, Dec 13, 2022 at 3:20 PM Christopher <ct...@apache.org> wrote:

> To add to Dave's answer, the public API is defined at
> https://accumulo.apache.org/api/
> Anything else is not public and is subject to change without notice on
> any release without any attempt to retain compatibility.
>
> On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <dm...@gmail.com> wrote:
> >
> > There is no guide. You are using implementation classes (see clientImpl
> in
> > the package name) vs. using the client api. If you can use the client api
> > directly, then this should insulate you from changes in the future
> (except
> > during major versions). We can try and find where things might have
> moved,
> > but a class may have been split into multiple pieces. If you could
> provide
> > class and method, that would be easier.
> >
> > On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <
> vincent.russell@gmail.com>
> > wrote:
> >
> > > Is there a guide that shows where classes may have been moved with
> moving
> > > from 2.0 to 2.1?  For instance, I am having issues compiling, because
> the
> > > following class doesn't exist:
> > > import org.apache.accumulo.core.clientImpl.Tables;
> > >
> > > I'm just getting started so I'm sure there are others.
> > >
> > > Thanks,
> > > Vincent
> > >
> > >
> > >
> > > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <
> vincent.russell@gmail.com>
> > > wrote:
> > >
> > > > I mean Christopher.
> > > >
> > > > Thanks again.
> > > >
> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
> > > vincent.russell@gmail.com>
> > > > wrote:
> > > >
> > > >> Thank you Chris.
> > > >>
> > > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or later as
> soon as
> > > >> possible.
> > > >>
> > > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <ct...@apache.org>
> wrote:
> > > >>
> > > >>> Hi Vincent,
> > > >>>
> > > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM release, and 2.0
> is
> > > >>> not expected to receive any further updates. Version 2.1.0 may work
> > > >>> with ZooKeeper 3.4, but was developed and tested against 3.5 and
> later
> > > >>> versions. I believe the ZooKeeper community is currently
> considering
> > > >>> whether to make 3.6 end-of-life themselves, so I would recommend
> using
> > > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to have the
> best
> > > >>> chance of any kind of support, including JDK 17 support.
> > > >>>
> > > >>> As for your specific issues:
> > > >>>
> > > >>> 1. This is already fixed in 2.1.0
> > > >>> 2/3. These issues are likely fixed in newer ZooKeeper versions. I
> > > >>> haven't seen them anytime recently, anyway. Bugs in ZooKeeper
> itself
> > > >>> are out of scope for the Accumulo developers, but I have tried
> > > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and haven't
> > > >>> observed any unresolved issues. However, it's difficult to actually
> > > >>> run it because I don't think Hadoop has good JDK 17 support yet.
> So,
> > > >>> MiniAccumuloCluster seems to work with JDK 17, as does Accumulo
> and ZK
> > > >>> 3.8, but I don't think a full Hadoop cluster would (yet).
> > > >>>
> > > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
> > > >>> <vi...@gmail.com> wrote:
> > > >>> >
> > > >>> > Hello,
> > > >>> >
> > > >>> > We are currently using accumulo 2.0.1.
> > > >>> >
> > > >>> > We are in the process of upgrading our source code to use jdk 17
> > > >>> however we
> > > >>> > are running into some problems with our tests and the
> > > >>> MiniAccumuloCluster.
> > > >>> >
> > > >>> > One of our developer encountered the following issues:
> > > >>> >
> > > >>> >    1. The MiniAccumumluoClusterImpl._exec is hardcoded with the
> JVM
> > > arg
> > > >>> >    -XX:+IUseConcMarkSweepGC, which is no longer tolerated with
> JDK17.
> > > >>> >    2. In Zookeeper 3.4.14, ConetStringParser uses
> createUnresolved to
> > > >>> >    make IPAddresses.
> > > >>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> > > >>> >    uses InetSocketAddess.getAddress, which returns null because
> it's
> > > >>> not
> > > >>> >    resolved, resulting in a failure to connect to the
> newly-started
> > > >>> zookeeper.
> > > >>> >    3. StaticHostProvider.getHostString() tries to extract he
> hostname
> > > >>> by
> > > >>> >    calling toString on the address and taking everything before
> the
> > > >>> colon, but
> > > >>> >    in JDK17, the string format changed to
> > > "localhost/<unresolved->:xx"
> > > >>> (where
> > > >>> >    XX is still the port number).  That's incorrect and it can't
> > > >>> resolve the
> > > >>> >    names.
> > > >>> >
> > > >>> >
> > > >>> > Has anyone come across/resolved these kinds of issues?  Is it not
> > > >>> possible
> > > >>> > to use java17 from a client perspective?  Will upgrading to
> accumulo
> > > >>> 2.1
> > > >>> > help?
> > > >>> >
> > > >>> > Thanks,
> > > >>> > Vincent
> > > >>>
> > > >>
> > >
>

Re: jdk 17 and accumulo testing

Posted by Christopher <ct...@apache.org>.
To add to Dave's answer, the public API is defined at
https://accumulo.apache.org/api/
Anything else is not public and is subject to change without notice on
any release without any attempt to retain compatibility.

On Tue, Dec 13, 2022 at 3:10 PM Dave Marion <dm...@gmail.com> wrote:
>
> There is no guide. You are using implementation classes (see clientImpl in
> the package name) vs. using the client api. If you can use the client api
> directly, then this should insulate you from changes in the future (except
> during major versions). We can try and find where things might have moved,
> but a class may have been split into multiple pieces. If you could provide
> class and method, that would be easier.
>
> On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <vi...@gmail.com>
> wrote:
>
> > Is there a guide that shows where classes may have been moved with moving
> > from 2.0 to 2.1?  For instance, I am having issues compiling, because the
> > following class doesn't exist:
> > import org.apache.accumulo.core.clientImpl.Tables;
> >
> > I'm just getting started so I'm sure there are others.
> >
> > Thanks,
> > Vincent
> >
> >
> >
> > On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <vi...@gmail.com>
> > wrote:
> >
> > > I mean Christopher.
> > >
> > > Thanks again.
> > >
> > > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
> > vincent.russell@gmail.com>
> > > wrote:
> > >
> > >> Thank you Chris.
> > >>
> > >> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or later as soon as
> > >> possible.
> > >>
> > >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <ct...@apache.org> wrote:
> > >>
> > >>> Hi Vincent,
> > >>>
> > >>> Version 2.0.1 is end of life as of the 2.1.0 LTM release, and 2.0 is
> > >>> not expected to receive any further updates. Version 2.1.0 may work
> > >>> with ZooKeeper 3.4, but was developed and tested against 3.5 and later
> > >>> versions. I believe the ZooKeeper community is currently considering
> > >>> whether to make 3.6 end-of-life themselves, so I would recommend using
> > >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to have the best
> > >>> chance of any kind of support, including JDK 17 support.
> > >>>
> > >>> As for your specific issues:
> > >>>
> > >>> 1. This is already fixed in 2.1.0
> > >>> 2/3. These issues are likely fixed in newer ZooKeeper versions. I
> > >>> haven't seen them anytime recently, anyway. Bugs in ZooKeeper itself
> > >>> are out of scope for the Accumulo developers, but I have tried
> > >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and haven't
> > >>> observed any unresolved issues. However, it's difficult to actually
> > >>> run it because I don't think Hadoop has good JDK 17 support yet. So,
> > >>> MiniAccumuloCluster seems to work with JDK 17, as does Accumulo and ZK
> > >>> 3.8, but I don't think a full Hadoop cluster would (yet).
> > >>>
> > >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
> > >>> <vi...@gmail.com> wrote:
> > >>> >
> > >>> > Hello,
> > >>> >
> > >>> > We are currently using accumulo 2.0.1.
> > >>> >
> > >>> > We are in the process of upgrading our source code to use jdk 17
> > >>> however we
> > >>> > are running into some problems with our tests and the
> > >>> MiniAccumuloCluster.
> > >>> >
> > >>> > One of our developer encountered the following issues:
> > >>> >
> > >>> >    1. The MiniAccumumluoClusterImpl._exec is hardcoded with the JVM
> > arg
> > >>> >    -XX:+IUseConcMarkSweepGC, which is no longer tolerated with JDK17.
> > >>> >    2. In Zookeeper 3.4.14, ConetStringParser uses createUnresolved to
> > >>> >    make IPAddresses.
> > >>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> > >>> >    uses InetSocketAddess.getAddress, which returns null because it's
> > >>> not
> > >>> >    resolved, resulting in a failure to connect to the newly-started
> > >>> zookeeper.
> > >>> >    3. StaticHostProvider.getHostString() tries to extract he hostname
> > >>> by
> > >>> >    calling toString on the address and taking everything before the
> > >>> colon, but
> > >>> >    in JDK17, the string format changed to
> > "localhost/<unresolved->:xx"
> > >>> (where
> > >>> >    XX is still the port number).  That's incorrect and it can't
> > >>> resolve the
> > >>> >    names.
> > >>> >
> > >>> >
> > >>> > Has anyone come across/resolved these kinds of issues?  Is it not
> > >>> possible
> > >>> > to use java17 from a client perspective?  Will upgrading to accumulo
> > >>> 2.1
> > >>> > help?
> > >>> >
> > >>> > Thanks,
> > >>> > Vincent
> > >>>
> > >>
> >

Re: jdk 17 and accumulo testing

Posted by Dave Marion <dm...@gmail.com>.
There is no guide. You are using implementation classes (see clientImpl in
the package name) vs. using the client api. If you can use the client api
directly, then this should insulate you from changes in the future (except
during major versions). We can try and find where things might have moved,
but a class may have been split into multiple pieces. If you could provide
class and method, that would be easier.

On Tue, Dec 13, 2022 at 2:45 PM Vincent Russell <vi...@gmail.com>
wrote:

> Is there a guide that shows where classes may have been moved with moving
> from 2.0 to 2.1?  For instance, I am having issues compiling, because the
> following class doesn't exist:
> import org.apache.accumulo.core.clientImpl.Tables;
>
> I'm just getting started so I'm sure there are others.
>
> Thanks,
> Vincent
>
>
>
> On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <vi...@gmail.com>
> wrote:
>
> > I mean Christopher.
> >
> > Thanks again.
> >
> > On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <
> vincent.russell@gmail.com>
> > wrote:
> >
> >> Thank you Chris.
> >>
> >> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or later as soon as
> >> possible.
> >>
> >> On Thu, Dec 8, 2022 at 8:44 PM Christopher <ct...@apache.org> wrote:
> >>
> >>> Hi Vincent,
> >>>
> >>> Version 2.0.1 is end of life as of the 2.1.0 LTM release, and 2.0 is
> >>> not expected to receive any further updates. Version 2.1.0 may work
> >>> with ZooKeeper 3.4, but was developed and tested against 3.5 and later
> >>> versions. I believe the ZooKeeper community is currently considering
> >>> whether to make 3.6 end-of-life themselves, so I would recommend using
> >>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to have the best
> >>> chance of any kind of support, including JDK 17 support.
> >>>
> >>> As for your specific issues:
> >>>
> >>> 1. This is already fixed in 2.1.0
> >>> 2/3. These issues are likely fixed in newer ZooKeeper versions. I
> >>> haven't seen them anytime recently, anyway. Bugs in ZooKeeper itself
> >>> are out of scope for the Accumulo developers, but I have tried
> >>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and haven't
> >>> observed any unresolved issues. However, it's difficult to actually
> >>> run it because I don't think Hadoop has good JDK 17 support yet. So,
> >>> MiniAccumuloCluster seems to work with JDK 17, as does Accumulo and ZK
> >>> 3.8, but I don't think a full Hadoop cluster would (yet).
> >>>
> >>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
> >>> <vi...@gmail.com> wrote:
> >>> >
> >>> > Hello,
> >>> >
> >>> > We are currently using accumulo 2.0.1.
> >>> >
> >>> > We are in the process of upgrading our source code to use jdk 17
> >>> however we
> >>> > are running into some problems with our tests and the
> >>> MiniAccumuloCluster.
> >>> >
> >>> > One of our developer encountered the following issues:
> >>> >
> >>> >    1. The MiniAccumumluoClusterImpl._exec is hardcoded with the JVM
> arg
> >>> >    -XX:+IUseConcMarkSweepGC, which is no longer tolerated with JDK17.
> >>> >    2. In Zookeeper 3.4.14, ConetStringParser uses createUnresolved to
> >>> >    make IPAddresses.
> >>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> >>> >    uses InetSocketAddess.getAddress, which returns null because it's
> >>> not
> >>> >    resolved, resulting in a failure to connect to the newly-started
> >>> zookeeper.
> >>> >    3. StaticHostProvider.getHostString() tries to extract he hostname
> >>> by
> >>> >    calling toString on the address and taking everything before the
> >>> colon, but
> >>> >    in JDK17, the string format changed to
> "localhost/<unresolved->:xx"
> >>> (where
> >>> >    XX is still the port number).  That's incorrect and it can't
> >>> resolve the
> >>> >    names.
> >>> >
> >>> >
> >>> > Has anyone come across/resolved these kinds of issues?  Is it not
> >>> possible
> >>> > to use java17 from a client perspective?  Will upgrading to accumulo
> >>> 2.1
> >>> > help?
> >>> >
> >>> > Thanks,
> >>> > Vincent
> >>>
> >>
>

Re: jdk 17 and accumulo testing

Posted by Vincent Russell <vi...@gmail.com>.
Is there a guide that shows where classes may have been moved with moving
from 2.0 to 2.1?  For instance, I am having issues compiling, because the
following class doesn't exist:
import org.apache.accumulo.core.clientImpl.Tables;

I'm just getting started so I'm sure there are others.

Thanks,
Vincent



On Fri, Dec 9, 2022 at 9:02 AM Vincent Russell <vi...@gmail.com>
wrote:

> I mean Christopher.
>
> Thanks again.
>
> On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <vi...@gmail.com>
> wrote:
>
>> Thank you Chris.
>>
>> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or later as soon as
>> possible.
>>
>> On Thu, Dec 8, 2022 at 8:44 PM Christopher <ct...@apache.org> wrote:
>>
>>> Hi Vincent,
>>>
>>> Version 2.0.1 is end of life as of the 2.1.0 LTM release, and 2.0 is
>>> not expected to receive any further updates. Version 2.1.0 may work
>>> with ZooKeeper 3.4, but was developed and tested against 3.5 and later
>>> versions. I believe the ZooKeeper community is currently considering
>>> whether to make 3.6 end-of-life themselves, so I would recommend using
>>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to have the best
>>> chance of any kind of support, including JDK 17 support.
>>>
>>> As for your specific issues:
>>>
>>> 1. This is already fixed in 2.1.0
>>> 2/3. These issues are likely fixed in newer ZooKeeper versions. I
>>> haven't seen them anytime recently, anyway. Bugs in ZooKeeper itself
>>> are out of scope for the Accumulo developers, but I have tried
>>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and haven't
>>> observed any unresolved issues. However, it's difficult to actually
>>> run it because I don't think Hadoop has good JDK 17 support yet. So,
>>> MiniAccumuloCluster seems to work with JDK 17, as does Accumulo and ZK
>>> 3.8, but I don't think a full Hadoop cluster would (yet).
>>>
>>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
>>> <vi...@gmail.com> wrote:
>>> >
>>> > Hello,
>>> >
>>> > We are currently using accumulo 2.0.1.
>>> >
>>> > We are in the process of upgrading our source code to use jdk 17
>>> however we
>>> > are running into some problems with our tests and the
>>> MiniAccumuloCluster.
>>> >
>>> > One of our developer encountered the following issues:
>>> >
>>> >    1. The MiniAccumumluoClusterImpl._exec is hardcoded with the JVM arg
>>> >    -XX:+IUseConcMarkSweepGC, which is no longer tolerated with JDK17.
>>> >    2. In Zookeeper 3.4.14, ConetStringParser uses createUnresolved to
>>> >    make IPAddresses.
>>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
>>> >    uses InetSocketAddess.getAddress, which returns null because it's
>>> not
>>> >    resolved, resulting in a failure to connect to the newly-started
>>> zookeeper.
>>> >    3. StaticHostProvider.getHostString() tries to extract he hostname
>>> by
>>> >    calling toString on the address and taking everything before the
>>> colon, but
>>> >    in JDK17, the string format changed to "localhost/<unresolved->:xx"
>>> (where
>>> >    XX is still the port number).  That's incorrect and it can't
>>> resolve the
>>> >    names.
>>> >
>>> >
>>> > Has anyone come across/resolved these kinds of issues?  Is it not
>>> possible
>>> > to use java17 from a client perspective?  Will upgrading to accumulo
>>> 2.1
>>> > help?
>>> >
>>> > Thanks,
>>> > Vincent
>>>
>>

Re: jdk 17 and accumulo testing

Posted by Vincent Russell <vi...@gmail.com>.
I mean Christopher.

Thanks again.

On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell <vi...@gmail.com>
wrote:

> Thank you Chris.
>
> Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or later as soon as
> possible.
>
> On Thu, Dec 8, 2022 at 8:44 PM Christopher <ct...@apache.org> wrote:
>
>> Hi Vincent,
>>
>> Version 2.0.1 is end of life as of the 2.1.0 LTM release, and 2.0 is
>> not expected to receive any further updates. Version 2.1.0 may work
>> with ZooKeeper 3.4, but was developed and tested against 3.5 and later
>> versions. I believe the ZooKeeper community is currently considering
>> whether to make 3.6 end-of-life themselves, so I would recommend using
>> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to have the best
>> chance of any kind of support, including JDK 17 support.
>>
>> As for your specific issues:
>>
>> 1. This is already fixed in 2.1.0
>> 2/3. These issues are likely fixed in newer ZooKeeper versions. I
>> haven't seen them anytime recently, anyway. Bugs in ZooKeeper itself
>> are out of scope for the Accumulo developers, but I have tried
>> building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and haven't
>> observed any unresolved issues. However, it's difficult to actually
>> run it because I don't think Hadoop has good JDK 17 support yet. So,
>> MiniAccumuloCluster seems to work with JDK 17, as does Accumulo and ZK
>> 3.8, but I don't think a full Hadoop cluster would (yet).
>>
>> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
>> <vi...@gmail.com> wrote:
>> >
>> > Hello,
>> >
>> > We are currently using accumulo 2.0.1.
>> >
>> > We are in the process of upgrading our source code to use jdk 17
>> however we
>> > are running into some problems with our tests and the
>> MiniAccumuloCluster.
>> >
>> > One of our developer encountered the following issues:
>> >
>> >    1. The MiniAccumumluoClusterImpl._exec is hardcoded with the JVM arg
>> >    -XX:+IUseConcMarkSweepGC, which is no longer tolerated with JDK17.
>> >    2. In Zookeeper 3.4.14, ConetStringParser uses createUnresolved to
>> >    make IPAddresses.
>> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
>> >    uses InetSocketAddess.getAddress, which returns null because it's not
>> >    resolved, resulting in a failure to connect to the newly-started
>> zookeeper.
>> >    3. StaticHostProvider.getHostString() tries to extract he hostname by
>> >    calling toString on the address and taking everything before the
>> colon, but
>> >    in JDK17, the string format changed to "localhost/<unresolved->:xx"
>> (where
>> >    XX is still the port number).  That's incorrect and it can't resolve
>> the
>> >    names.
>> >
>> >
>> > Has anyone come across/resolved these kinds of issues?  Is it not
>> possible
>> > to use java17 from a client perspective?  Will upgrading to accumulo 2.1
>> > help?
>> >
>> > Thanks,
>> > Vincent
>>
>

Re: jdk 17 and accumulo testing

Posted by Vincent Russell <vi...@gmail.com>.
Thank you Chris.

Will will upgrade to Accumulo 2.1 and  ZooKeeper 3.7 or later as soon as
possible.

On Thu, Dec 8, 2022 at 8:44 PM Christopher <ct...@apache.org> wrote:

> Hi Vincent,
>
> Version 2.0.1 is end of life as of the 2.1.0 LTM release, and 2.0 is
> not expected to receive any further updates. Version 2.1.0 may work
> with ZooKeeper 3.4, but was developed and tested against 3.5 and later
> versions. I believe the ZooKeeper community is currently considering
> whether to make 3.6 end-of-life themselves, so I would recommend using
> Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to have the best
> chance of any kind of support, including JDK 17 support.
>
> As for your specific issues:
>
> 1. This is already fixed in 2.1.0
> 2/3. These issues are likely fixed in newer ZooKeeper versions. I
> haven't seen them anytime recently, anyway. Bugs in ZooKeeper itself
> are out of scope for the Accumulo developers, but I have tried
> building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and haven't
> observed any unresolved issues. However, it's difficult to actually
> run it because I don't think Hadoop has good JDK 17 support yet. So,
> MiniAccumuloCluster seems to work with JDK 17, as does Accumulo and ZK
> 3.8, but I don't think a full Hadoop cluster would (yet).
>
> On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
> <vi...@gmail.com> wrote:
> >
> > Hello,
> >
> > We are currently using accumulo 2.0.1.
> >
> > We are in the process of upgrading our source code to use jdk 17 however
> we
> > are running into some problems with our tests and the
> MiniAccumuloCluster.
> >
> > One of our developer encountered the following issues:
> >
> >    1. The MiniAccumumluoClusterImpl._exec is hardcoded with the JVM arg
> >    -XX:+IUseConcMarkSweepGC, which is no longer tolerated with JDK17.
> >    2. In Zookeeper 3.4.14, ConetStringParser uses createUnresolved to
> >    make IPAddresses.
> SaslServerPrincipal.WrapperInetSocketAddress.getAddress
> >    uses InetSocketAddess.getAddress, which returns null because it's not
> >    resolved, resulting in a failure to connect to the newly-started
> zookeeper.
> >    3. StaticHostProvider.getHostString() tries to extract he hostname by
> >    calling toString on the address and taking everything before the
> colon, but
> >    in JDK17, the string format changed to "localhost/<unresolved->:xx"
> (where
> >    XX is still the port number).  That's incorrect and it can't resolve
> the
> >    names.
> >
> >
> > Has anyone come across/resolved these kinds of issues?  Is it not
> possible
> > to use java17 from a client perspective?  Will upgrading to accumulo 2.1
> > help?
> >
> > Thanks,
> > Vincent
>

Re: jdk 17 and accumulo testing

Posted by Christopher <ct...@apache.org>.
Hi Vincent,

Version 2.0.1 is end of life as of the 2.1.0 LTM release, and 2.0 is
not expected to receive any further updates. Version 2.1.0 may work
with ZooKeeper 3.4, but was developed and tested against 3.5 and later
versions. I believe the ZooKeeper community is currently considering
whether to make 3.6 end-of-life themselves, so I would recommend using
Accumulo 2.1.0 with the latest ZooKeeper 3.7 or later to have the best
chance of any kind of support, including JDK 17 support.

As for your specific issues:

1. This is already fixed in 2.1.0
2/3. These issues are likely fixed in newer ZooKeeper versions. I
haven't seen them anytime recently, anyway. Bugs in ZooKeeper itself
are out of scope for the Accumulo developers, but I have tried
building Accumulo 2.1.0 with JDK 17 and ZooKeeper 3.8.0 and haven't
observed any unresolved issues. However, it's difficult to actually
run it because I don't think Hadoop has good JDK 17 support yet. So,
MiniAccumuloCluster seems to work with JDK 17, as does Accumulo and ZK
3.8, but I don't think a full Hadoop cluster would (yet).

On Thu, Dec 8, 2022 at 12:28 PM Vincent Russell
<vi...@gmail.com> wrote:
>
> Hello,
>
> We are currently using accumulo 2.0.1.
>
> We are in the process of upgrading our source code to use jdk 17 however we
> are running into some problems with our tests and the MiniAccumuloCluster.
>
> One of our developer encountered the following issues:
>
>    1. The MiniAccumumluoClusterImpl._exec is hardcoded with the JVM arg
>    -XX:+IUseConcMarkSweepGC, which is no longer tolerated with JDK17.
>    2. In Zookeeper 3.4.14, ConetStringParser uses createUnresolved to
>    make IPAddresses.  SaslServerPrincipal.WrapperInetSocketAddress.getAddress
>    uses InetSocketAddess.getAddress, which returns null because it's not
>    resolved, resulting in a failure to connect to the newly-started zookeeper.
>    3. StaticHostProvider.getHostString() tries to extract he hostname by
>    calling toString on the address and taking everything before the colon, but
>    in JDK17, the string format changed to "localhost/<unresolved->:xx" (where
>    XX is still the port number).  That's incorrect and it can't resolve the
>    names.
>
>
> Has anyone come across/resolved these kinds of issues?  Is it not possible
> to use java17 from a client perspective?  Will upgrading to accumulo 2.1
> help?
>
> Thanks,
> Vincent