[JBoss JIRA] (ISPN-5930) OOM error when registering continuous query
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5930?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5930:
-----------------------------------------------
Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1279379|https://bugzilla.redhat.com/show_bug.cgi?id=1279379] from POST to MODIFIED
> OOM error when registering continuous query
> -------------------------------------------
>
> Key: ISPN-5930
> URL: https://issues.jboss.org/browse/ISPN-5930
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.1.0.CR1, 8.0.2.Final
> Reporter: Vojtech Juranek
> Assignee: Adrian Nistor
> Fix For: 8.2.0.Alpha1, 8.2.0.Final
>
>
> When running CQ perf tests in client-server mode, I hit following exception in HR server.
> The scenario was to store random texts in the cache and CQ which matches all the entries (i.e. query was "%").
> Full logs from server are [here|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/PERF-...]. Machines perf01-04 are servers, perf05-07 clients and perf08 is RG master.
> {noformat}
> [0m[31m12:36:37,557 ERROR [org.infinispan.server.hotrod.HotRodEncoder] (HotRodServerWorker-9-33) ISPN005023: Exception encoding message CustomRawEvent{version=23, messageId=39574, op=CacheEntryCreatedEventResponse, listenerId=([B@9641785,false), event=([B@5ecfed02,false), isRetried=false}: java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:658)
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at io.netty.buffer.UnpooledUnsafeDirectByteBuf.allocateDirect(UnpooledUnsafeDirectByteBuf.java:108)
> at io.netty.buffer.UnpooledUnsafeDirectByteBuf.capacity(UnpooledUnsafeDirectByteBuf.java:157)
> at io.netty.buffer.AbstractByteBuf.ensureWritable(AbstractByteBuf.java:251)
> at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:817)
> at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:825)
> at org.infinispan.server.core.transport.ExtendedByteBuf$.writeRangedBytes(ExtendedByteBuf.scala:67)
> at org.infinispan.server.hotrod.Encoder2x$.writeEvent(Encoder2x.scala:47)
> at org.infinispan.server.hotrod.HotRodEncoder.encode(HotRodEncoder.scala:57)
> at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107)
> at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:633)
> at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:691)
> at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:681)
> at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:716)
> at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:954)
> at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:243)
> at org.infinispan.server.hotrod.ClientListenerRegistry$BaseClientEventSender.sendEvent(ClientListenerRegistry.scala:219)
> at org.infinispan.server.hotrod.ClientListenerRegistry$BaseClientEventSender.onCacheEvent(ClientListenerRegistry.scala:186)
> at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:21)
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1213)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl.raiseEventForInitialTransfer(CacheNotifierImpl.java:911)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl.addListener(CacheNotifierImpl.java:852)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl.addListener(CacheNotifierImpl.java:923)
> at org.infinispan.cache.impl.CacheImpl.addListener(CacheImpl.java:722)
> at org.infinispan.cache.impl.AbstractDelegatingCache.addListener(AbstractDelegatingCache.java:347)
> at org.infinispan.server.hotrod.ClientListenerRegistry.addClientListener(ClientListenerRegistry.scala:100)
> at org.infinispan.server.hotrod.Decoder2x$.customReadKey(Decoder2x.scala:384)
> at org.infinispan.server.hotrod.HotRodDecoder.customDecodeKey(HotRodDecoder.scala:194)
> at org.infinispan.server.hotrod.HotRodDecoder.org$infinispan$server$hotrod$HotRodDecoder$$decodeKey(HotRodDecoder.scala:104)
> at org.infinispan.server.hotrod.HotRodDecoder$$anonfun$decode$1.apply$mcV$sp(HotRodDecoder.scala:48)
> at org.infinispan.server.hotrod.HotRodDecoder.wrapSecurity(HotRodDecoder.scala:206)
> at org.infinispan.server.hotrod.HotRodDecoder.decode(HotRodDecoder.scala:45)
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:370)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:168)
> at org.infinispan.server.hotrod.HotRodDecoder.org$infinispan$server$core$transport$StatsChannelHandler$$super$channelRead(HotRodDecoder.scala:31)
> at org.infinispan.server.core.transport.StatsChannelHandler$class.channelRead(StatsChannelHandler.scala:32)
> at org.infinispan.server.hotrod.HotRodDecoder.channelRead(HotRodDecoder.scala:31)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846)
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:130)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-6047) Deadlock when a prepare command is retried
by Dan Berindei (JIRA)
Dan Berindei created ISPN-6047:
----------------------------------
Summary: Deadlock when a prepare command is retried
Key: ISPN-6047
URL: https://issues.jboss.org/browse/ISPN-6047
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.1.0.Final
Reporter: Dan Berindei
Assignee: Pedro Ruivo
Fix For: 8.2.0.Alpha1
Looks like the ISPN-5623 fix went too far, and now I found a test failure with the opposite behaviour:
1. Remote prepare for {{txA}} acquires lock {{K}}
2. Remote prepare for {{txB}} blocks waiting for lock {{K}}
3. The topology changes, and the {{txA}} prepare is retried
4. The {{txA}} prepare times out, because it waits for pending transaction {{txB}} to finish.
So we have to make {{txA}} somehow know that it already has the lock after it received an {{UnsureResponse}} for the prepare command, and skip waiting for pending transactions.
I found the problem in a random failure of {{DistributedFourNodesMapReduceTest}} on a local branch, but I'm not sure if my local changes (making SyncCHF the default CH factory) made it more likely.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-6047) Deadlock when a prepare command is retried
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6047?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6047:
-------------------------------
Status: Open (was: New)
> Deadlock when a prepare command is retried
> ------------------------------------------
>
> Key: ISPN-6047
> URL: https://issues.jboss.org/browse/ISPN-6047
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Fix For: 8.2.0.Alpha1
>
>
> Looks like the ISPN-5623 fix went too far, and now I found a test failure with the opposite behaviour:
> 1. Remote prepare for {{txA}} acquires lock {{K}}
> 2. Remote prepare for {{txB}} blocks waiting for lock {{K}}
> 3. The topology changes, and the {{txA}} prepare is retried
> 4. The {{txA}} prepare times out, because it waits for pending transaction {{txB}} to finish.
> So we have to make {{txA}} somehow know that it already has the lock after it received an {{UnsureResponse}} for the prepare command, and skip waiting for pending transactions.
> I found the problem in a random failure of {{DistributedFourNodesMapReduceTest}} on a local branch, but I'm not sure if my local changes (making SyncCHF the default CH factory) made it more likely.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-5941) Ensure testability of management console
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5941?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5941:
----------------------------------
Status: Open (was: New)
> Ensure testability of management console
> ----------------------------------------
>
> Key: ISPN-5941
> URL: https://issues.jboss.org/browse/ISPN-5941
> Project: Infinispan
> Issue Type: Task
> Components: Console
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
> Fix For: 8.2.0.Alpha1, 8.2.0.Final
>
>
> Since we're planning to test ISPN management console using Selenium (Selenide more specifically), we would appreciate taking more attention to giving ID's to page elements that would be helpful for testing.
> Just an example, how it could simplify our test development as a motivation. Currently (ISPN 8.1.0.Alpha2), in the detail of cache container page with list of caches, the shortest way (even with Java 8) how to get (for testing purposes) names of caches, is:
> {code}
> List<String> caches = $$("#cache-cards > div").filterBy(attribute("ng-show", "cache.show"))
> .stream().map(element -> element.find("a").text()).collect(Collectors.toList());
> {code}
> The time to figure out this "query" was about 2 minutes (For the first time. I know, very subjective, but as an example)
> Now suppose we would add class="cacheName" to <a> element of the corresponding cache card:
> {code}
> List<String> caches = $$("#cache-cards a.cacheName").stream().map(element -> element.text()).collect(Collectors.toList());
> {code}
> Time to come up with such an "query" would be around 5 seconds :)
> I tried to come up with some generic guidelines about where to put some id/class, feel free to add some:
> * to every input/select field
> * especially with checkboxes which are differentiated with <label>
> * generally to <span> or any (text?) element which can change it's value, which is dependent on some state of the cache/server/...
> Of course, you cannot be 100% successful with giving the id/class to every useful place, but every single place, which you select correctly, simplifies and speeds up the test development. Probably also a good idea to come up with some naming convention.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-5941) Ensure testability of management console
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5941?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5941:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan-management-console/pull/35
> Ensure testability of management console
> ----------------------------------------
>
> Key: ISPN-5941
> URL: https://issues.jboss.org/browse/ISPN-5941
> Project: Infinispan
> Issue Type: Task
> Components: Console
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
> Fix For: 8.2.0.Alpha1, 8.2.0.Final
>
>
> Since we're planning to test ISPN management console using Selenium (Selenide more specifically), we would appreciate taking more attention to giving ID's to page elements that would be helpful for testing.
> Just an example, how it could simplify our test development as a motivation. Currently (ISPN 8.1.0.Alpha2), in the detail of cache container page with list of caches, the shortest way (even with Java 8) how to get (for testing purposes) names of caches, is:
> {code}
> List<String> caches = $$("#cache-cards > div").filterBy(attribute("ng-show", "cache.show"))
> .stream().map(element -> element.find("a").text()).collect(Collectors.toList());
> {code}
> The time to figure out this "query" was about 2 minutes (For the first time. I know, very subjective, but as an example)
> Now suppose we would add class="cacheName" to <a> element of the corresponding cache card:
> {code}
> List<String> caches = $$("#cache-cards a.cacheName").stream().map(element -> element.text()).collect(Collectors.toList());
> {code}
> Time to come up with such an "query" would be around 5 seconds :)
> I tried to come up with some generic guidelines about where to put some id/class, feel free to add some:
> * to every input/select field
> * especially with checkboxes which are differentiated with <label>
> * generally to <span> or any (text?) element which can change it's value, which is dependent on some state of the cache/server/...
> Of course, you cannot be 100% successful with giving the id/class to every useful place, but every single place, which you select correctly, simplifies and speeds up the test development. Probably also a good idea to come up with some naming convention.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-5941) Ensure testability of management console
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5941?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5941:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 8.2.0.Alpha1
8.2.0.Final
Resolution: Done
> Ensure testability of management console
> ----------------------------------------
>
> Key: ISPN-5941
> URL: https://issues.jboss.org/browse/ISPN-5941
> Project: Infinispan
> Issue Type: Task
> Components: Console
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
> Fix For: 8.2.0.Alpha1, 8.2.0.Final
>
>
> Since we're planning to test ISPN management console using Selenium (Selenide more specifically), we would appreciate taking more attention to giving ID's to page elements that would be helpful for testing.
> Just an example, how it could simplify our test development as a motivation. Currently (ISPN 8.1.0.Alpha2), in the detail of cache container page with list of caches, the shortest way (even with Java 8) how to get (for testing purposes) names of caches, is:
> {code}
> List<String> caches = $$("#cache-cards > div").filterBy(attribute("ng-show", "cache.show"))
> .stream().map(element -> element.find("a").text()).collect(Collectors.toList());
> {code}
> The time to figure out this "query" was about 2 minutes (For the first time. I know, very subjective, but as an example)
> Now suppose we would add class="cacheName" to <a> element of the corresponding cache card:
> {code}
> List<String> caches = $$("#cache-cards a.cacheName").stream().map(element -> element.text()).collect(Collectors.toList());
> {code}
> Time to come up with such an "query" would be around 5 seconds :)
> I tried to come up with some generic guidelines about where to put some id/class, feel free to add some:
> * to every input/select field
> * especially with checkboxes which are differentiated with <label>
> * generally to <span> or any (text?) element which can change it's value, which is dependent on some state of the cache/server/...
> Of course, you cannot be 100% successful with giving the id/class to every useful place, but every single place, which you select correctly, simplifies and speeds up the test development. Probably also a good idea to come up with some naming convention.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months