January 2009 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1466) Deadlock in JDBCCacheLoader

by Grzegorz Klimek (JIRA)

Deadlock in JDBCCacheLoader --------------------------- Key: JBCACHE-1466 URL: https://jira.jboss.org/jira/browse/JBCACHE-1466 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.0.1.GA, 1.4.1.SP8 Reporter: Grzegorz Klimek Assignee: Manik Surtani It is possible to have a deadlock in JDBCCacheLoader when concurrently trying to put two different entries into it. For example: in version 3.0.1.GA trying to put Fqns "/a/b" and "/c/d" at the same time is fine, but "/a/m" and "/l/p" is not. See referenced JBoss Forum topic for a unit test and proposed solution. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1465) Make MBean name independent of Thread name when used in LOCAL mode.

by Galder Zamarreno (JIRA)

Make MBean name independent of Thread name when used in LOCAL mode. ------------------------------------------------------------------- Key: JBCACHE-1465 URL: https://jira.jboss.org/jira/browse/JBCACHE-1465 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.1.GA Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.0.2.GA When using JBossCache in LOCAL mode, make it's MBean independent of the thread name to avoid potential issues with specific thread names. Alternatives include using UUID.randomUUID().toString() as part of the MBean name but as the instance will only be LOCAL, we only need to make sure the MBean name is unique in the VM, so Manik's suggestion to use Integer.toHexString(System.identityHashCode(objectToRegister)) in JBCACHE-1444 should be enough. We also have to take account that UUIDs are not very readable. -- 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, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1463) Adding the missing APIs like cache.isCoordinator and cache.exists()

by Srinivasan Bakthavachalam (JIRA)

Adding the missing APIs like cache.isCoordinator and cache.exists() ------------------------------------------------------------------- Key: JBCACHE-1463 URL: https://jira.jboss.org/jira/browse/JBCACHE-1463 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.1.CR2 Reporter: Srinivasan Bakthavachalam Assignee: Manik Surtani Priority: Minor It would be nice if the API isCoordinator() and isExists() which existed for JBossCache 1.4.x TreeCache are re-introduced for the latest versions. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1458) CacheJmxWrapper.printCacheDetailsAsHtml not showing carriage returns properly

by Galder Zamarreno (JIRA)

CacheJmxWrapper.printCacheDetailsAsHtml not showing carriage returns properly ----------------------------------------------------------------------------- Key: JBCACHE-1458 URL: https://jira.jboss.org/jira/browse/JBCACHE-1458 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.1.GA Environment: Fedora 10 + Firefox 3 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.0.2.GA HTML generate is something like this which does not show correctly in the environment indicated: <html><head> <title>Operation Results</title> <link rel="stylesheet" href="style_master.css" type="text/css"> <meta http-equiv="cache-control" content="no-cache"> </head><body leftmargin="10" rightmargin="10" topmargin="10"> <table align="center" border="0" cellpadding="0" cellspacing="0" width="100%"> <tbody><tr> <td align="center" height="105"><h1>JMX MBean Operation View</h1>localhost.localdomain</td> <td align="center" height="105" width="300"> <p> <input value="Back to Agent" onclick="javascript:location='HtmlAdaptor?action=displayMBeans'" type="button"> <input value="Back to MBean" onclick="javascript:location='HtmlAdaptor?action=inspectMBean&name=jboss.cache%253Aservice%253DCache%252Cconfig%253Dsfsb-cache'" type="button"> </p> <p> <input onclick="location='HtmlAdaptor?action=invokeOpByName&name=jboss.cache%253Aservice%253DCache%252Cconfig%253Dsfsb-cache&methodName=printCacheDetailsAsHtml'" value="Reinvoke MBean Operation" type="button"> </p> </td> </tr> </tbody></table> <pre>/  {}<br >  /sfsb  {}<br >    /jar=acme-haejb3.jar,name=BankAccountBean,service=EJB3  {}<br >      /78  {}<br >    /jar=acme-haejb3.jar,name=ShoppingCartBean,service=EJB3  {}<br >      /79  {}<br > </br ></br ></br ></br ></br ></br ></pre> </body></html> -- 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, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1451) Read Time Out for TcpDelegatingCacheLoader

by J B (JIRA)

Read Time Out for TcpDelegatingCacheLoader ------------------------------------------ Key: JBCACHE-1451 URL: https://jira.jboss.org/jira/browse/JBCACHE-1451 Project: JBoss Cache Issue Type: Patch Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 2.1.1.GA Reporter: J B Assignee: Manik Surtani Priority: Trivial Currently there is no way to set the SO_TIMEOUT on the socket used in TcpDelegatingCacheLoader, this means that it can block forever on the read when asking for remote data from the TcpCacheServer. Users should be able to configure a timeout on whether they want to block forever or not. -- 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, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1444) ObjectName's validation fails for Jbosscache 3.0 on WAS 6.1 due to ":" char in name.

by Peter Kovgan (JIRA)

ObjectName's validation fails for Jbosscache 3.0 on WAS 6.1 due to ":" char in name. ------------------------------------------------------------------------------------ Key: JBCACHE-1444 URL: https://jira.jboss.org/jira/browse/JBCACHE-1444 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: 3.0.0.CR3 Environment: WAS 6.1, IBM VM Reporter: Peter Kovgan Assignee: Manik Surtani I deploy jboss cache on WAS 6.1(base install), and the problem is: new JmxRegistrationManager uses this function to create unique object name: private void processBaseName(ObjectName baseName) in LOCAL mode, name is objectNameBase = LOCAL_CACHE_PREFIX + Thread.currentThread().getName() + "-" + System.currentTimeMillis(); the problem WAS returns <ContainerName>:<some number> as a Thread.currentThread().getName(). This means you have something like WebContainer : 1 in name, but the ":" char fails during the validation in WAS's proprietary(!!!) javax.management.ObjectName.class. Probably needed some configurable option that excludes ":" Thread.currentThread().getName() - problem part - should be changed for WAS to exclude ":" below is WAS check for invalid characters: while ((in_index < len) && ((c1 = name_chars[in_index++]) != '=')) switch (c1) { // '=' considered to introduce value part case '*' : case '?' : case ',' : case ':' : case '\n' : final String ichar = ((c1=='\n')?"\\n":""+c1); throw new MalformedObjectNameException( "Invalid character '" + ichar + "' in key part of property"); default: ; } -- 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, 11 months

3
13
0 / 0

[JBoss JIRA] Assigned: (JBCACHE-816) Clustering between data centres

by Galder Zamarreno (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-816?page=com.atlassian.jira.pl... ] Galder Zamarreno reassigned JBCACHE-816: ---------------------------------------- Assignee: Galder Zamarreno (was: Manik Surtani) > Clustering between data centres > ------------------------------- > > Key: JBCACHE-816 > URL: https://jira.jboss.org/jira/browse/JBCACHE-816 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 1.4.0.GA, 2.0.0.GA > Reporter: Manik Surtani > Assignee: Galder Zamarreno > Fix For: 3.2.0.GA > > Original Estimate: 3 weeks > Remaining Estimate: 3 weeks > > This has to do with multiple JBoss Cache clusters deployed on LANs as islands, requiring a bridge between such islands. An ideal use case is where a cluster spans multiple data centres and would need to replicate across a WAN. > The ideal strategy would be to allow for async bridging, since most calls would be colocated to a single LAN, but may fail over to a remote LAN (pretty much the same idea of async repl within a LAN, except that now we treat an entire LAN as a host. Sort of a meta-cluster). > For more details and some brainstorming ideas, see: > http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheAcrossDataCentres -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1455) Rollback corrupts nodes loaded from cache loader

by Krzysztof Sobolewski (JIRA)

Rollback corrupts nodes loaded from cache loader ------------------------------------------------ Key: JBCACHE-1455 URL: https://jira.jboss.org/jira/browse/JBCACHE-1455 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders, Transactions Affects Versions: 3.0.2.CR1, 2.2.1.CR1 Reporter: Krzysztof Sobolewski Assignee: Manik Surtani The scenario is simple: when a node is evicted and needs to be (and is) loaded from cache loader, a subsequent transaction rollback does something bad to this node's parent node. The node can still be retrieved by directly referencing its FQN, but the parent "forgets" about it and does not return it in its list of children, as illustrated in the attached test case(s) (in versions for 2.2 and 3.0). -- 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, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1452) JDBCCacheLoader Doesn't Work With Sybase

by Jimmy Wilson (JIRA)

JDBCCacheLoader Doesn't Work With Sybase ---------------------------------------- Key: JBCACHE-1452 URL: https://jira.jboss.org/jira/browse/JBCACHE-1452 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.1.SP9 Reporter: Jimmy Wilson Assignee: Jimmy Wilson Fix For: 1.4.X The JDBCCacheLoader implementation doesn't work with Sybase because it tries to set a null BLOB column and Sybase doesn't support BLOBs. -- 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, 11 months

2
8
0 / 0

[JBoss JIRA] Created: (JBCACHE-1456) The root node starts with "children loaded" flag

by Krzysztof Sobolewski (JIRA)

The root node starts with "children loaded" flag ------------------------------------------------ Key: JBCACHE-1456 URL: https://jira.jboss.org/jira/browse/JBCACHE-1456 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.0.2.CR1, 2.2.1.CR1 Reporter: Krzysztof Sobolewski Assignee: Manik Surtani Attachments: RootChildrenLoadedTest_2_2.java, RootChildrenLoadedTest_3_0.java The root node starts with "children loaded" flag. This causes problems when all the data is in cache loader and the cache starts empty - in this case it refuses to load its children for the getChildren() call. The subnodes can be correctly addressed directly and the list of children is updated accordingly then. The eviction of root node correctly sets the "children loaded" flag to false. Other nodes, than the root, are anaffected. This is, of course, without preloading anything, but with "fetch persistent state" flag on (or off, doesn't matter here). There is a simple workaround, namely casting the root node to NodeInvocationDelegate and tweaking this flag directly, but I'm not sure if this is proper solution, even if it works for anything I'm doing. -- 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, 11 months

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues January 2009