[JBoss JIRA] (ISPN-5665) Query should not rely on the results of return values of write commands
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-5665?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-5665:
----------------------------------
Status: Open (was: New)
> Query should not rely on the results of return values of write commands
> -----------------------------------------------------------------------
>
> Key: ISPN-5665
> URL: https://issues.jboss.org/browse/ISPN-5665
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.0.0.Beta2
> Reporter: Dan Berindei
> Fix For: 8.0.0.Final
>
>
> The query interceptor relies on the return value of the write commands to know the previous value of the modified entries. This is not correct, because some write commands do not return the previous value, e.g. {{remove(key, value)}}, {{replace(key, oldValue, newValue)}}, and {{putAll(map)}}.
> The query interceptor should instead look up the previous values in the invocation context, and also force the loading of old values in the invocation context if the command doesn't do it explicitly (e.g. {{putAll(map)}}, or {{put(k, v)}} with the {{IGNORE_RETURN_VALUES}} flag).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (ISPN-5665) Query should not rely on the results of return values of write commands
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5665?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-5665:
------------------------------------
Note that {{PutMapCommand}} does return a map of the previous values, but it doesn't force the loading of values from stores, so those previous values are not reliable.
> Query should not rely on the results of return values of write commands
> -----------------------------------------------------------------------
>
> Key: ISPN-5665
> URL: https://issues.jboss.org/browse/ISPN-5665
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.0.0.Beta2
> Reporter: Dan Berindei
> Fix For: 8.0.0.Final
>
>
> The query interceptor relies on the return value of the write commands to know the previous value of the modified entries. This is not correct, because some write commands do not return the previous value, e.g. {{remove(key, value)}}, {{replace(key, oldValue, newValue)}}, and {{putAll(map)}}.
> The query interceptor should instead look up the previous values in the invocation context, and also force the loading of old values in the invocation context if the command doesn't do it explicitly (e.g. {{putAll(map)}}, or {{put(k, v)}} with the {{IGNORE_RETURN_VALUES}} flag).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (ISPN-5665) Query should not rely on the results of return values of write commands
by Dan Berindei (JIRA)
Dan Berindei created ISPN-5665:
----------------------------------
Summary: Query should not rely on the results of return values of write commands
Key: ISPN-5665
URL: https://issues.jboss.org/browse/ISPN-5665
Project: Infinispan
Issue Type: Bug
Components: Embedded Querying
Affects Versions: 8.0.0.Beta2
Reporter: Dan Berindei
Fix For: 8.0.0.Final
The query interceptor relies on the return value of the write commands to know the previous value of the modified entries. This is not correct, because some write commands do not return the previous value, e.g. {{remove(key, value)}}, {{replace(key, oldValue, newValue)}}, and {{putAll(map)}}.
The query interceptor should instead look up the previous values in the invocation context, and also force the loading of old values in the invocation context if the command doesn't do it explicitly (e.g. {{putAll(map)}}, or {{put(k, v)}} with the {{IGNORE_RETURN_VALUES}} flag).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (ISPN-5596) "Cannot clear data directory" in SoftIndexFileStore when clear() is called after stopping and restarting cache
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-5596?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-5596:
-----------------------------------
Thanks, so it seems that the FileChannel is closed properly and you're hitting some quirk on Windows. Please, re-fetch https://github.com/rvansa/infinispan/tree/t_sifs_logging and give it one more run, I've tried to apply some suggestions from SO.
Btw., what version of JDK/JRE do you use?
> "Cannot clear data directory" in SoftIndexFileStore when clear() is called after stopping and restarting cache
> --------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5596
> URL: https://issues.jboss.org/browse/ISPN-5596
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 7.2.3.Final
> Environment: Windows 7
> Reporter: Andreas Pabst
> Assignee: Radim Vansa
> Attachments: SoftIndexFileStoreTest.java, test.log, test2.log
>
>
> When stopping and restarting a cache with SoftIndexFileStore persistence, it behaves strangely.
> Calling cache.clear() leads to the following exception:
> ERROR: ISPN000136: Execution error
> org.infinispan.persistence.spi.PersistenceException: Cannot clear data directory!
> at org.infinispan.persistence.sifs.SoftIndexFileStore.clear(SoftIndexFileStore.java:234)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.clearAllStores(PersistenceManagerImpl.java:372)
> at org.infinispan.interceptors.CacheWriterInterceptor.visitClearCommand(CacheWriterInterceptor.java:158)
> ...
> Caused by: java.io.IOException: Cannot delete file soft-index-test\data\2
> at org.infinispan.persistence.sifs.FileProvider.clear(FileProvider.java:205)
> at org.infinispan.persistence.sifs.SoftIndexFileStore.clear(SoftIndexFileStore.java:232)
> If the manager is also stopped and recreated every time, this only happens after the third iteration.
> Calling cache.remove() in the same place leads to an unrecoverable corruption of the cache store files: java.lang.IllegalArgumentException: Negative position
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (ISPN-5379) Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5379?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5379:
-----------------------------------------------
Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1212505|https://bugzilla.redhat.com/show_bug.cgi?id=1212505] from ASSIGNED to POST
> Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache
> ----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5379
> URL: https://issues.jboss.org/browse/ISPN-5379
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Loaders and Stores
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.0.0.Final
>
>
> From Dennis Reed:
> A ConcurrentModificationException in the CacheWriter interceptor during a commit.
> java.util.ConcurrentModificationException
> at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:953)
> at java.util.LinkedList$ListItr.next(LinkedList.java:886)
> at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:210)
> at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115)
> The code is looping through the modifications associated with the transaction:
> List<WriteCommand> modifications = ctx.getCacheTransaction().getAllModifications();
> ...
> 210: for (WriteCommand cacheCommand : modifications) {
> The transaction's modification list is stored as a synchronized list with a comment "we need to synchronize this collection to be able to get a valid snapshot from another thread during state transfer".
> But this thread is not doing state transfer, and I'd assume "get a valid snapshot" wouldn't include modification?
> Is it valid for this list to be modified from another thread (in which case all iterations should be synchronized), or is something modifying it incorrectly?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (ISPN-5576) Use MessageToByteEncoder to avoid ByteBuf leak w/ exceptions
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5576?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5576:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1248999|https://bugzilla.redhat.com/show_bug.cgi?id=1248999] from MODIFIED to ON_QA
> Use MessageToByteEncoder to avoid ByteBuf leak w/ exceptions
> ------------------------------------------------------------
>
> Key: ISPN-5576
> URL: https://issues.jboss.org/browse/ISPN-5576
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 7.2.3.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.0.0.Beta1, 7.2.4.Final, 8.0.0.Final
>
>
> Encoder implementation allocates buffers but does not release them in case of exception before the encoded buffer is added to the response list. As a result, if encoding faces exceptions, it could leak byte buffers and show messages like this:
> {code}
> [io.netty.util.ResourceLeakDetector] LEAK: ByteBuf.release() was not called before it's garbage-collected.
> Enable advanced leak reporting to find out where the leak occurred. To enable advanced leak reporting,
> specify the JVM option '-Dio.netty.leakDetectionLevel=advanced' or call ResourceLeakDetector.setLevel()
> LEAK: ByteBuf.release() was not called before it's garbage-collected.
> Recent access records: 0
> Created at:
> io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:259)
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:155)
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:141)
> io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:75)
> org.infinispan.server.hotrod.HotRodEncoder.encode(HotRodEncoder.scala:29)
> io.netty.handler.codec.MessageToMessageEncoder.write(MessageToMessageEncoder.java:89)
> io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:633)
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:691)
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:626)
> io.netty.handler.timeout.IdleStateHandler.write(IdleStateHandler.java:266)
> io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:633)
> io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:691)
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:681)
> io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:716)
> io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:954)
> io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:243)
> org.infinispan.server.core.AbstractProtocolDecoder.writeResponse(AbstractProtocolDecoder.scala:220)
> org.infinispan.server.hotrod.HotRodDecoder.customDecodeHeader(HotRodDecoder.scala:153)
> org.infinispan.server.core.AbstractProtocolDecoder.org$infinispan$server$core$AbstractProtocolDecoder$$decodeHeader(AbstractProtocolDecoder.scala:137)
> org.infinispan.server.core.AbstractProtocolDecoder$$anon$2.run(AbstractProtocolDecoder.scala:98)
> org.infinispan.server.core.AbstractProtocolDecoder$$anon$2.run(AbstractProtocolDecoder.scala:95)
> org.infinispan.security.Security.doAs(Security.java:143)
> org.infinispan.server.core.AbstractProtocolDecoder.secureDecodeDispatch(AbstractProtocolDecoder.scala:95)
> org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:59)
> io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:370)
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:168)
> org.infinispan.server.core.AbstractProtocolDecoder.channelRead(AbstractProtocolDecoder.scala:459)
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294)
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846)
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:130)
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
> io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> java.lang.Thread.run(Thread.java:745)
> {code}
> Also, encoder implementation does not log exceptions reported at encoding time, so exceptions like this can only be noticed via instrumentation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (ISPN-5523) Enabling eager caching can lead to sever throwing "OutOfMemoryError: Direct buffer memory"
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5523?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5523:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1248999|https://bugzilla.redhat.com/show_bug.cgi?id=1248999] from MODIFIED to ON_QA
> Enabling eager caching can lead to sever throwing "OutOfMemoryError: Direct buffer memory"
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-5523
> URL: https://issues.jboss.org/browse/ISPN-5523
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 7.2.2.Final, 8.0.0.Alpha1
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.2.4.Final, 8.0.0.CR1
>
>
> Some near caching tests are throwing:
> {code}
> [0m[31m04:11:24,499 ERROR [org.infinispan.server.hotrod.CacheDecodeContext] (HotRodServerWorker-43) ISPN005009: Unexpected error before any request parameters read: java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:658) [rt.jar:1.7.0_75]
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123) [rt.jar:1.7.0_75]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:306) [rt.jar:1.7.0_75]
> at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:433) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:179) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.buffer.PoolArena.allocate(PoolArena.java:168) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.buffer.PoolArena.allocate(PoolArena.java:98) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:241) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:155) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:146) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.buffer.AbstractByteBufAllocator.ioBuffer(AbstractByteBufAllocator.java:107) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:106) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:494) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:461) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
> {code}
> KeyValueVersionConverter allocates a byte buffer but does not release it. It could be the cause...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months