[JBoss JIRA] (ISPN-5576) Use MessageToByteEncoder to avoid ByteBuf leak w/ exceptions
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5576?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5576:
-----------------------------------
Description:
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.
was:
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()
{code}
Also, encoder implementation does not log exceptions reported at encoding time, so exceptions like this can only be noticed via instrumentation.
> 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, 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)
8 years, 10 months
[JBoss JIRA] (ISPN-5576) Use MessageToByteEncoder to avoid ByteBuf leak w/ exceptions
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-5576:
--------------------------------------
Summary: 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, 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()
{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)
8 years, 10 months
[JBoss JIRA] (ISPN-5567) CreateCacheCommand waiting for a number of members should be optional
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5567?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5567:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 8.0.0.Final
Resolution: Done
> CreateCacheCommand waiting for a number of members should be optional
> ---------------------------------------------------------------------
>
> Key: ISPN-5567
> URL: https://issues.jboss.org/browse/ISPN-5567
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 8.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 8.0.0.Beta1, 8.0.0.Final
>
>
> CLI allows the user to create a cache on all the nodes with {{create <newCache> like <existingCache>;}}.
> It doesn't specify an expected number of members, so {{CreateCacheCommand}} shouldn't block. However, after of the ISPN-5534 fix, the {{CreateCacheCommand}} invocation would always time out waiting for {{0}} members. This causes {{ClusteredCLITest.testCreateCluster()}} to always fail.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5548) Realign JGroups subsystem with the one from WildFly
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5548?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5548:
----------------------------------
Status: Open (was: New)
> Realign JGroups subsystem with the one from WildFly
> ---------------------------------------------------
>
> Key: ISPN-5548
> URL: https://issues.jboss.org/browse/ISPN-5548
> Project: Infinispan
> Issue Type: Task
> Components: Server
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 8.0.0.Final
>
>
> The JGroups subsystem in WildFly has evolved to support forked channels and has also been including the relay support which he had grafted on.
> We should rebase our own on the WildFly one, add any delta (SASL), package it to make it standalone (the WildFly one depends on a variety of clustering modules) and give it its own management model name to distinguish from the WildFly one to allow parallel installation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5575) Shared write-behind store can read stale entries on joiner
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5575?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-5575:
------------------------------------
It doesn't matter if the shared store is configured with {{shared="true"}} or with {{singleton="true"}}. Both options will allow a joiner to read keys that it doesn't have in memory directly from the store, after state transfer is over, and state transfer can finish before AsyncCacheWriter writes all the modifications to the store.
> Shared write-behind store can read stale entries on joiner
> ----------------------------------------------------------
>
> Key: ISPN-5575
> URL: https://issues.jboss.org/browse/ISPN-5575
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Loaders and Stores
> Affects Versions: 8.0.0.Alpha2, 7.2.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.0.0.Final
>
>
> The AsyncCacheWriter modification queue is not sent with state transfer when the store is shared. A joiner can then read from the shared store a stale version of entries that have updates in the modification queue but are no longer in memory (because they were either removed explicitly, or evicted).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5575) Shared async store can read stale entries on joiner
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5575?page=com.atlassian.jira.plugin.... ]
Dan Berindei reassigned ISPN-5575:
----------------------------------
Assignee: Dan Berindei
> Shared async store can read stale entries on joiner
> ---------------------------------------------------
>
> Key: ISPN-5575
> URL: https://issues.jboss.org/browse/ISPN-5575
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Loaders and Stores
> Affects Versions: 8.0.0.Alpha2, 7.2.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.0.0.Final
>
>
> The AsyncCacheWriter modification queue is not sent with state transfer when the store is shared. A joiner can then read from the shared store a stale version of entries that have updates in the modification queue but are no longer in memory (because they were either removed explicitly, or evicted).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5575) Shared write-behind store can read stale entries on joiner
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5575?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5575:
-------------------------------
Summary: Shared write-behind store can read stale entries on joiner (was: Shared async store can read stale entries on joiner)
> Shared write-behind store can read stale entries on joiner
> ----------------------------------------------------------
>
> Key: ISPN-5575
> URL: https://issues.jboss.org/browse/ISPN-5575
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Loaders and Stores
> Affects Versions: 8.0.0.Alpha2, 7.2.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.0.0.Final
>
>
> The AsyncCacheWriter modification queue is not sent with state transfer when the store is shared. A joiner can then read from the shared store a stale version of entries that have updates in the modification queue but are no longer in memory (because they were either removed explicitly, or evicted).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months