[JBoss JIRA] (ISPN-7579) SimpleDateFormat is not thread safe
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7579?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant moved JDG-844 to ISPN-7579:
-------------------------------------------
Project: Infinispan (was: JBoss Data Grid)
Key: ISPN-7579 (was: JDG-844)
Workflow: GIT Pull Request with Triage workflow (was: CDW with loose statuses v1)
Component/s: Remote Protocols
(was: Hot Rod, REST and Memcached)
Fix Build: (was: ER7)
Affects Version/s: 9.0.0.CR2
(was: JDG 7.0.0 GA)
> SimpleDateFormat is not thread safe
> -----------------------------------
>
> Key: ISPN-7579
> URL: https://issues.jboss.org/browse/ISPN-7579
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 9.0.0.CR2
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
>
> {{org.infinispan.rest.Server}} has a static field of {{DatePatternRfc1123LocaleUS}}, wihich is an instance of {{SimpleDateFormat}}, and is causing the following error during a load test.
> {code}
> 2017-03-03 15:57:55,939 ERROR [org.jboss.resteasy.plugins.server.netty.i18n] (nioEventLoopGroup-6-8) RESTEASY018525: Unexpected: org.jboss.resteasy.spi.UnhandledException: java.lang.ArrayIndexOutOfBoundsException: -2147483648
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76)
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
> at org.jboss.resteasy.plugins.server.netty.RequestDispatcher.service(RequestDispatcher.java:83)
> at org.jboss.resteasy.plugins.server.netty.RequestHandler.channelRead0(RequestHandler.java:54)
> at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> at io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32)
> at io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:283)
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:374)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: -2147483648
> at java.util.Calendar.getDisplayName(Calendar.java:2114)
> at java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1125)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:966)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.DateFormat.format(DateFormat.java:345)
> at org.infinispan.rest.Server.org$infinispan$rest$Server$$formatDate(Server.scala:222)
> at org.infinispan.rest.Server.org$infinispan$rest$Server$$getMimeEntry(Server.scala:140)
> at org.infinispan.rest.Server$$anonfun$getEntry$1$$anonfun$apply$10.apply(Server.scala:98)
> at org.infinispan.rest.Server$$anonfun$getEntry$1$$anonfun$apply$10.apply(Server.scala:96)
> at org.infinispan.rest.Server.org$infinispan$rest$Server$$ensureFreshEnoughEntry(Server.scala:111)
> at org.infinispan.rest.Server$$anonfun$getEntry$1.apply(Server.scala:95)
> at org.infinispan.rest.Server$$anonfun$getEntry$1.apply(Server.scala:89)
> at org.infinispan.rest.Server.protectCacheNotFound(Server.scala:498)
> at org.infinispan.rest.Server.getEntry(Server.scala:89)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
> ... 12 more
> {code}
> A similar issue is found here:
> https://github.com/rhuss/jolokia/issues/184
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7400) Cache segment ownership information in DistributionManager
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7400?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7400:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.CR3
(was: 9.0.0.Final)
Resolution: Done
> Cache segment ownership information in DistributionManager
> ----------------------------------------------------------
>
> Key: ISPN-7400
> URL: https://issues.jboss.org/browse/ISPN-7400
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: performance
> Fix For: 9.0.0.CR3
>
>
> ISPN-7029 introduced {{DistributionInfo}} to simplify limit the number of times we compute the location of a given key. We can go further and cache the {{DistributionInfo}} of each segment in {{DistributionManager}}, so that each operation only needs to compute the segment of its key.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7046) IndexOutOfBoundsException following cache topology change
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-7046?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated ISPN-7046:
-------------------------------
Affects Version/s: 9.0.0.CR2
> IndexOutOfBoundsException following cache topology change
> ---------------------------------------------------------
>
> Key: ISPN-7046
> URL: https://issues.jboss.org/browse/ISPN-7046
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.CR2, 8.2.4.Final
> Reporter: Paul Ferraro
>
> Seen only once so far in failover tests - HA Singleton deployment scenarios. Is probably closely related to JBEAP-2254 as it occured during the events described there, namely:
> - redeploy will fail
> - This node will no longer operate as the singleton provider
> - *IndexOutOfBoundsException* appears, see the stacktrace below
> - the node is re-elected as the singleton provider and the deployment starts successfully
> Stacktrace:
> {code}
> [JBossINF] [0m[31m05:51:00,920 ERROR [org.jgroups.protocols.pbcast.GMS] (Incoming-14,ee,perf19) JGRP000027: failed passing message up: java.lang.RuntimeException: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.IndexOutOfBoundsException] while invoking method [public void org.infinispan.container.versioning.NumericVersionGenerator$RankCalculator.calculateRank(org.infinispan.notifications.cachemanagerlistener.event.ViewChangedEvent)] on listener instance: org.infinispan.container.versioning.NumericVersionGenerator$RankCalculator@3118031c
> [JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:689)
> [JBossINF] at org.jgroups.JChannel.up(JChannel.java:738)
> [JBossINF] at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:123)
> [JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:374)
> [JBossINF] at org.jgroups.protocols.FORK.up(FORK.java:118)
> [JBossINF] at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:394)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:394)
> [JBossINF] at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:735)
> [JBossINF] at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:244)
> [JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:925)
> [JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:412)
> [JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> [JBossINF] at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:982)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618)
> [JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> [JBossINF] at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> [JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> [JBossINF] at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> [JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:295)
> [JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
> [JBossINF] at org.jgroups.protocols.TP$3.run(TP.java:1511)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] Caused by: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.IndexOutOfBoundsException] while invoking method [public void org.infinispan.container.versioning.NumericVersionGenerator$RankCalculator.calculateRank(org.infinispan.notifications.cachemanagerlistener.event.ViewChangedEvent)] on listener instance: org.infinispan.container.versioning.NumericVersionGenerator$RankCalculator@3118031c
> [JBossINF] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:291)
> [JBossINF] at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:21)
> [JBossINF] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> [JBossINF] at org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifierImpl.notifyViewChange(CacheManagerNotifierImpl.java:88)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport$NotifyViewChange.emitNotification(JGroupsTransport.java:774)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.viewAccepted(JGroupsTransport.java:850)
> [JBossINF] at org.jgroups.blocks.MessageDispatcher.handleUpEvent(MessageDispatcher.java:605)
> [JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:686)
> [JBossINF] ... 27 more
> [JBossINF] Caused by: java.lang.IndexOutOfBoundsException: Index: 0
> [JBossINF] at org.infinispan.commons.util.InfinispanCollections$EmptyList.get(InfinispanCollections.java:115)
> [JBossINF] at org.infinispan.container.versioning.NumericVersionGenerator.findAddressRank(NumericVersionGenerator.java:115)
> [JBossINF] at org.infinispan.container.versioning.NumericVersionGenerator.calculateRank(NumericVersionGenerator.java:101)
> [JBossINF] at org.infinispan.container.versioning.NumericVersionGenerator$RankCalculator.calculateRank(NumericVersionGenerator.java:126)
> [JBossINF] at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> [JBossINF] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [JBossINF] at java.lang.reflect.Method.invoke(Method.java:497)
> [JBossINF] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> [JBossINF] ... 34 more
> {code}
> Link:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-singl...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-6029) DDL for JDBC store tables should never allow null
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-6029?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated ISPN-6029:
-------------------------------
Affects Version/s: 9.0.0.CR2
8.2.0.Final
> DDL for JDBC store tables should never allow null
> -------------------------------------------------
>
> Key: ISPN-6029
> URL: https://issues.jboss.org/browse/ISPN-6029
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 8.1.0.Final, 8.2.0.Final, 8.0.2.Final, 9.0.0.CR2
> Reporter: Paul Ferraro
>
> The DDL for jdbc persistent stores creates a 3 column table, where only the primary key is not null. However, both the string-based and binary-based cache stores require non-null values for the data column and timestamp column. These columns should not allow null values.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-6029) DDL for JDBC store tables should never allow null
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-6029?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned ISPN-6029:
----------------------------------
Assignee: Paul Ferraro
> DDL for JDBC store tables should never allow null
> -------------------------------------------------
>
> Key: ISPN-6029
> URL: https://issues.jboss.org/browse/ISPN-6029
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 8.1.0.Final, 8.2.0.Final, 8.0.2.Final, 9.0.0.CR2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> The DDL for jdbc persistent stores creates a 3 column table, where only the primary key is not null. However, both the string-based and binary-based cache stores require non-null values for the data column and timestamp column. These columns should not allow null values.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7045) Fix interrupt handling during CacheStore.purge(...)
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-7045?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned ISPN-7045:
----------------------------------
Assignee: Paul Ferraro
> Fix interrupt handling during CacheStore.purge(...)
> ---------------------------------------------------
>
> Key: ISPN-7045
> URL: https://issues.jboss.org/browse/ISPN-7045
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 8.2.4.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> During cache shutdown, any persistence threads are interrupted. Some cache stores, e.g. JdbcBinaryStore, inappropriately rethrow InterruptedExceptions as PersistenceExceptions, which then get logged as ERROR by the ExpirationManager.
> Other cache stores, e.g. SingleFileStore, don't handle/react to interrupts at all!
> I haven't looked at every cache store implementation, but the problem seems widespread.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7505) Non-functional read in transaction with modifications returns old value
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7505?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-7505:
------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/4906, https://github.com/infinispan/infinispan/pull/4947 (was: https://github.com/infinispan/infinispan/pull/4906)
> Non-functional read in transaction with modifications returns old value
> -----------------------------------------------------------------------
>
> Key: ISPN-7505
> URL: https://issues.jboss.org/browse/ISPN-7505
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Fix For: 9.0.0.CR3
>
>
> See this modified FunctionalTxInMemoryTest:
> {code:java}
> @Test(dataProvider = "owningModeAndReadWrites")
> public void testReadWriteAfterMods(boolean isOwner, WriteMethod method) throws Exception {
> Object KEY = getKey(isOwner);
> cache(0, DIST).put(KEY, "a");
> tm.begin();
> assertEquals("a", rw.eval(KEY, append("b")).join());
> assertEquals("ab", rw.evalMany(Collections.singleton(KEY), append("c")).findAny().get());
> assertEquals("abc", cache(0, DIST).get(KEY)); // <-- THIS FAILS
> assertEquals(null, rw.eval("otherKey", append("d")).join());
> assertEquals("abc", method.action.eval(KEY, wo, rw,
> MarshallableFunctions.returnReadOnlyFindOrNull(),
> (BiConsumer<EntryView.WriteEntryView<String>, String> & Serializable) (e, prev) -> {}, getClass()));
> tm.commit();
> }
> {code}
> When the entry was modified in given transaction, we have to do the read using functional identity read which passes all modifications along. We need to do this for all {{remoteGet}} s, including those invoked for {{putIfAbsent}} etc.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months