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
wrote:
> Thank you for the response Christopher.
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
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
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
wrote:
> Ok.. Thank you for the update.
>
> On Fri, Dec 30, 2022 at 11:55 AM Christopher wrote:
Ok.. Thank you for the update.
On Fri, Dec 30, 2022 at 11:55 AM Christopher 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
> wrote:
> >
> > Version 2.1.1 will be released
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
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
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
wrote:
> Hello,
>
> Are there any plans to release an accumulo 2
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
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 Shann
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
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
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 wrote:
> I don'
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
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 intention
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
wrote:
> Christopher,
>
> I am not sure if this issue is related to 3042 or
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.thri
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)
a
>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 muta
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.CustomN
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, De
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 wrote:
>
> There is no guide. You are
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,
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,
Vinc
I mean Christopher.
Thanks again.
On Fri, Dec 9, 2022 at 9:01 AM Vincent Russell
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 wrote:
>
>> Hi Vincent,
>>
>> Version 2.0.1 is end
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 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
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 t
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 i
25 matches
Mail list logo
