July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3372) Make AdvanceCache.getXaResource throw an exception if the cache is not XA + recovery enabled

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3372?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3372: ------------------------------------- This would give a clear message to users and avoid issues such as WFLY-1719 > Make AdvanceCache.getXaResource throw an exception if the cache is not XA + recovery enabled > -------------------------------------------------------------------------------------------- > > Key: ISPN-3372 > URL: https://issues.jboss.org/browse/ISPN-3372 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Minor > > also on the returned XAResource instance make sure that all methods besides the recovery releated ones would throw an exception. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3372) Make AdvanceCache.getXaResource throw an exception if the cache is not XA + recovery enabled

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3372?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3372: -------------------------------- Priority: Minor (was: Major) > Make AdvanceCache.getXaResource throw an exception if the cache is not XA + recovery enabled > -------------------------------------------------------------------------------------------- > > Key: ISPN-3372 > URL: https://issues.jboss.org/browse/ISPN-3372 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Minor > > also on the returned XAResource instance make sure that all methods besides the recovery releated ones would throw an exception. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3372) Make AdvanceCache.getXaResource throw an exception if the cache is not XA + recovery enabled

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3372: ----------------------------------- Summary: Make AdvanceCache.getXaResource throw an exception if the cache is not XA + recovery enabled Key: ISPN-3372 URL: https://issues.jboss.org/browse/ISPN-3372 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Mircea Markus also on the returned XAResource instance make sure that all methods besides the recovery releated ones would throw an exception. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3369) ParserRegistry throws exception when DefaultCacheManager is using config file

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3369?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3369: -------------------------------- Assignee: Mircea Markus (was: Galder Zamarreño) > ParserRegistry throws exception when DefaultCacheManager is using config file > ----------------------------------------------------------------------------- > > Key: ISPN-3369 > URL: https://issues.jboss.org/browse/ISPN-3369 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 6.0.0.Alpha1 > Reporter: Emre Varol > Assignee: Mircea Markus > Priority: Blocker > Fix For: 6.0.0.Alpha2 > > > ParserRegistiry throws an exception with message "ISPN000234: Root element for remoteStore already registered in ParserRegistry" when DefaultCacheManager is created with a config file. > It is because BdbjeCacheStoreConfigurationParser60 has wrong namespace annotation. In line 27, "remoteStore" should be replaced with "bdbjeStore". -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3293) Putting entries with memcached is ignoring the queue-flush-interval parameter

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3293?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-3293: --------------------------------------- This issue is caused by the new "distribution-based replication" algorithm in Infinispan: a key's primary owner might not be the local node, so a synchronous put operation is sent to the key owner, thus overriding the async queue. The fact that the test works for HotRod is probably because the encoding of the key differs. The actual solution to this problem will be solved by ISPN-3371 > Putting entries with memcached is ignoring the queue-flush-interval parameter > ----------------------------------------------------------------------------- > > Key: ISPN-3293 > URL: https://issues.jboss.org/browse/ISPN-3293 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Jakub Markos > Assignee: Tristan Tarrant > Attachments: server1.log, server2.log > > > I have a cluster of 2 nodes with the following configuration: > {code:xml} > <replicated-cache name="memcachedCache" > start="EAGER" > mode="ASYNC" > batching="false" > queue-size="1000" > queue-flush-interval="15000"> > </replicated-cache> > {code} > The following code (MemcachedHelper is a memcached client) > {code} > mc1 = new MemcachedHelper(server1.getMemcachedEndpoint().getInetAddress().getHostName(), server1.getMemcachedEndpoint().getPort()); > mc2 = new MemcachedHelper(server2.getMemcachedEndpoint().getInetAddress().getHostName(), server2.getMemcachedEndpoint().getPort()); > mc1.set("key1", "value1"); > assertTrue(null != mc1.get("key1")); > assertTrue(null == mc2.get("key1")); > {code} > fails on the 2nd assert, because the entry is retrieved. > According to logs (attached), the replication queue is correctly flushed after 15 seconds with 1 element (and happens after the gets). > Works correctly with hotrod (entry is replicated only after the flush happens). -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3371) Add an non-tx distribution interceptor optimised for non-concurrent and async usage

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3371: ----------------------------------- Summary: Add an non-tx distribution interceptor optimised for non-concurrent and async usage Key: ISPN-3371 URL: https://issues.jboss.org/browse/ISPN-3371 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.3.0.Final Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 6.0.0.Beta2, 6.0.0.Final This is needed for: - improving performance of sync caches that don't have concurrent writes - improving performance of async caches for which there is no no consistency guarantee in the presence of concurrent writes anyway -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3358) Update to Apache Lucene 4.4.0

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3358?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3358: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Update to Apache Lucene 4.4.0 > ----------------------------- > > Key: ISPN-3358 > URL: https://issues.jboss.org/browse/ISPN-3358 > Project: Infinispan > Issue Type: Component Upgrade > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 6.0.0.Alpha2 > > -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3293) Putting entries with memcached is ignoring the queue-flush-interval parameter

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3293?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-3293: --------------------------------------- Which version did this happen on ? > Putting entries with memcached is ignoring the queue-flush-interval parameter > ----------------------------------------------------------------------------- > > Key: ISPN-3293 > URL: https://issues.jboss.org/browse/ISPN-3293 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Jakub Markos > Assignee: Tristan Tarrant > Attachments: server1.log, server2.log > > > I have a cluster of 2 nodes with the following configuration: > {code:xml} > <replicated-cache name="memcachedCache" > start="EAGER" > mode="ASYNC" > batching="false" > queue-size="1000" > queue-flush-interval="15000"> > </replicated-cache> > {code} > The following code (MemcachedHelper is a memcached client) > {code} > mc1 = new MemcachedHelper(server1.getMemcachedEndpoint().getInetAddress().getHostName(), server1.getMemcachedEndpoint().getPort()); > mc2 = new MemcachedHelper(server2.getMemcachedEndpoint().getInetAddress().getHostName(), server2.getMemcachedEndpoint().getPort()); > mc1.set("key1", "value1"); > assertTrue(null != mc1.get("key1")); > assertTrue(null == mc2.get("key1")); > {code} > fails on the 2nd assert, because the entry is retrieved. > According to logs (attached), the replication queue is correctly flushed after 15 seconds with 1 element (and happens after the gets). > Works correctly with hotrod (entry is replicated only after the flush happens). -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3366) Data loss when entry forwarding to primary owner and primary owner shutdown

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3366?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3366: ------------------------------------- [~nekop] there's also a topology change going on. Would be interesting to have the raw logs that contain the topology change information as well. > Data loss when entry forwarding to primary owner and primary owner shutdown > --------------------------------------------------------------------------- > > Key: ISPN-3366 > URL: https://issues.jboss.org/browse/ISPN-3366 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.4.Final, 6.0.0.Alpha1 > Reporter: Takayoshi Kimura > Assignee: Dan Berindei > Priority: Critical > Attachments: ISPN-3366-logs.zip > > > Looks like a problem in entry forwarding. > Here is test scenario: > * DIST numOwners=2, start with 4 nodes cluster then normal shutdown 1 node during load > * HotRod putIfAbsent accesses from 40 threads (1 process, 1 remote cache instance), 40000 entries total > After the test run, the numberOfEntries on each node are: > * node1: 26608 > * node2: 26622 > * node3: 26746 > * node4: 0 > Total is 79976 and HotRod client received 11 errors, so 79976 + (11 * 2) = 79998. It means 1 entry is completely missing. > Let's take a look at the missing entry, hash(thread16key59) = 574ff563. > Current CH: owners(574ff563) are [node4, node1] > The events sequence is: > * hotrod -> node1 > * node1 forwarding it to primary owner node4 > * node4 doesn't process the forwarded entry, shutdown > Result owners(7c29bccb) is [] empty. This entry is completely lost without any errors. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3293) Putting entries with memcached is ignoring the queue-flush-interval parameter

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3293?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-3293: --------------------------------------- Nothing do to with the issue itself, but assertTrue(null == mc2.get("key1")); should be assertNull(mc2.get("key1")); > Putting entries with memcached is ignoring the queue-flush-interval parameter > ----------------------------------------------------------------------------- > > Key: ISPN-3293 > URL: https://issues.jboss.org/browse/ISPN-3293 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Jakub Markos > Assignee: Tristan Tarrant > Attachments: server1.log, server2.log > > > I have a cluster of 2 nodes with the following configuration: > {code:xml} > <replicated-cache name="memcachedCache" > start="EAGER" > mode="ASYNC" > batching="false" > queue-size="1000" > queue-flush-interval="15000"> > </replicated-cache> > {code} > The following code (MemcachedHelper is a memcached client) > {code} > mc1 = new MemcachedHelper(server1.getMemcachedEndpoint().getInetAddress().getHostName(), server1.getMemcachedEndpoint().getPort()); > mc2 = new MemcachedHelper(server2.getMemcachedEndpoint().getInetAddress().getHostName(), server2.getMemcachedEndpoint().getPort()); > mc1.set("key1", "value1"); > assertTrue(null != mc1.get("key1")); > assertTrue(null == mc2.get("key1")); > {code} > fails on the 2nd assert, because the entry is retrieved. > According to logs (attached), the replication queue is correctly flushed after 15 seconds with 1 element (and happens after the gets). > Works correctly with hotrod (entry is replicated only after the flush happens). -- 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, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2013