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 <ctubb...@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 > <vincent.russ...@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.russ...@gmail.com> > > wrote: > > > > > Ok.. Thank you for the update. > > > > > > On Fri, Dec 30, 2022 at 11:55 AM Christopher <ctubb...@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 > > >> <christopher.l.shan...@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.russ...@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.russ...@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.shan...@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.shan...@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 < > ctubb...@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 > > >> > > >> >> <vincent.russ...@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.russ...@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.russ...@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 < > > >> > > ctubb...@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 > > >> > > >> >> > >>> <vincent.russ...@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.russ...@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 < > > >> > > >> >> ctubb...@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 < > > >> > > >> >> dmario...@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.russ...@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.russ...@gmail.com> > > >> > > >> >> > >>> > >> > > wrote: > > >> > > >> >> > >>> > >> > > > > >> > > >> >> > >>> > >> > > > I mean Christopher. > > >> > > >> >> > >>> > >> > > > > > >> > > >> >> > >>> > >> > > > Thanks again. > > >> > > >> >> > >>> > >> > > > > > >> > > >> >> > >>> > >> > > > On Fri, Dec 9, 2022 at 9:01 AM Vincent > Russell > > >> < > > >> > > >> >> > >>> > >> > > vincent.russ...@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 < > > >> > > >> >> > >>> ctubb...@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 > > >> > > >> >> > >>> > >> > > >>> <vincent.russ...@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 > > >> > > >> >> > >>> > >> > > >>> > > >> > > >> >> > >>> > >> > > >> > > >> > > >> >> > >>> > >> > > > > >> > > >> >> > >>> > >> > > >> > > >> >> > >>> > > > > >> > > >> >> > >>> > > >> > > >> >> > >> > > >> > > >> >> > > >> > > >> > > > >> > > >> > > >> > > > > > >> > > > > >> > > > >
