[JBoss JIRA] (ISPN-6332) L1CachingIT random failures
by Dan Berindei (JIRA)
Dan Berindei created ISPN-6332:
----------------------------------
Summary: L1CachingIT random failures
Key: ISPN-6332
URL: https://issues.jboss.org/browse/ISPN-6332
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Server
Affects Versions: 8.2.0.CR1
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 8.2.0.Final
The test inserts 3 keys in a distributed cache with 2 members and {{numOwners == 1}}, and asserts that each member will have at least one key.
This worked prior to ISPN-4851, because the distribution of keys was always the same, but it is no longer reliable now:
{noformat}
java.lang.AssertionError: Distribution of entries is wrong (at least unexpected).
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.infinispan.server.test.l1.L1CachingIT.testL1CachingEnabled(L1CachingIT.java:85)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6332) L1CachingIT random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6332?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6332:
-------------------------------
Status: Open (was: New)
> L1CachingIT random failures
> ---------------------------
>
> Key: ISPN-6332
> URL: https://issues.jboss.org/browse/ISPN-6332
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 8.2.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 8.2.0.Final
>
>
> The test inserts 3 keys in a distributed cache with 2 members and {{numOwners == 1}}, and asserts that each member will have at least one key.
> This worked prior to ISPN-4851, because the distribution of keys was always the same, but it is no longer reliable now:
> {noformat}
> java.lang.AssertionError: Distribution of entries is wrong (at least unexpected).
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.infinispan.server.test.l1.L1CachingIT.testL1CachingEnabled(L1CachingIT.java:85)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6307) Add datatype metadata script parameter for dealing with UTF-8 Strings
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-6307?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-6307:
-----------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/4067, https://github.com/infinispan/infinispan/pull/4085 (was: https://github.com/infinispan/infinispan/pull/4067)
> Add datatype metadata script parameter for dealing with UTF-8 Strings
> ---------------------------------------------------------------------
>
> Key: ISPN-6307
> URL: https://issues.jboss.org/browse/ISPN-6307
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 8.2.0.Final
>
>
> Hot Rod's 'execute' operation is tightly coupled with JBoss Marshalling making it difficult to run an execute operation from Javascript, who currently supports plain, UTF-8 String keys and values.
> The essence of the problem is that the server marshalls parameters and return values instead of having the client drive how these are marshalled. As a result of this, for a JS or C++ client to be able to use `exec` with default configuration, they need to understand JBoss Marshaller format, which is not good.
> IOW, if a JS client sends a UTF-8 string as parameter, server tries to unmarshall it using the JBoss Marshaller and it fails. This happens because exec assumes the client is a Java client. The same happens with the return value.
> On top of that, the script run from Javascript would be expect cached values to be Strings.
> In order to accommodate the JS client's needs to support plain UTF-8 Strings, and also help C/C++ client, it was decided to add a new metadata parameter to the script called `datatype` which for JS scripts, it would take as value `utf8`.
> When `datatype=utf8`, the following will happen:
> 1. Parameters to the script will be assumed to be UTF-8 Strings.
> 2. Cached values would be assumed to be Strings.
> 3. The return type of the script will be transformed into byte[] encoded as UTF-8 String.
> When `datatype=utf8` is defined, no attempt to interoperate with data stored using a Java Hot Rod client or a REST client. To get such interoperability, compatibility mode would need to be enabled and both Java HR client and JS/C++ client would need to share the same marshaller. This is not yet in place but will come.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6331) Netty buffer leak RESTAsyncIT
by Dan Berindei (JIRA)
Dan Berindei created ISPN-6331:
----------------------------------
Summary: Netty buffer leak RESTAsyncIT
Key: ISPN-6331
URL: https://issues.jboss.org/browse/ISPN-6331
Project: Infinispan
Issue Type: Bug
Components: Server
Affects Versions: 8.2.0.CR1
Reporter: Dan Berindei
This is the leak report when running the server with {{-Dio.netty.leakDetectionLevel=advanced}}:
{noformat}
12:59:12,985 SEVERE [io.netty.util.ResourceLeakDetector] (nioEventLoopGroup-2-2) LEAK: ByteBuf.release() was not called before it's garbage-collected.
Recent access records: 4
#4:
io.netty.buffer.AdvancedLeakAwareByteBuf.getBytes(AdvancedLeakAwareByteBuf.java:223)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:687)
io.netty.buffer.CompositeByteBuf.getBytes(CompositeByteBuf.java:40)
io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:677)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1495)
io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:40)
io.netty.buffer.ByteBufInputStream.read(ByteBufInputStream.java:120)
java.io.InputStream.read(InputStream.java:101)
org.jboss.resteasy.util.ReadFromStream.readFromStream(ReadFromStream.java:30)
org.jboss.resteasy.plugins.providers.ByteArrayProvider.readFrom(ByteArrayProvider.java:35)
org.jboss.resteasy.plugins.providers.ByteArrayProvider.readFrom(ByteArrayProvider.java:23)
org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.readFrom(AbstractReaderInterceptorContext.java:61)
org.jboss.resteasy.core.interception.ServerReaderInterceptorContext.readFrom(ServerReaderInterceptorContext.java:60)
org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:53)
org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.aroundReadFrom(GZIPDecodingInterceptor.java:59)
org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:55)
org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:151)
org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:91)
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:114)
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
org.jboss.resteasy.plugins.server.netty.RequestDispatcher.service(RequestDispatcher.java:83)
org.jboss.resteasy.plugins.server.netty.RequestHandler.channelRead0(RequestHandler.java:53)
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)
io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32)
io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:299)
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:380)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
java.lang.Thread.run(Thread.java:745)
#3:
io.netty.buffer.AdvancedLeakAwareByteBuf.release(AdvancedLeakAwareByteBuf.java:45)
io.netty.handler.codec.http.DefaultHttpContent.release(DefaultHttpContent.java:72)
io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:59)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:91)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:182)
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)
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
java.lang.Thread.run(Thread.java:745)
#2:
io.netty.buffer.AdvancedLeakAwareByteBuf.slice(AdvancedLeakAwareByteBuf.java:73)
io.netty.buffer.CompositeByteBuf.addComponent0(CompositeByteBuf.java:173)
io.netty.buffer.CompositeByteBuf.addComponent(CompositeByteBuf.java:112)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:191)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:54)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:182)
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)
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
java.lang.Thread.run(Thread.java:745)
#1:
io.netty.buffer.AdvancedLeakAwareByteBuf.order(AdvancedLeakAwareByteBuf.java:63)
io.netty.buffer.CompositeByteBuf.addComponent0(CompositeByteBuf.java:173)
io.netty.buffer.CompositeByteBuf.addComponent(CompositeByteBuf.java:112)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:191)
io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:54)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:182)
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)
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
java.lang.Thread.run(Thread.java:745)
Created at:
io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:55)
io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:155)
io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:146)
io.netty.buffer.AbstractByteBufAllocator.ioBuffer(AbstractByteBufAllocator.java:107)
io.netty.channel.AdaptiveRecvByteBufAllocator$HandleImpl.allocate(AdaptiveRecvByteBufAllocator.java:104)
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:117)
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)
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-3927) rethinking ISPN transactions
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3927?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-3927:
-----------------------------------
Adding ISPN-5600 as it should be taken into account as well.
> rethinking ISPN transactions
> ----------------------------
>
> Key: ISPN-3927
> URL: https://issues.jboss.org/browse/ISPN-3927
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Mircea Markus
> Assignee: Pedro Ruivo
> Labels: roadmap
>
> Umbrella JIRA for several transaction related improvements:
> 1. Async options for commit/rollback
> - they don't really make sense as a user you don't get any guarantee on the status of the transaction
> - they complicate the code significantly
> - I think they should be removed
> 2. READ_COMMITTED
> - it has the same performance as REPEATABLE_READ, but offers less guarantees.
> - unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator
> - I think it should be removed
> 3. Optimistic tx without Write Skew Check (WSC)
> - well, without WSC the transactions are not optimistic by definition
> - they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee
> - suggestion: optimistic tx should *always* have WSC enabled (no option to configure it)
> - build our batching functionality on top of what currently is optimistic tx without WSC and document it as such
> 4. Remove 1PC option
> - I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing
> [1] http://markmail.org/thread/a7fjko4dyejxqgdy
> [2] https://github.com/infinispan/infinispan/pull/2177
> [3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv
> [4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month