July 2013 - infinispan-issues - Jboss List Archives

[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: Tristan Tarrant (was: Mircea Markus) > 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: Tristan Tarrant > Priority: Blocker > > 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-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: -------------------------------- Fix Version/s: 6.0.0.Alpha2 > 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: Tristan Tarrant > 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-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: Galder Zamarreño (was: Tristan Tarrant) > 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: Galder Zamarreño > 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-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: ------------------------------------- Following on the previous comment, N1 sees as owners {N4, N1} but N4 doesn't see itself as an owner of that key. N1: {quote} 2013-07-25:13:26:02,243 TRACE [org.infinispan.interceptors.distribution.NonTxDistributionInterceptor] (HotRodServerWorker-15) Not doing a remote get for key ByteArrayKey{data=ByteArray{size=16, hashCode=574ff563, array=0x033e0d7468726561..}} since entry is not affected by rehash or is already in data container. We are node1/clustered(s1), *owners are [node4/clustered(s1), node1/clustered(s1)]* {quote} N4: {quote} 2013-07-25:13:26:02,000 TRACE [org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor] (OOB-188,shared=tcp) *Are (node4/clustered(s1)) we the lock owners for key 'ByteArrayKey{data=ByteArray{size=16, hashCode=19e17f1d, array=0x033e0d7468726561..}}'? false* {quote} The fact that the hash code is different between nodes explains this discrepancy. Would be interesting to see if the key array is sent correctly between nodes (currently only the first 8 bytes are written). [~nekop] would it be possible to re-run this with -Dinfinispan.arrays.debug flag enabled? > 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-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: ------------------------------------- Interesting enough, the hash code of the key in N4 is different than the hash code of the key in N1: N1: {quote} 2013-07-25:13:26:02,242 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (HotRodServerWorker-15) Invoked with command PutKeyValueCommand{key=ByteArrayKey{data=ByteArray{size=16, hashCode=*574ff563*, array=*0x033e0d7468726561..*}}, value=CacheValue{data=ByteArray{size=8, array=0x033e0576616c7565..}, version=844437815034540 {quote} N4: {quote} 2013-07-25:13:26:01,999 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (OOB-188,shared=tcp) Attempting to execute command: SingleRpcCommand{cacheName='1', command=PutKeyValueCommand{key=ByteArrayKey{data=ByteArray{size=16, hashCode=*19e17f1d*, array=*0x033e0d7468726561..*}}, ... {quote} > 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-3327) Server init.d script should be customized for Infinispan

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3327?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3327: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-server/pull/125 > Server init.d script should be customized for Infinispan > -------------------------------------------------------- > > Key: ISPN-3327 > URL: https://issues.jboss.org/browse/ISPN-3327 > Project: Infinispan > Issue Type: Bug > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > > The current init.d script included in Infinispan Server should be appropriately renamed and verified -- 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-3330) Hotrod clients getWithMetadata doesn't work when locking isolation != NONE

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3330?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3330: ---------------------------------- Summary: Hotrod clients getWithMetadata doesn't work when locking isolation != NONE (was: Hotrod clients getWithMetadata doesn't work with dist/repl cache) > Hotrod clients getWithMetadata doesn't work when locking isolation != NONE > -------------------------------------------------------------------------- > > Key: ISPN-3330 > URL: https://issues.jboss.org/browse/ISPN-3330 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final > Reporter: Jakub Markos > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 6.0.0.Final > > > I have a cluster of 2 infinispan servers with this configuration: > {code:xml}<subsystem xmlns="urn:infinispan:server:core:5.3"> > <cache-container name="default" default-cache="default" listener-executor="infinispan-listener"> > <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/> > <distributed-cache name="default" start="EAGER" mode="SYNC" segments="1" owners="2" batching="false" l1-lifespan="0" remote-timeout="60000"> > <locking isolation="REPEATABLE_READ"/> > </distributed-cache> > </cache-container> > </subsystem>{code} > Running this code: > {code}remoteCache.put("k1", "v1", 10000000, TimeUnit.MICROSECONDS); // setting only lifespan > MetadataValue<String> k1 = remoteCache.getWithMetadata("k1"); > assertTrue(k1.getValue().equals("v1")); > // microseconds converted to seconds > assertTrue(k1.getLifespan() == 10); > assertTrue(k1.getMaxIdle() == -1);{code} > fails with: > {code}org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[5] returned server error (status=0x85): java.lang.ClassCastException: org.infinispan.container.entries.RepeatableReadEntry can > not be cast to org.infinispan.container.entries.InternalCacheEntry > at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143) > at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:52) > at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:35) > at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:23) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.getWithMetadata(RemoteCacheImpl.java:145){code} > Works with isolation="READ_COMMITED"/"NONE" or with no <locking> at all. -- 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-3327) Server init.d script should be customized for Infinispan

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3327?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3327: ------------------------------------- Assignee: Tristan Tarrant (was: Mircea Markus) > Server init.d script should be customized for Infinispan > -------------------------------------------------------- > > Key: ISPN-3327 > URL: https://issues.jboss.org/browse/ISPN-3327 > Project: Infinispan > Issue Type: Bug > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > > The current init.d script included in Infinispan Server should be appropriately renamed and verified -- 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-3357) Insufficient owners with putIfAbsent during node join rebalance

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3357?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3357: ------------------------------------- [~nekop] can you please upload all the logs somewhere (dropbox) in case we'd need to look at some other details? > Insufficient owners with putIfAbsent during node join rebalance > --------------------------------------------------------------- > > Key: ISPN-3357 > URL: https://issues.jboss.org/browse/ISPN-3357 > 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: 7c29bccb.log > > > Here is test scenario: > * DIST numOwners=2, start with 3 nodes cluster then join 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: 20074 > * node2: 19888 > * node3: 20114 > * node4: 18885 > Total is 78961, 1039 entries are missing. No error on HotRod client side so 80000 entries should be there. > Let's take a look at example missing entry, hash(thread01key151) = 7c29bccb. > Current CH: owners(7c29bccb) are [node1, node2] > Pending CH: owners(7c29bccb) are [node1, node2, node4] > Balanced CH: owners(7c29bccb) are [node1, node4] > The events sequence is: > * hotrod -> node1 > * node1 -> node2, node4 > * node2 committed entry > * node4 performed clustered get before write, got a value from node2 and will not commit the entry because this node thinks it's not changed/created > * node1 committed entry > * node2 invalidates the entry because it's no longer an owner > Result owners(7c29bccb) are only node1 and node4 is missing. This entry may be completely lost by further rebalances when node4 is donor for this segment. -- 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-3323) Update Hotrod client version number

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3323?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3323: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1989 > Update Hotrod client version number > ----------------------------------- > > Key: ISPN-3323 > URL: https://issues.jboss.org/browse/ISPN-3323 > Project: Infinispan > Issue Type: Task > Components: Remote protocols > Affects Versions: 5.3.0.Final > Reporter: Dan Berindei > Assignee: Tristan Tarrant > Fix For: 6.0.0.Final > > > {{BasicCache.getVersion()}} is documented to return "the version of Infinispan", but {{RemoteCacheImpl.getVersion()}} returns {{Version.getProtocolVersion()}} (which is {{"1.0"}}). > I think there should be a separate method to return the protocol version, and {{RemoteCacheImpl.getVersion()}} should return the Infinispan version (with a hook in the release script to update it automatically). > {{Version.getProtocolVersion()}} should also be updated to {{"1.2"}}. -- 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