August 2009 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1534) JDBCCacheLoader does not escape wildcard characters in generated LIKE clause

by Andrew Duckworth (JIRA)

JDBCCacheLoader does not escape wildcard characters in generated LIKE clause ---------------------------------------------------------------------------- Key: JBCACHE-1534 URL: https://jira.jboss.org/jira/browse/JBCACHE-1534 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.1.0.GA Reporter: Andrew Duckworth Assignee: Manik Surtani JDBCCacheLoader does not escape wildcard characters '_' and '%' in generated LIKE clause. Node removal and recursive child loading generates the following SQL: private String constructRecursiveChildrenSql() { return "SELECT " + fqnColumn + "," + nodeColumn + " FROM " + table + " WHERE " + fqnColumn + " = ? OR " + fqnColumn + " LIKE ?"; } @Override protected String constructDeleteNodeSql() { return "DELETE FROM " + table + " WHERE " + fqnColumn + " = ? OR " + fqnColumn + " LIKE ?"; } If the FQN contains the underscore character, SQL treats this as a match any single character. Similarly if the FQN contains a '%' then it is treated as matching any substring. This means incorrect FQNs may be matched and also causes some RDBs to do an index scan rather than an index seek, leading to greater lock contention in the database and poor performance. -- 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, 4 months

3
4
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-1331) Clustering between data centres

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1331?page=com.atlassian.jira.p... ] Manik Surtani reopened JBCACHE-1331: ------------------------------------ > Clustering between data centres > ------------------------------- > > Key: JBCACHE-1331 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1331 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Replication > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 3.3.0.GA > > > A mechanism for efficiently replicating state between data centres. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1331) Clustering between data centres

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1331?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1331: ----------------------------------- Fix Version/s: 3.3.0.GA (was: 3.2.0.GA) (was: 3.2.0.BETA1) > Clustering between data centres > ------------------------------- > > Key: JBCACHE-1331 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1331 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Replication > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 3.3.0.GA > > > A mechanism for efficiently replicating state between data centres. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1533) JDBCCacheLoader does not honour the create/drop false property for the jbosscache_D table

by Andrew Duckworth (JIRA)

JDBCCacheLoader does not honour the create/drop false property for the jbosscache_D table ----------------------------------------------------------------------------------------- Key: JBCACHE-1533 URL: https://jira.jboss.org/jira/browse/JBCACHE-1533 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.1.0.GA Reporter: Andrew Duckworth Assignee: Manik Surtani Priority: Minor JDBCCacheLoader does not honour the create/drop false property for the jbosscache_D table and instead drops and recreates it even when cache.jdbc.table.create=false. This has two consequences; if the JDBC user does not have create/drop privileges a SQL exception occurs and the cache doesn't start correctly. The second consequence is in a cluster one VM starting its cache may drop the table while another VM is trying to use it. -- 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, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1531) Replication is allowed when buddy group state is inconsistent

by Brian Stansberry (JIRA)

Replication is allowed when buddy group state is inconsistent ------------------------------------------------------------- Key: JBCACHE-1531 URL: https://jira.jboss.org/jira/browse/JBCACHE-1531 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assignee: Manik Surtani Fix For: 3.2.0.BETA1 There's nothing preventing application threads sending replication messages during the buddy-group reformation process. E.g. during this section of BuddyManager.reassignBuddies: if (!obsoleteBuddies.isEmpty()) { removeFromGroup(obsoleteBuddies); } else { log.trace("No obsolete buddies found, nothing to announce."); } if (!uninitialisedBuddies.isEmpty()) { addBuddies(newBuddies); } in the middle a node might have no buddies. But application threads continue replicating -- to no one. [JBoss] 21:45:19,482 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (AsyncViewChangeHandlerThread,10.34.32.156:33822) Destination list is empty: no need to send message [JBoss] 21:45:19,495 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-194) Destination list is empty: no need to send message [JBoss] 21:45:19,495 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-194) Destination list is empty: no need to send message [JBoss] 21:45:19,496 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-194) Destination list is empty: no need to send message [JBoss] 21:45:19,515 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-95) Destination list is empty: no need to send message [JBoss] 21:45:19,537 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-64) Destination list is empty: no need to send message [JBoss] 21:45:19,540 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-65) Destination list is empty: no need to send message [JBoss] 21:45:19,540 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-65) Destination list is empty: no need to send message [JBoss] 21:45:19,542 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-65) Destination list is empty: no need to send message [JBoss] 21:45:19,564 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-53) Destination list is empty: no need to send message [JBoss] 21:45:19,568 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-13) Destination list is empty: no need to send message [JBoss] 21:45:19,569 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-185) Destination list is empty: no need to send message [JBoss] 21:45:19,570 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-196) Destination list is empty: no need to send message [JBoss] 21:45:19,605 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-171) Destination list is empty: no need to send message [JBoss] 21:45:19,661 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-19) Destination list is empty: no need to send message [JBoss] 21:45:19,667 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-51) Destination list is empty: no need to send message [JBoss] 21:45:19,682 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-109) Destination list is empty: no need to send message [JBoss] 21:45:19,682 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-152) Destination list is empty: no need to send message [JBoss] 21:45:19,727 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-182) Destination list is empty: no need to send message [JBoss] 21:45:19,772 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-20) Destination list is empty: no need to send message [JBoss] 21:45:19,827 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-134) Destination list is empty: no need to send message [JBoss] 21:45:19,845 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-171) Destination list is empty: no need to send message [JBoss] 21:45:19,854 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-115) Destination list is empty: no need to send message [JBoss] 21:45:19,893 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-148) Destination list is empty: no need to send message [JBoss] 21:45:19,978 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-74) Destination list is empty: no need to send message Effect is state on the new buddy backup nodes can be inconsistent, since messages sent after the state transfer to the new buddies but before the new buddy is added to the group will be lost. Writing the above makes me realize the problem is probably just in assignBuddies -- the window between state = acquireState( ...); .... buddyGroup.addBuddies(buddies); Ideally in that window, local application threads calling BuddyManager.getBuddyAddress(AsVector) should block. -- 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, 4 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1530) Stale copies of gravitated data left in "xxx:DEAD trees

by Brian Stansberry (JIRA)

Stale copies of gravitated data left in "xxx:DEAD trees ------------------------------------------------------- Key: JBCACHE-1530 URL: https://jira.jboss.org/jira/browse/JBCACHE-1530 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.2.0.BETA1 Reporter: Brian Stansberry Assignee: Manik Surtani There's a race that can result in a stale copy of gravitated data being left in a "/BUDDY_BACKUP/xxx:DEAD" tree: Scenario: 1) Data is store in /B_B/xxx/foo 2) xxx is leaving group 3) Gravitate data command for /B_B/xxx/foo comes in, result is returned 4) Buddy group re-formation thread move /B_B/xxx/foo to /B_B/xxx:DEAD/1/foo 5) DataGravitationCleanupCommand comes in for /B_B/xxx/foo which results in nothing happening since the node is moved A fix might involve some analysis of the backup fqn in the DataGravitationCleanupCommand, try to detect this condition. Or perhaps tracking successful GravitationResult responses, trying to match against the cleanup command. As a quick workaround I'm going to investigate an algorithm on the GravitateDataCommand sender side to not just accept the first successful result but rather to compare all positive results, giving preference to: 1) A result from the main tree 2) A result from a non :DEAD buddy backup tree 3) A result from xxx:DEAD/2 4) A result from xxx:DEAD/1 -- 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, 4 months

2
11
0 / 0

[JBoss JIRA] Created: (JBCACHE-1532) Misleading exception message from FlushTracker

by Brian Stansberry (JIRA)

Misleading exception message from FlushTracker ---------------------------------------------- Key: JBCACHE-1532 URL: https://jira.jboss.org/jira/browse/JBCACHE-1532 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.1.0.GA, 3.2.0.BETA1 Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Trivial Fix For: 3.2.0.GA Following call stack doesn't involve state transfer but the exception message implies it does: [JBoss] Caused by: org.jboss.cache.lock.TimeoutException: State retrieval timed out waiting for flush to unblock. (timeout = 60 seconds) [JBoss] at org.jboss.cache.RPCManagerImpl$FlushTracker.waitForFlushCompletion(RPCManagerImpl.java:195) [JBoss] at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:745) [JBoss] at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:716) [JBoss] at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:721) [JBoss] at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:161) [JBoss] at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:135) [JBoss] at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:107) [JBoss] at org.jboss.cache.interceptors.ReplicationInterceptor.handleCrudMethod(ReplicationInterceptor.java:160) [JBoss] at org.jboss.cache.interceptors.ReplicationInterceptor.visitPutDataMapCommand(ReplicationInterceptor.java:113) -- 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, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1514) Problems Binding JBoss Cache Instance in JNDI

by Matt Accola (JIRA)

Problems Binding JBoss Cache Instance in JNDI --------------------------------------------- Key: JBCACHE-1514 URL: https://jira.jboss.org/jira/browse/JBCACHE-1514 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.GA Environment: WebSphere 6.1.0.17 Reporter: Matt Accola Assignee: Manik Surtani Attempting to create a JBoss Cache instance and bind to JNDI for use by multiple applications. In WebSphere 6.1 the best way to do this is to create a Custom Service, http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/co.... I have attached a simple Custom Service which creates a new cache instance from an XML configuration file, obtains an InitialContext and attempts to bind the org.jboss.cache.Cache reference. The Custom Service is in the attached JBossCacheCustomService.jar. When I try to start the server I get the following error: com.ibm.ws.naming.util.CannotBindObjectException: Object is not of any type which can be bound. As described in the WebSphere 6.1 Info Center, http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/co... , this is because the object which is being bound is not Serializable. I have also attached the complete log of the server startup. -- 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, 4 months

2
8
0 / 0

[JBoss JIRA] Created: (JBCACHE-1519) ClassCastException in ReadCommittedNode.markForUpdate()

by Krzysztof Sobolewski (JIRA)

ClassCastException in ReadCommittedNode.markForUpdate() ------------------------------------------------------- Key: JBCACHE-1519 URL: https://jira.jboss.org/jira/browse/JBCACHE-1519 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking, Transactions Affects Versions: 3.1.0.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani Attachments: ClassCastExceptionTest.java The exception is deterministic (test case is attached) and even easy to reproduce. Prerequisites: - isolation level READ_COMMITTED - lockParentForChildInsertRemove == true - transactions (not sure about this one) The test attached most probably isn't minimal, but it's small enough (it's almost exactly what my application does). The test adds a small tree in one transaction then in another transaction removes it and adds again, and it does both of those in a loop. The exception is in the *second* iteration. The exception occurs because the line 121 of ReadCommittedNode expects the backup of node to be NodeReference, but somehow it's an UnversionedNode instead. This node is retrieved from the data container, where the child is being added as an UnversionedNode by MVCCNodeHelper line 338. When lockParentForChildInsertRemove is false this fragment is never executed and there is no exception. -- 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, 4 months

3
13
0 / 0

[JBoss JIRA] Created: (JBCACHE-1516) CacheStoreInterceptor hangs when concurrent access to txStores HashMap

by Takayoshi Kimura (JIRA)

CacheStoreInterceptor hangs when concurrent access to txStores HashMap ---------------------------------------------------------------------- Key: JBCACHE-1516 URL: https://jira.jboss.org/jira/browse/JBCACHE-1516 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.GA, 1.4.0.GA Reporter: Takayoshi Kimura Assignee: Takayoshi Kimura CacheStoreInterceptor has a HashMap txStores instance variable for cache stats. This map is accessed from multiple threads but not synchronized. With Sun JVM, concurrent write operations to a HashMap sometimes hang. See the following bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6484560 This bug affects in all branches, 1.4.x, 2.2.x and 3.x. -- 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, 4 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues August 2009