[JBoss JIRA] (ISPN-3357) Insufficient owners with putIfAbsent during rebalance
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3357?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3357:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> made a comment on [bug 989808|https://bugzilla.redhat.com/show_bug.cgi?id=989808]
It turns out that this bug will be fixed in ER1 (after integrating https://github.com/infinispan/infinispan/commit/f9982dea28). So moving the target milestone.
> Insufficient owners with putIfAbsent during 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
> Fix For: 5.2.8.Final, 6.0.0.Alpha3
>
> Attachments: 7c29bccb.log, ISPN-3357-full-logs-leave.zip
>
>
> 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, 3 months
[JBoss JIRA] (ISPN-3470) Expiration processing can overflow if maxIdleTime == Long.MAX
by Erik Salter (JIRA)
Erik Salter created ISPN-3470:
---------------------------------
Summary: Expiration processing can overflow if maxIdleTime == Long.MAX
Key: ISPN-3470
URL: https://issues.jboss.org/browse/ISPN-3470
Project: Infinispan
Issue Type: Feature Request
Components: Eviction
Affects Versions: 5.2.7.Final
Reporter: Erik Salter
Assignee: Mircea Markus
We have a use case where the maxIdle value of a CacheEntry can be set to Long.MAX. In this case, the isExpiredTransient() function won't work as expected, since maxIdle + lastUsed will overflow.
--
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, 3 months
[JBoss JIRA] (ISPN-3366) Data loss when entry forwarding to primary owner and primary owner shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3366?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3366:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 989807|https://bugzilla.redhat.com/show_bug.cgi?id=989807] from ON_QA to VERIFIED
> 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
> Fix For: 5.2.8.Final, 6.0.0.Alpha3, 6.0.0.Final
>
> Attachments: ISPN-3366-full-logs-3rd.zip, ISPN-3366-full-logs-4th.zip, 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, 3 months
[JBoss JIRA] (ISPN-3469) stateTransfer.fetchInMemoryState XSD documentation is incomplete
by Dan Berindei (JIRA)
Dan Berindei created ISPN-3469:
----------------------------------
Summary: stateTransfer.fetchInMemoryState XSD documentation is incomplete
Key: ISPN-3469
URL: https://issues.jboss.org/browse/ISPN-3469
Project: Infinispan
Issue Type: Bug
Components: Documentation
Affects Versions: 6.0.0.Alpha3, 5.3.0.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Minor
Fix For: 6.0.0.Final
The XSD documentation for the {{clustering.stateTransfer.fetchInMemoryState}} setting only mentions nodes joining the cache, it doesn't mention that it also covers the redistribution of state between existing nodes when a node leaves.
The javadoc is a bit more complete/up-to-date, but it only mentions that if disabled, a key may have less than numOwners owners - it doesn't mention that the key might be lost completely, or that some nodes may not be able to retrieve the value of the key even though there is still a copy of the key in the cluster.
--
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, 3 months
[JBoss JIRA] (ISPN-3175) Upgrade the java hotrod client to support remote querying
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3175?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3175:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Upgrade the java hotrod client to support remote querying
> ---------------------------------------------------------
>
> Key: ISPN-3175
> URL: https://issues.jboss.org/browse/ISPN-3175
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Priority: Blocker
> Labels: jdg62
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
>
> Once we'll have ISPN-3169(define query fluent API), ISPN-3173(add a new query operation over hotrod) and ISPN-3174(String-based query language) in place, this is about connecting the dots: invoke the remote query on the server and present the result to the user.
> h3.On the client side
> As described in ISPN-3173, the query is sent as a byte[] to the server: the payload.
> The request payload is query specific (not defined in the HR protocol) and at this stage has the following format: [Q_TYPE] [QUERY_ST] [FIRST_INDEX] [PAGE_SIZE]. This format accommodates the remote query requirements as defined in ISPN-3169.
> - Q_TYPE (protobuf's byte) and query identifier, 1 for JPAQL (this is the query type we'll support). In future we'll add different query types as well.
> - QUERY_STRING (protobuf's string)- JPAQL string generated by the fluent API (ISPN-3169). Parameters are encoded in this string (vs being sent separately)
> - FIRST_INDEX + PAGE_SIZE (protobuf's int)- used for paginating/iterating over the result set.
> HR response: [HR_SUCESS_FLAG] [payload]
> PAYLOAD = [NUM_EL] [PROJ_SIZE] [ELEMENTS]
> - even though at this stage we don't support projections (see ISPN-3169) PROJ_SIZE is added for future compatibility when projection will be supported.
> Note that the payload for both request and response should be marshalled with protobuf as this information is read/written over multiple clients.
> h3.On the server side
> - the server module reads the query operation and the payload (byte[])
> - invokes QueryFacade.query(byte[]) : byte[]
> - QueryFacade is an interface defined in the server modules
> - has an implementation in the remote-query module (new modules)
> - the reason for adding this module: RemoteQueryImpl cannot be in the server modules (ASL) as it has a dependency on the query module (LGPL) which would "contaminate" the server module. Another option would be to merge it in the query module itself, but doesn't feel like a natural fit as its responsibility is serializing data (protobuf). OTOH if it is small we can merge it there so that we don't add a new module to the system?
>
> For an overview on the remote querying see https://community.jboss.org/wiki/QueryingDesignInInfinispan
--
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, 3 months
[JBoss JIRA] (ISPN-3468) ClassCastException in map-reduce with unfamiliar key type, some cache stores and storeAsBinary
by Krzysztof Sobolewski (JIRA)
[ https://issues.jboss.org/browse/ISPN-3468?page=com.atlassian.jira.plugin.... ]
Krzysztof Sobolewski commented on ISPN-3468:
--------------------------------------------
Oh, the test case is in a base test class so it will be run for all cache stores that include a test class extending this one. It should fail for JdbcBinaryCacheStore at least.
> ClassCastException in map-reduce with unfamiliar key type, some cache stores and storeAsBinary
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-3468
> URL: https://issues.jboss.org/browse/ISPN-3468
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.3.0.Final
> Reporter: Krzysztof Sobolewski
> Assignee: Mircea Markus
> Attachments: 0001-core-add-BaseCacheStoreFunctionalTest.testMapReduceS.patch
>
>
> The conditions needed to replicate:
> 1) storeAsBinary enabled for keys
> 2) a cache store that marshals keys directly, e.g. any BucketBasedCacheStore (I'm using JdbcBinaryCacheStore)
> 3) a key type that is unfamiliar to MarshalledValue.isTypeExcluded(Class<?>)
> If these are satisfied, then map-reduce fails with an exception like this:
> org.infinispan.CacheException: java.util.concurrent.ExecutionException: java.lang.ClassCastException: org.infinispan.marshall.MarshalledValue cannot be cast to com.example.UnfamiliarKeyType
> at com.example.TestMapper.map(TestMapper.java:11) ~[?:?]
> at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.map(MapReduceManagerImpl.java:216) ~[?:?]
> at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapAndCombineForLocalReduction(MapReduceManagerImpl.java:103) ~[?:?]
> at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.invokeMapCombineLocallyForLocalReduction(MapReduceTask.java:977) ~[?:?]
> at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.access$300(MapReduceTask.java:916) ~[?:?]
> at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:948) ~[?:?]
> at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:944) ~[?:?]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[?:1.6.0_45]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[?:1.6.0_45]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) ~[?:1.6.0_45]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[?:1.6.0_45]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[?:1.6.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) ~[?:1.6.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) ~[?:1.6.0_45]
--
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, 3 months
[JBoss JIRA] (ISPN-3468) ClassCastException in map-reduce with unfamiliar key type, some cache stores and storeAsBinary
by Krzysztof Sobolewski (JIRA)
[ https://issues.jboss.org/browse/ISPN-3468?page=com.atlassian.jira.plugin.... ]
Krzysztof Sobolewski updated ISPN-3468:
---------------------------------------
Attachment: 0001-core-add-BaseCacheStoreFunctionalTest.testMapReduceS.patch
A patch that adds a test case replicating the problem.
> ClassCastException in map-reduce with unfamiliar key type, some cache stores and storeAsBinary
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-3468
> URL: https://issues.jboss.org/browse/ISPN-3468
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.3.0.Final
> Reporter: Krzysztof Sobolewski
> Assignee: Mircea Markus
> Attachments: 0001-core-add-BaseCacheStoreFunctionalTest.testMapReduceS.patch
>
>
> The conditions needed to replicate:
> 1) storeAsBinary enabled for keys
> 2) a cache store that marshals keys directly, e.g. any BucketBasedCacheStore (I'm using JdbcBinaryCacheStore)
> 3) a key type that is unfamiliar to MarshalledValue.isTypeExcluded(Class<?>)
> If these are satisfied, then map-reduce fails with an exception like this:
> org.infinispan.CacheException: java.util.concurrent.ExecutionException: java.lang.ClassCastException: org.infinispan.marshall.MarshalledValue cannot be cast to com.example.UnfamiliarKeyType
> at com.example.TestMapper.map(TestMapper.java:11) ~[?:?]
> at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.map(MapReduceManagerImpl.java:216) ~[?:?]
> at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapAndCombineForLocalReduction(MapReduceManagerImpl.java:103) ~[?:?]
> at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.invokeMapCombineLocallyForLocalReduction(MapReduceTask.java:977) ~[?:?]
> at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.access$300(MapReduceTask.java:916) ~[?:?]
> at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:948) ~[?:?]
> at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:944) ~[?:?]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[?:1.6.0_45]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[?:1.6.0_45]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) ~[?:1.6.0_45]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[?:1.6.0_45]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[?:1.6.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) ~[?:1.6.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) ~[?:1.6.0_45]
--
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, 3 months
[JBoss JIRA] (ISPN-3468) ClassCastException in map-reduce with unfamiliar key type, some cache stores and storeAsBinary
by Krzysztof Sobolewski (JIRA)
Krzysztof Sobolewski created ISPN-3468:
------------------------------------------
Summary: ClassCastException in map-reduce with unfamiliar key type, some cache stores and storeAsBinary
Key: ISPN-3468
URL: https://issues.jboss.org/browse/ISPN-3468
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 5.3.0.Final
Reporter: Krzysztof Sobolewski
Assignee: Mircea Markus
The conditions needed to replicate:
1) storeAsBinary enabled for keys
2) a cache store that marshals keys directly, e.g. any BucketBasedCacheStore (I'm using JdbcBinaryCacheStore)
3) a key type that is unfamiliar to MarshalledValue.isTypeExcluded(Class<?>)
If these are satisfied, then map-reduce fails with an exception like this:
org.infinispan.CacheException: java.util.concurrent.ExecutionException: java.lang.ClassCastException: org.infinispan.marshall.MarshalledValue cannot be cast to com.example.UnfamiliarKeyType
at com.example.TestMapper.map(TestMapper.java:11) ~[?:?]
at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.map(MapReduceManagerImpl.java:216) ~[?:?]
at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapAndCombineForLocalReduction(MapReduceManagerImpl.java:103) ~[?:?]
at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.invokeMapCombineLocallyForLocalReduction(MapReduceTask.java:977) ~[?:?]
at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.access$300(MapReduceTask.java:916) ~[?:?]
at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:948) ~[?:?]
at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:944) ~[?:?]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[?:1.6.0_45]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[?:1.6.0_45]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) ~[?:1.6.0_45]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[?:1.6.0_45]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[?:1.6.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) ~[?:1.6.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) ~[?:1.6.0_45]
--
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, 3 months