Logan, When not all data is read from the range set on a scanner it can leave scan sessions open on servers, which can result in idle sessions. When the client side scanner object is closed its supposed to clean up any of the open scan sessions related to it. I looked for a test for this and did not find one. Wrote a test and found the batch scanner was not closing sessions when the batch scanner object was closed. Opened https://github.com/apache/accumulo/pull/4841 to fix the batch scanner and add new tests.
Keith On Fri, Aug 23, 2024 at 5:47 PM Logan Jones <lo...@codescratch.com> wrote: > Hi Keith: > > Yes this is very helpful. Seems like the queued and running states are > straight forward. > > For idle, are there any other reasons a scan would drop to idle? We noticed > a decent number of idle scans after we started compactions from the system > user. They lasted about 90 seconds and then went away. My gut instinct is > telling me the client doesn’t care about the response anymore and is timing > out at which point the scan is abandoned? Does that sound plausible to you? > > Thank you! > > - Logan > > On Fri, Aug 23, 2024 at 6:24 PM Keith Turner <ktur...@apache.org> wrote: > > > Logan, > > > > I documented the meaning of those values in the following PR > > > > https://github.com/apache/accumulo/pull/4827 > > > > Does that help? > > > > Keith > > > > On Fri, Aug 23, 2024 at 7:26 AM Logan Jones <lo...@codescratch.com> > wrote: > > > > > Hello > > > > > > I was hoping to understand the different scan states that can be > > > returned by the listscans commands. > > > > > > I've dug around for docs on ScanState but can't find anything > > > immediately enlightening in the code. As far as I can tell, there are 3 > > > scan states: > > > > > > - IDLE > > > - RUNNING > > > - QUEUED > > > > > > Any explanations would be great. > > > > > > Thanks, > > > > > > - Logan > > > > > >
