On Fri, Nov 20, 2015 at 11:08 AM, Ivan V. <iveselovs...@gridgain.com> wrote:
> Hi, Dmitriy, > to wait for memory freeing we have > method > org.apache.ignite.internal.processors.igfs.IgfsEx#awaitDeletesAsync() > which returns a Future that can be awaited (with a timeout or without). > Also during recent fix https://issues.apache.org/jira/browse/IGNITE-1510 > we > introduced new method IgfsEx#clear(IgfsPath) that deletes the specified > path and waits for the garbage data cleanup. > These methods have more or less convenient usage pattern. > But it is much more difficult to use PURGE events in practice. E.g. how to > know how many events to expect, and how to track what events have arrived, > and what have not? > Ivan, I see your point. There are 2 ways to resolve it, we either deprecate the event, or we support it properly. How difficult, in your opinion, it would be to support this even properly. > > On Fri, Nov 20, 2015 at 9:10 PM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > Ivan, > > > > The importance of the PURGE event has to do with notification about > freeing > > memory, otherwise occupied by a deleted file. > > > > How hard do you think would be making the PURGE behavior consistent > between > > directory and file deletions? > > > > D > > > > On Fri, Nov 20, 2015 at 8:15 AM, Ivan V. <iveselovs...@gridgain.com> > > wrote: > > > > > Hi, dev, > > > need opinions on the question discussed in > > > https://issues.apache.org/jira/browse/IGNITE-1679 (IGFS: Purge event > is > > > inconsistent). > > > In short: in Igfs we have "soft" delete that moves the deleted file or > > > folder to special "TRASH" folder. > > > Special async worker walks inside TRASH and removes the items > > permanently. > > > When an item is completely removed, an event of type > > > org.apache.ignite.events.EventType#EVT_IGFS_FILE_PURGED is fired. > > > But such events are now fired only for files, and only in case if such > > file > > > was deleted itself, but not a part of a folder sub-tree. It's quite > > obvious > > > that such behavior is not quite consistent, so we should either get rid > > of > > > PURGE events at all, or make them consistent. > > > In the latter case it would be good to have answer to the question: > what > > > are real use cases when we may need the purge events ? (Now they seem > to > > > be used in tests only). > > > If we don't have such real use cases, are there any objections to get > rid > > > of the purge events at all? > > > Thanks in advance. > > > > > >
