June 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3219) CommitCommands should ignore SuspectExceptions

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3219?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3219: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1895 > CommitCommands should ignore SuspectExceptions > ---------------------------------------------- > > Key: ISPN-3219 > URL: https://issues.jboss.org/browse/ISPN-3219 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.2.6.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 5.3.0.CR2 > > > We can ignore any nodes leaving the cache during the invocation of a CommitCommand - the NBST command forwarding mechanism takes care of sending the CommitCommand to the right targets. > The same with 1PC PrepareCommands, they are only used for asynchronous caches and for pessimistic synchronous caches. If the cache is asynchronous we won't receive SuspectExceptions anyway, and if the cache is pessimistic the locks will have already been acquired on the primary owners before the PrepareCommand was sent. > There is already a more generic issue for dealing with SuspectExceptions everywhere: ISPN-2402. But exceptions during TransactionCoordinator.commit() are much more critical than prepare exceptions, because the TM can't roll back the transaction at that point (especially if Infinispan is registered as a synchronization). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3221) Put back DONT_BUNDLE for sync requests due to some regressions in performance

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3221?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3221: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1896 > Put back DONT_BUNDLE for sync requests due to some regressions in performance > ----------------------------------------------------------------------------- > > Key: ISPN-3221 > URL: https://issues.jboss.org/browse/ISPN-3221 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 5.3.0.CR2 > > > from mailling list: The performance drops from about 7800 writes/s to 4800 writes/s, and from 1.5M reads/s to 1.2M reads/s (having slower reads in replicated mode is really odd). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3221) Put back DONT_BUNDLE for sync requests due to some regressions in performance

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3221: --------------------------------- Summary: Put back DONT_BUNDLE for sync requests due to some regressions in performance Key: ISPN-3221 URL: https://issues.jboss.org/browse/ISPN-3221 Project: Infinispan Issue Type: Bug Affects Versions: 5.3.0.CR1 Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 5.3.0.CR2 from mailling list: The performance drops from about 7800 writes/s to 4800 writes/s, and from 1.5M reads/s to 1.2M reads/s (having slower reads in replicated mode is really odd). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3220) Integration tests rely on a nonexistent artifact

by Manik Surtani (JIRA)

Manik Surtani created ISPN-3220: ----------------------------------- Summary: Integration tests rely on a nonexistent artifact Key: ISPN-3220 URL: https://issues.jboss.org/browse/ISPN-3220 Project: Infinispan Issue Type: Bug Components: Server Affects Versions: 5.3.0.CR1 Reporter: Manik Surtani Assignee: Tristan Tarrant Priority: Critical Fix For: 5.3.0.CR2 When running in a clean environment (no cached .m2 repo), {{AS Module Integration Tests}} fails with a broken dependency on {{org.jboss.as:jboss-as-dist:zip:7.2.0.Alpha1-redhat-4}}. The following repos are queried: {code} [ERROR] jboss-public-repository-group (https://repository.jboss.org/nexus/content/groups/public/, releases=true, snapshots=true), [ERROR] jboss-public-repository (https://repository.jboss.org/nexus/content/groups/public, releases=true, snapshots=true), [ERROR] central (http://repo1.maven.org/maven2, releases=true, snapshots=false) {code} If this integration test relies on specific installs of JBoss AS/EAP/WildFly then they should be made optional, and *not* enabled by default as it breaks community builds/tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3218) TypeConverterInterceptor throwing NPE in distributed compatibility mode

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3218?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3218: ---------------------------------------- Hmmmm, weird. That NPE comes from converter being null. determineTypeConverter() does not return null unless one of the cached converters is null, which might be if the TypeConverter instances were not loaded correctly by the service loader in the constructor. I'm gonna try to run that branch to see if I can find out more... > TypeConverterInterceptor throwing NPE in distributed compatibility mode > ----------------------------------------------------------------------- > > Key: ISPN-3218 > URL: https://issues.jboss.org/browse/ISPN-3218 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.CR1 > Reporter: Martin Gencur > Assignee: Tristan Tarrant > Priority: Critical > Fix For: 5.3.0.Final > > Attachments: standalone-compatibility-mode.xml > > > The following test fails for the server in DIST mode when in compatibility mode. It does not happen in normal DIST mode: > {code:java} > @Test > public void testHotRodPutRestGetTest() throws Exception { > final String key = "1"; > // 1. Put with Hot Rod > RemoteCache<String, byte[]> remote = getHotRodCache(); > assertEquals(null, remote.withFlags(Flag.FORCE_RETURN_VALUE).put(key, "v1".getBytes())); > //^^^^this put operation fails > assertArrayEquals("v1".getBytes(), remote.get(key)); > // 2. Get with REST > HttpMethod get = new GetMethod(getRestUrl() + "/" + key); > getRestClient().executeMethod(get); > assertEquals(HttpServletResponse.SC_OK, get.getStatusCode()); > assertEquals("v1".getBytes(), get.getResponseBody()); > } > {code} > ISPN version: bfa10c4 - okdalvi, 2 days ago : Update BasicCache.java > ISPN server version: cb6ef3a - Tristan Tarrant, 5 days ago : ISPN-3207 Add a top-level README > Stacktrace: > {code} > 14:35:51,294 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (HotRodServerWorker-163) ISPN000136: Execution error: java.lang.NullPointerException > at org.infinispan.interceptors.compat.TypeConverterInterceptor.visitPutKeyValueCommand(TypeConverterInterceptor.java:71) [infinispan-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:83) [infinispan-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120) [infinispan-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128) [infinispan-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92) [infinispan-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:54) [infinispan-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:83) [infinispan-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343) [infinispan-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1337) [infinispan-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.CacheImpl.putInternal(CacheImpl.java:898) [infinispan-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.CacheImpl.put(CacheImpl.java:890) [infinispan-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.DecoratedCache.put(DecoratedCache.java:489) [infinispan-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.AbstractDelegatingAdvancedCache.put(AbstractDelegatingAdvancedCache.java:208) [infinispan-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.server.core.AbstractProtocolDecoder.put(AbstractProtocolDecoder.scala:203) [infinispan-server-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.server.core.AbstractProtocolDecoder.decodeValue(AbstractProtocolDecoder.scala:160) [infinispan-server-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:75) [infinispan-server-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:49) [infinispan-server-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500) [netty-3.6.5.Final.jar:] > at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435) [netty-3.6.5.Final.jar:] > at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:394) [infinispan-server-core-5.3.0-SNAPSHOT.jar:5.3.0-SNAPSHOT] > at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.5.Final.jar:] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.5.Final.jar:] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.5.Final.jar:] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.5.Final.jar:] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.5.Final.jar:] > at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.5.Final.jar:] > at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107) [netty-3.6.5.Final.jar:] > at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312) [netty-3.6.5.Final.jar:] > at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88) [netty-3.6.5.Final.jar:] > at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.6.5.Final.jar:] > at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.5.Final.jar:] > at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.5.Final.jar:] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17] > {code} > The branch with the test can be found at https://github.com/mgencur/infinispan-server/tree/ISPN-3176/compatibility... (run it with "mvn clean verify") -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2657) Support for LevelDB CacheStore

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2657?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2657: -------------------------------- Fix Version/s: 5.3.0.CR2 > Support for LevelDB CacheStore > ------------------------------ > > Key: ISPN-2657 > URL: https://issues.jboss.org/browse/ISPN-2657 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Ray Tsang > Assignee: Ray Tsang > Fix For: 5.2.7.Final, 5.3.0.CR2, 5.3.0.Final > > > Support for LevelDB, a fast key-value persistence storage. > There is a pure java implementation and a jni by fuse -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3140) JMX operation to suppress state transfer

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3140?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3140: -------------------------------- Fix Version/s: 5.2.7.Final > JMX operation to suppress state transfer > ---------------------------------------- > > Key: ISPN-3140 > URL: https://issues.jboss.org/browse/ISPN-3140 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache, State transfer > Affects Versions: 5.2.6.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Fix For: 5.2.7.Final, 5.3.0.CR2, 5.3.0.Final > > > This feature request is to expose a JMX operation on each node, to suppress state transfer for a period of time. This flag would be {{false}} by default. > The use case of this flag would be to ease bringing down (and up) a cluster for maintenance work. A typical workflow would be: > 1) Shut down application requests to the data grid > 2) Suppress state transfer on all nodes via JMX > 3) Bring down all nodes > 4) Perform maintenance work > 5) Bring up nodes, one at a time. As each node comes up, disable state transfer for the node via JMX. > 6) Once all nodes are up, enable state transfer for each node again via JMX > 7) Allow application requests to reach the grid again. > The purpose of this is to allow smooth and fast shutdown and startup, remove the risk of OOM errors (when bringing a grid down). > This is a small but useful subset of full manual state transfer as defined in ISPN-1394. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3213) Upgrade to JCache 0.7

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3213?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3213: ---------------------------------------- More things that don't make sense: https://github.com/jsr107/jsr107tck/issues/20 > Upgrade to JCache 0.7 > --------------------- > > Key: ISPN-3213 > URL: https://issues.jboss.org/browse/ISPN-3213 > Project: Infinispan > Issue Type: Component Upgrade > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.3.0.CR2, 5.3.0.Final > > > Upgrade to JCache 0.7 (https://groups.google.com/forum/#!topic/jsr107/vYRLv2xsveA) and see if issues WRT annotation integration highlighted in ISPN-2855 are fixed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3219) CommitCommands should ignore SuspectExceptions

by Dan Berindei (JIRA)

Dan Berindei created ISPN-3219: ---------------------------------- Summary: CommitCommands should ignore SuspectExceptions Key: ISPN-3219 URL: https://issues.jboss.org/browse/ISPN-3219 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 5.2.6.Final Reporter: Dan Berindei Assignee: Dan Berindei Priority: Critical Fix For: 5.3.0.CR2 We can ignore any nodes leaving the cache during the invocation of a CommitCommand - the NBST command forwarding mechanism takes care of sending the CommitCommand to the right targets. The same with 1PC PrepareCommands, they are only used for asynchronous caches and for pessimistic synchronous caches. If the cache is asynchronous we won't receive SuspectExceptions anyway, and if the cache is pessimistic the locks will have already been acquired on the primary owners before the PrepareCommand was sent. There is already a more generic issue for dealing with SuspectExceptions everywhere: ISPN-2402. But exceptions during TransactionCoordinator.commit() are much more critical than prepare exceptions, because the TM can't roll back the transaction at that point (especially if Infinispan is registered as a synchronization). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-741) Implement Continuous Query in Infinispan

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-741?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-741: ------------------------------- Labels: leads (was: ) > Implement Continuous Query in Infinispan > ---------------------------------------- > > Key: ISPN-741 > URL: https://issues.jboss.org/browse/ISPN-741 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Mircea Markus > Labels: leads > Fix For: 7.0.0.Final > > > Implement continuous query on infinispan based on the tech preview: http://github.com/mmarkus/infinispan-continuous-query. Documentation on API and functionality: http://community.jboss.org/wiki/ContinuousQuerywithInfinispan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2013