Project

General

Profile

Bug #4992

File lock with JSON Parse/Write File

Added by Marian Edu over 5 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

History

#1 Updated by Greg Shah over 5 years ago

  • Description updated (diff)

From Marian:

There seems to be a locking issue that we're experiencing with ParseFile (ObjectModelParser) and WriteFile (JsonConstruct) looks like being related to memory mapped files and might just be Windows specific. I've put together a test in oo/json/quirks/file_lock.p but then while writing this thought to check with plain input/output streams and it gives the same error `Unable to open... (98)`.

We have that in one of the tests for http client state management where we need to make sure we don't have any cookies persisted in the jar so we call clearPersistentCookies which in turn override the cookie jar file after emptying the jar. That was silently failing before but after adding routine level option on JsonConstruct the error gets propagated, silently eating it is not a valid option imho anyway :)

#2 Updated by Marian Edu over 5 years ago

Just to clarify, it looks like the issue comes from opening the file read-only. We open, close the log file constantly to write messages and there is no problem in this scenario.

Somewhere when opening the file read-only the file gets memmapped, on unmap the buffer linger there until GC and seems to be a known issue. Forcing GC might not be the best idea, I've seen the suggestion of using DirectByteBuffer using reflection but don't like using internal classes. Only using memory mapped for write seems to solve the issue, read only files are read in a ByteBuffer instead of mapped one. However I can see why memory mapped could be better, at least for large files or constantly accessed ones :(

#3 Updated by Greg Shah over 5 years ago

Does this happen on both Linux and Windows?

#4 Updated by Greg Shah over 5 years ago

What JDK do you use (post output of java -version)?

#5 Updated by Marian Edu over 5 years ago

Greg Shah wrote:

What JDK do you use (post output of java -version)?

java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

#6 Updated by Marian Edu over 5 years ago

Greg Shah wrote:

Does this happen on both Linux and Windows?

We were only working on Windows for now but this might not be OS specific...

A mapped byte buffer and the file mapping that it represents remain valid until the buffer itself is garbage-collected.

The unmap method in FileStream does set the buffer to null but then this does not guaranty is being GC hence actually disposed :(

Also available in: Atom PDF