dlmarion commented on PR #3187:
URL: https://github.com/apache/accumulo/pull/3187#issuecomment-1420627043
> I haven't seen any reason even proposed, least of all a substantially
compelling one.
This was something that a user noticed their client waiting on, and not
performing scans, when the user thought scans should have been running.
> My understanding is that the specific use case is consistency from the
same client, to ensure that a previous write is visible on subsequent scans.
> I don't believe this was for same client. The wait for write behavior is
for the following case.
> client does a write and then the client process dies
> client process starts again and does a read, expecting to see anything it
wrote before. However if the write is still in flight on the tserver side it
may not see it.
My understanding of the use-case for waiting for writes is you have an
application running on a host, the application
dies and is restarted, so you want the application to wait for writes to
finish before reading. The current implementation makes several assumptions:
1. All user applications both read and write data.
2. All newly started applications are able to wait for some unknown amount
of time for writes to complete before their scans can start.
3. That in an environment where you could be constantly loading data, the
application performing scans has an understanding of what consistent means.
The thought here was to be able to bypass the wait condition in the client
for user tables. I have no issue with the implementation being done at the
table or scanner level. I think doing it as either a client property or scanner
setting would be easier, as it would not involve any server side code to deal
with the table property. Doing it at the client seemed sufficient to meet the
needs of an application running in an environment where 1, 2, and 3 were not
the case.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
