[
https://issues.apache.org/jira/browse/IGNITE-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15423105#comment-15423105
]
Valentin Kulichenko edited comment on IGNITE-3197 at 8/16/16 5:26 PM:
----------------------------------------------------------------------
Agree. Actually, I'm not sure it's even possible, because we should check for
collisions when updating the meta cache.
was (Author: vkulichenko):
Agree. Actually, I'm not sure it's even possible, because we should check
collisions when updating the meta cache.
> OverlappingFileLockException in marshaller context
> --------------------------------------------------
>
> Key: IGNITE-3197
> URL: https://issues.apache.org/jira/browse/IGNITE-3197
> Project: Ignite
> Issue Type: Bug
> Components: general
> Affects Versions: 1.6
> Reporter: Valentin Kulichenko
> Assignee: Andrey Velichko
> Priority: Minor
> Labels: important
> Fix For: 1.8
>
>
> {{MarshallerContextImpl}} uses static locks to avoid writing to the same file
> concurrently. But if Ignite is running embedded in managed environment (e.g.,
> application server), it's possible that there will be two clients loaded by
> different class loaders. In this case they will not share these static locks
> and therefore they can try to acquire the file lock for the same file,
> causing the {{OverlappingFileLockException}}:
> {noformat}
> [#|2016-05-17T08:02:21.950+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=291;_ThreadName=Thread-2;|java.nio.channels.OverlappingFileLockException
> at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
> at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)
> at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1011)
> at
> org.apache.ignite.internal.MarshallerContextImpl$ContinuousQueryListener.onUpdated(MarshallerContextImpl.java:239)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback(CacheContinuousQueryHandler.java:655)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:967)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$1900(GridContinuousProcessor.java:94)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:612)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1058)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:104)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2295)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1018)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:104)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:987)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> |#]
> {noformat}
> It's actually harmless, but the logs are flooded with the errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)