[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, 1 month
[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, 1 month
[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, 1 month
[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, 1 month
[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, 1 month
[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, 1 month