[JBoss JIRA] Updated: (JBCACHE-1393) putFailFast javadoc on timeout is misleading
by Manik Surtani (JIRA)
[ https://jira.jboss.org/jira/browse/JBCACHE-1393?page=com.atlassian.jira.p... ]
Manik Surtani updated JBCACHE-1393:
-----------------------------------
Fix Version/s: 1.4.1.SP10
(was: 1.4.X)
> putFailFast javadoc on timeout is misleading
> --------------------------------------------
>
> Key: JBCACHE-1393
> URL: https://jira.jboss.org/jira/browse/JBCACHE-1393
> Project: JBoss Cache
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.4.1.SP9
> Reporter: Galder Zamarreno
> Assignee: Galder Zamarreno
> Fix For: 1.4.1.SP10
>
>
> putFailFast() javadoc says:
> * @param timeout Number of milliseconds to wait until a lock has been acquired. A TimeoutException will
> * be thrown if not successful. 0 means to wait forever
> 0 actually means no wait at all.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 12 months
- 1
- 0
[JBoss JIRA] Created: (JBCACHE-1406) issue with removing an node in tx
by Mircea Markus (JIRA)
issue with removing an node in tx
---------------------------------
Key: JBCACHE-1406
URL: https://jira.jboss.org/jira/browse/JBCACHE-1406
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.4.1.SP9
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 1.4.X
tx.start()'
cache.put(/a/b/c);
cache.remove(/a/b);
cache.put(/a/b/d);
tx.commit();
assert "this still exists in the internal structure" : cache.peek(/a/b/c) == null;
above assertion fails.
The problem is that when tx commits and cache wants to remove /a/b, sees that its not marked for removal (as it was re-added through put(/a/b/d) )and does not look in its children.
Method is TreeCache.realRemove, and it;s called from TxInterceptor.commit()
UT added to reproduce the issue is: org.jboss.cache.RemoveOnTxTest.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 12 months
- 4
- 13
[JBoss JIRA] Created: (JBCACHE-1412) TreeCacheMarshaller140 marshalling replaces distinct but equal() objects
by Brian Stansberry (JIRA)
TreeCacheMarshaller140 marshalling replaces distinct but equal() objects
------------------------------------------------------------------------
Key: JBCACHE-1412
URL: https://jira.jboss.org/jira/browse/JBCACHE-1412
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Replication
Affects Versions: 1.4.1.SP9
Reporter: Brian Stansberry
Assignee: Manik Surtani
Priority: Critical
The marshalling logic in TreeCacheMarshaller140 uses a HashMap as store of objects already written so it can replace subsequent writes of the same object with a magic number. Use of a HashMap is incorrect, as magic number replacement should only occur if an object with the same identity is detected, not one that just satisfies equals() but not ==.
Either a custom map that uses System.identityHashCode() for hashing and == instead of equals() for equality is needed, or the map key should be System.identityHashCode(). Note the Object.hashCode() javadocs do not absolutely guarantee uniqueness in System.identityHashCode(), so a custom map is probably better:
"As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)"
Non-uniquenesss in System.identityHashCode() might be more of an issue in systems with large heaps that can't be addressed with 32 bits.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 12 months
- 2
- 7