Hi Alan,
The era of 32 is over in Apple world. Seems that is the time switching
to x64 everywhere. "640K ought to be enough for anybody ". The problem
is in program up-time. If we are discussing about GUI application,
0xFFFFFFFF is infinity. But from a service point of view it is not so
clear. (Webkit source-save server is a good example, but, yes, it isn't
on Windows.)
I rollback the changes in WindowsWatchService to avoid the blot.
Regards,
-uta
On 5/22/2013 11:58 PM, Alan Bateman wrote:
On 22/05/2013 17:07, Alexey Utkin wrote:
Bug description:
https://jbs.oracle.com/bugs/browse/JDK-8014394
http://bugs.sun.com/view_bug.do?bug_id=8014394
Here is the suggested fix:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8014394/webrev.00/
Summary:
The problem source is the ERROR_MORE_DATA warning event that was
treated as error.
The suggested fix contains limited refactoring that can be critical
for further support.
:
Thanks for finding the ERROR_MORE_DATA case, that was missed in the
original implementation and I can only assume just hasn't been noticed
(maybe because watching a directory over CIFS wouldn't be as common as
local).
On expanding on the width of the completion key then this this
increases the footprint of the key to WatchKey map which doesn't seem
necessary (we originally choose an int as it should be more than
enough for extreme usage over an extended period). Maybe it would be
better to keep the WindowsNativeDispatcher.* changes to use jlong/
ULONG_PTR but revert the usage in WindowsWatchService to avoid the blot.
-Alan.
