[JBoss JIRA] (ISPN-10301) Deprecate server media type application/x-java-object
by Vittorio Rigamonti (Jira)
[ https://issues.jboss.org/browse/ISPN-10301?page=com.atlassian.jira.plugin... ]
Vittorio Rigamonti updated ISPN-10301:
--------------------------------------
Fix Version/s: 10.0.0.CR2
(was: 10.0.0.CR1)
> Deprecate server media type application/x-java-object
> -----------------------------------------------------
>
> Key: ISPN-10301
> URL: https://issues.jboss.org/browse/ISPN-10301
> Project: Infinispan
> Issue Type: Task
> Components: Server
> Affects Versions: 10.0.0.Beta3
> Reporter: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.CR2
>
>
> `application/x-java-object` needs to have the application classes deployed on the server in order to do anything useful with it, and the server must also be able to do reflection on those application classes.
> We should steer users towards always using `application/x-protostream` instead, because the protobuf schemas are much easier to deploy to the server. The first step would be to make protostream the default marshalling mechanism in the client.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-10254) Modularize Spring Boot Starter Docs
by Vittorio Rigamonti (Jira)
[ https://issues.jboss.org/browse/ISPN-10254?page=com.atlassian.jira.plugin... ]
Vittorio Rigamonti updated ISPN-10254:
--------------------------------------
Fix Version/s: 10.0.0.CR2
(was: 10.0.0.CR1)
> Modularize Spring Boot Starter Docs
> -----------------------------------
>
> Key: ISPN-10254
> URL: https://issues.jboss.org/browse/ISPN-10254
> Project: Infinispan
> Issue Type: Enhancement
> Components: Documentation-Core
> Reporter: Donald Naro
> Assignee: Donald Naro
> Priority: Major
> Fix For: 10.0.0.CR2
>
> Attachments: sb_starter.png
>
>
> In 9.4.x and 7.3.x the doc source for the Spring Boot Starter is different for upstream and downstream.
> * Modularize the Spring Boot Starter doc source upstream.
> * Include the Spring Boot Starter docs on the community site (infinispan.org/documentation).
> * Remove the Spring Boot Starter productization docs from infinispan/documentation/src/main/asciidoc.
> This task removes duplication of content with downstream source. Also brings the user experience for Spring Boot Starter docs into alignment with the strategy for ISPN 10.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-10238) RemoteCacheManager.stop() hangs if a client thread is waiting for a server response
by Vittorio Rigamonti (Jira)
[ https://issues.jboss.org/browse/ISPN-10238?page=com.atlassian.jira.plugin... ]
Vittorio Rigamonti updated ISPN-10238:
--------------------------------------
Fix Version/s: 10.0.0.CR2
(was: 10.0.0.CR1)
> RemoteCacheManager.stop() hangs if a client thread is waiting for a server response
> -----------------------------------------------------------------------------------
>
> Key: ISPN-10238
> URL: https://issues.jboss.org/browse/ISPN-10238
> Project: Infinispan
> Issue Type: Bug
> Components: Server, Test Suite - Server
> Affects Versions: 10.0.0.Beta3, 9.4.14.Final
> Reporter: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.CR2
>
>
> One of our integration tests performs a blocking {{RemoteCache.size()}} operation on the thread where another asynchronous operation was completed (a {{HotRod-client-async-pool}} thread):
> {code:title=EvictionIT}
> CompletableFuture res = rc.putAllAsync(entries);
> res.thenRun(() -> assertEquals(3, rc.size()));
> {code}
> The test then finishes, but doesn't stop the {{RemoteCacheManager}}. When I changed the test to stop the {{RemoteCacheManager}}, the test started hanging:
> {noformat}
> "HotRod-client-async-pool-139-1" #2880 daemon prio=5 os_prio=0 cpu=434.56ms elapsed=1621.24s tid=0x00007f43a6b99800 nid=0x19c0 waiting on condition [0x00007f42ec9fd000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base(a)11.0.3/Native Method)
> - parking to wait for <0x00000000d3321350> (a java.util.concurrent.CompletableFuture$Signaller)
> at java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.3/LockSupport.java:234)
> at java.util.concurrent.CompletableFuture$Signaller.block(java.base@11.0.3/CompletableFuture.java:1798)
> at java.util.concurrent.ForkJoinPool.managedBlock(java.base@11.0.3/ForkJoinPool.java:3128)
> at java.util.concurrent.CompletableFuture.timedGet(java.base@11.0.3/CompletableFuture.java:1868)
> at java.util.concurrent.CompletableFuture.get(java.base@11.0.3/CompletableFuture.java:2021)
> at org.infinispan.client.hotrod.impl.Util.await(Util.java:46)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.size(RemoteCacheImpl.java:307)
> at org.infinispan.server.test.eviction.EvictionIT.lambda$testPutAllAsyncEviction$0(EvictionIT.java:73)
> at org.infinispan.server.test.eviction.EvictionIT$$Lambda$347/0x000000010074a440.run(Unknown Source)
> at java.util.concurrent.CompletableFuture$UniRun.tryFire(java.base@11.0.3/CompletableFuture.java:783)
> at java.util.concurrent.CompletableFuture.postComplete(java.base@11.0.3/CompletableFuture.java:506)
> at java.util.concurrent.CompletableFuture.complete(java.base@11.0.3/CompletableFuture.java:2073)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.complete(HotRodOperation.java:162)
> at org.infinispan.client.hotrod.impl.operations.PutAllOperation.acceptResponse(PutAllOperation.java:83)
> at org.infinispan.client.hotrod.impl.transport.netty.HeaderDecoder.decode(HeaderDecoder.java:144)
> at org.infinispan.client.hotrod.impl.transport.netty.HintedReplayingDecoder.callDecode(HintedReplayingDecoder.java:94)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:278)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1434)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:965)
> at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:799)
> at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:421)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:321)
> at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:897)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.3/ThreadPoolExecutor.java:1128)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.3/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.3/Thread.java:834)
> Locked ownable synchronizers:
> - <0x00000000ca248c30> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "main" #1 prio=5 os_prio=0 cpu=37300.10ms elapsed=2911.99s tid=0x00007f43a4023000 nid=0x37f7 in Object.wait() [0x00007f43a9c21000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(java.base(a)11.0.3/Native Method)
> - waiting on <no object reference available>
> at java.lang.Object.wait(java.base@11.0.3/Object.java:328)
> at io.netty.util.concurrent.DefaultPromise.await(DefaultPromise.java:231)
> - waiting to re-lock in wait() <0x00000000ca174af8> (a io.netty.util.concurrent.DefaultPromise)
> at io.netty.util.concurrent.DefaultPromise.await(DefaultPromise.java:33)
> at io.netty.util.concurrent.AbstractFuture.get(AbstractFuture.java:32)
> at org.infinispan.client.hotrod.impl.transport.netty.ChannelFactory.destroy(ChannelFactory.java:216)
> at org.infinispan.client.hotrod.RemoteCacheManager.stop(RemoteCacheManager.java:365)
> at org.infinispan.client.hotrod.RemoteCacheManager.close(RemoteCacheManager.java:513)
> at org.infinispan.commons.junit.ClassResource.lambda$new$0(ClassResource.java:24)
> at org.infinispan.commons.junit.ClassResource$$Lambda$286/0x0000000100573040.accept(Unknown Source)
> at org.infinispan.commons.junit.ClassResource.after(ClassResource.java:41)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:50)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:167)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
> Locked ownable synchronizers:
> - None
> {noformat}
> {{HotRod-client-async-pool}} threads are not appropriate for doing blocking cache operations at any time, but we need to do more than just change the test:
> * We need an asynchronous {{RemoteCache.size()}} alternative
> * Currently blocking operations like {{size()}} wait for a response from the server for 1 day, they should wait for a much smaller (and configurable) timeout.
> * {{RemoteCacheManager.stop()}} should have a timeout as well, but more importantly it should cancel any pending operation.
> * We should consider running all application code on a separate thread pool.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-10236) Hotrod client error releasing channel after server cache stop
by Vittorio Rigamonti (Jira)
[ https://issues.jboss.org/browse/ISPN-10236?page=com.atlassian.jira.plugin... ]
Vittorio Rigamonti updated ISPN-10236:
--------------------------------------
Fix Version/s: 10.0.0.CR2
(was: 10.0.0.CR1)
> Hotrod client error releasing channel after server cache stop
> -------------------------------------------------------------
>
> Key: ISPN-10236
> URL: https://issues.jboss.org/browse/ISPN-10236
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 10.0.0.Beta3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.CR2
>
> Attachments: ISPN-10137_package_private_scope_20190524-1732_ServerFailureRetryTest-infinispan-client-hotrod.log.gz
>
>
> Random failure in {{ServerFailureRetryTest.testRetryCacheStopped}} caused by an assert statement in {{ChannelPool.release()}}.
> {noformat}
> 17:37:36,562 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.client.hotrod.retry.ServerFailureRetryTest.testRetryCacheStopped
> java.lang.AssertionError: Error releasing [id: 0x5d9755e6, L:/127.0.0.1:42472 ! R:127.0.0.1/127.0.0.1:44865]
> at org.infinispan.client.hotrod.impl.transport.netty.ChannelPool.release(ChannelPool.java:170) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.transport.netty.ChannelFactory.releaseChannel(ChannelFactory.java:309) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.releaseChannel(HotRodOperation.java:105) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.invoke(RetryOnFailureOperation.java:80) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.transport.netty.ChannelPool.activateChannel(ChannelPool.java:217) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.transport.netty.ChannelPool.acquire(ChannelPool.java:86) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.transport.netty.ChannelFactory.fetchChannelAndInvoke(ChannelFactory.java:259) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.transport.netty.ChannelFactory.fetchChannelAndInvoke(ChannelFactory.java:297) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.fetchChannelAndInvoke(AbstractKeyOperation.java:41) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:61) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.putAsync(RemoteCacheImpl.java:366) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:334) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) ~[classes/:?]
> at org.infinispan.client.hotrod.retry.ServerFailureRetryTest.testRetryCacheStopped(ServerFailureRetryTest.java:63) ~[test-classes/:?]
> {noformat}
> I investigated a bit and I couldn't find an obvious mistake in the way {{ChannelPool.created}} is incremented and decremented, but I think it would help if access to it and {{ChannelPool.active}} were centralized in a smaller number of methods.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-10481) Add additional type support for Protostream user Marshaller
by Vittorio Rigamonti (Jira)
[ https://issues.jboss.org/browse/ISPN-10481?page=com.atlassian.jira.plugin... ]
Vittorio Rigamonti updated ISPN-10481:
--------------------------------------
Fix Version/s: 10.0.0.CR2
(was: 10.0.0.CR1)
> Add additional type support for Protostream user Marshaller
> -----------------------------------------------------------
>
> Key: ISPN-10481
> URL: https://issues.jboss.org/browse/ISPN-10481
> Project: Infinispan
> Issue Type: Sub-task
> Components: Loaders and Stores
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.0.0.CR2
>
>
> The PersistenceMarshallerImpl uses protostream to do marshalling and if not falls back to a user marshaller. The protostream context supports many more JDK built in types that we aren't currently testing for. This would allow a user to not have to supply these themselves.
> An example of known types can be found in the BaseProtoStreamMarshaller class.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-10472) ArrayIndexOutOfBoundsException in BoundedOffHeapDataContainer.removeSegments
by Vittorio Rigamonti (Jira)
[ https://issues.jboss.org/browse/ISPN-10472?page=com.atlassian.jira.plugin... ]
Vittorio Rigamonti updated ISPN-10472:
--------------------------------------
Fix Version/s: 10.0.0.CR2
(was: 10.0.0.CR1)
> ArrayIndexOutOfBoundsException in BoundedOffHeapDataContainer.removeSegments
> ----------------------------------------------------------------------------
>
> Key: ISPN-10472
> URL: https://issues.jboss.org/browse/ISPN-10472
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 10.0.0.Beta5, 9.4.16.Final
> Reporter: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.CR2, 9.4.17.Final
>
>
> When the {{data-segmentation}} feature is disabled, the data container is not segmented, but {{BoundedOffHeapDataContainer.removeSegments}} still uses {{DefaultSegmentedDataContainer.getMapForSegment}} internally, and gets an {{ArrayIndexOutOfBoundsException}}:
> {noformat}
> 09:51:06,887 ERROR [org.infinispan.topology.LocalTopologyManagerImpl] (transport-thread--p4-t3) ISPN000452: Failed to update topology for cache books: java.lang.ArrayIndexOutOfBoundsException: Index 54 out of bounds for length 1
> at java.base/java.lang.invoke.VarHandle$1.apply(VarHandle.java:2011)
> at java.base/java.lang.invoke.VarHandle$1.apply(VarHandle.java:2008)
> at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:159)
> at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:156)
> at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:62)
> at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
> at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
> at java.base/java.lang.invoke.VarHandleObjects$Array.getVolatile(VarHandleObjects.java:438)
> at java.base/java.lang.invoke.VarHandleGuards.guard_LI_L(VarHandleGuards.java:646)
> at java.base/java.util.concurrent.atomic.AtomicReferenceArray.get(AtomicReferenceArray.java:100)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.container.impl.DefaultSegmentedDataContainer.getMapForSegment(DefaultSegmentedDataContainer.java:83)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.container.impl.AbstractInternalDataContainer.remove(AbstractInternalDataContainer.java:183)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.container.impl.AbstractInternalDataContainer.remove(AbstractInternalDataContainer.java:206)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.container.impl.InternalDataContainerAdapter.removeSegmentEntries(InternalDataContainerAdapter.java:144)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.container.offheap.BoundedOffHeapDataContainer.removeSegments(BoundedOffHeapDataContainer.java:160)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.statetransfer.StateConsumerImpl.removeStaleData(StateConsumerImpl.java:972)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:442)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:200)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:57)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:113)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.topology.LocalTopologyManagerImpl.doHandleTopologyUpdate(LocalTopologyManagerImpl.java:357)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.topology.LocalTopologyManagerImpl.lambda$handleTopologyUpdate$1(LocalTopologyManagerImpl.java:279)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:175)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:37)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:227)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> The exception doesn't prevent the state transfer from finishing, but if the segments become owned by the local node again in the future, the cache may return the outdated values that were not removed because of the exception.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months