[JBoss JIRA] (ISPN-3927) rethinking ISPN transactions
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3927?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3927:
------------------------------
Description:
Umbrella JIRA for several transaction related improvements:
-1. Async options for commit/rollback- (DONE)
- 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
5. Configuration changes
- remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
- remove {{eager-locking-single-node}}. deprecated since 5.1
- remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
- remove {{eager-locking}}. deprecated since 5.1
- move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
- remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
[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
was:
Umbrella JIRA for several transaction related improvements:
-1. Async options for commit/rollback- (DONE)
- 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
> 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- (DONE)
> - 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
> 5. Configuration changes
> - remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent
> - remove {{eager-locking-single-node}}. deprecated since 5.1
> - remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
> - remove {{eager-locking}}. deprecated since 5.1
> - move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches.
> - remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.
> [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
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7620) Add metadata to Cache Stores
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-7620:
----------------------------------
Summary: Add metadata to Cache Stores
Key: ISPN-7620
URL: https://issues.jboss.org/browse/ISPN-7620
Project: Infinispan
Issue Type: Enhancement
Components: Loaders and Stores
Affects Versions: 9.0.0.Final
Reporter: Ryan Emerson
Assignee: Ryan Emerson
We should add metadata to store implementations to allow existing stores to be validated at startup.
This metadata should at least contain the Infinispan version used to write to the store, so that we can present the user with better errors if incompatibilities exist between different versions.
We could also write include information about which marshaller was used to read/write the data originally.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7572) Infinispan initialization via DirectoryProvider can't use any CacheStore or other extensions
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7572?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-7572:
------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4974
> Infinispan initialization via DirectoryProvider can't use any CacheStore or other extensions
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-7572
> URL: https://issues.jboss.org/browse/ISPN-7572
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores, Lucene Directory, WildFly modules
> Affects Versions: 9.0.0.CR2, 8.2.6.Final
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Priority: Critical
> Fix For: 9.0.0.Final, 8.2.7.Final
>
>
> When the Infinispan CacheManager is bootstrapped via Hibernate Search, the Infinispan modules are not necessarily visible to the deployment classpath (the TCCL).
> In this case if the configuration file refers to any extension such as a {{CacheStore}}, Infinispan will fail to start as it doesn't depend on the modules of its extensions.
> This will cause puzzling errors such as :
> {{ISPN000327: Cannot find a parser for element 'string-keyed-jdbc-store' in namespace 'urn:infinispan:config:store:jdbc:8.0'. Check that your configuration is up-to date for this version of Infinispan.}}
> For the record, the fact that the configuration parser expects to use the TCCL is an old problem which I've highlighted already in the past:
> Explicit classloader support during parsing was introduced in 2013:
> - http://lists.jboss.org/pipermail/infinispan-dev/2013-April/012590.html
> Then removed again in 2014:
> - http://lists.jboss.org/pipermail/infinispan-dev/2014-May/014952.html
> I asked for improvements and hoped for someone to take ownership:
> - http://lists.jboss.org/pipermail/infinispan-dev/2014-October/015549.html
> In this last email I explained what Hibernate Search would do, in lack of better alternatives..and so we did.
> Finally, this component of Hibernate Search code was transferred to the Infinispan repository so luckily we can change both components as you see most fit; the only requirement is to not expect the Hibernate users to have Infinispan on their TCCL.
> My proposal is simple: the Infinispan-core module should have an optional dependency to its extensions, including at least all supported CacheStore implementations so that people can use them.
> In fact, I expected them to do as it feels natural to have a graph edge towards extension points to be able to load them.
> But [~NadirX] doesn't like that, so assigning the issue to him ;-)
> Alternative ideas:
> * allow people to mention module names explicitly in the Infinispan configuration?
> * have a module which bootstraps the CacheManager, depending explicitly on all extensions, and register it over JNDI
> I favour the second option, especially as it came up before as a dire pratical need for many other situations.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7579) SimpleDateFormat is not thread safe
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-7579?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-7579:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1431965
Bugzilla Update: Perform
> 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
> Fix For: 9.0.0.Final
>
>
> {{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)
9 years
[JBoss JIRA] (ISPN-7617) Rest store - synchronize data opeartion hangs
by Vojtech Juranek (JIRA)
Vojtech Juranek created ISPN-7617:
-------------------------------------
Summary: Rest store - synchronize data opeartion hangs
Key: ISPN-7617
URL: https://issues.jboss.org/browse/ISPN-7617
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 9.0.0.CR2
Reporter: Vojtech Juranek
When using REST store for rolling upgrade, it hangs during {{synchronizeData}} operation (executed via JMX, didn't try CLI). Before it hangs, following warning is in the log:
{noformat}
ESC[0mESC[33m18:48:44,011 WARNING [io.netty.channel.DefaultChannelPipeline] (nioEventLoopGroup-9-3) An exception was thrown by a user handler's exceptionCaught() method while handling the following exception:: java.lang.IllegalStateException: Already committed
at org.jboss.resteasy.plugins.server.netty.NettyHttpResponse.reset(NettyHttpResponse.java:148)
at org.jboss.resteasy.plugins.server.netty.RequestHandler.channelRead0(RequestHandler.java:62)
at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)
at io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32)
at io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:299)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:380)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
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
(v7.2.3#72005)
9 years