May 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1337) Infinispan query module: searchManagerImpl.extractType() throws exception on some OS.

by JaeHee Roh (JIRA)

Infinispan query module: searchManagerImpl.extractType() throws exception on some OS. ------------------------------------------------------------------------------------- Key: ISPN-1337 URL: https://issues.jboss.org/browse/ISPN-1337 Project: Infinispan Issue Type: Bug Components: Querying Affects Versions: 5.0.0.FINAL Environment: JAVA java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) OS # uname -ovr 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 GNU/Linux Tested with Infinispan 5.0.0.FINAL and 5.0.0.CR8. Both versions failed on this Ubuntu platform. However, it is ok on Suse platform. # uname -ovr 2.6.16.60-0.85.1-smp #1 SMP Thu Mar 17 11:45:06 UTC 2011 GNU/Linux Reporter: JaeHee Roh Assignee: Manik Surtani Priority: Critical This is a same problem as https://issues.jboss.org/browse/ISPN-1232 which fixed in 5.0.0.CR8 and 5.0.0.FINAL but it seems that fix is working on some OS but not all of OS. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-1141) BigMemory Direct buffer

by Magnus Magnus (JIRA)

BigMemory Direct buffer ----------------------- Key: ISPN-1141 URL: https://issues.jboss.org/browse/ISPN-1141 Project: Infinispan Issue Type: Enhancement Components: Distributed Cache Reporter: Magnus Magnus Assignee: Manik Surtani It should be configurable if data stored by NIO buffer or not. It means data stored outside of java heap. Create, destroy in the external memory should be managed by infinispan. With this solution gc can run fast however infinispan node can handle huge amount of memory. In the current case the optional size of the java memory of a node is smaller or equals than 4GB because of garbage collection issues above 4GB. See a similar thing in EHCache BigMemory. http://www.snoopal.com/documents/GaSovOTchHCsOF5X7bG691/-Scale-over-the-l... 12nd page -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

5
8
0 / 0

[JBoss JIRA] Created: (ISPN-469) HotRod client in .NET

by Manik Surtani (JIRA)

HotRod client in .NET --------------------- Key: ISPN-469 URL: https://jira.jboss.org/browse/ISPN-469 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.BETA1, 5.0.0.Final .NET client impl for HotRod. Protocol is documented here: http://community.jboss.org/wiki/HotRodProtocol Could be based off the Java reference impl client: http://fisheye.jboss.org/browse/Infinispan/trunk/client/hotrod-client -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-557) support for same transaction touching multiple nodes (multiple VMs)

by Mircea Markus (JIRA)

support for same transaction touching multiple nodes (multiple VMs) -------------------------------------------------------------------- Key: ISPN-557 URL: https://jira.jboss.org/browse/ISPN-557 Project: Infinispan Issue Type: Feature Request Components: Transactions Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.1.0.Final E.g. if a distributed transaction managers touches two embedded Infinispan nodes within the same transaction. Could be implemented using the Hot Rod client approach - but in an embedded fashion! EmbeddedClient <-- implements logic above Except comms are in-VM for local entries And via RpcDispatcher for remote entries RemoteClient extends EmbeddedClient Adds proper HotRod layer for comms Including failover, smart routing, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
6
0 / 0

[JBoss JIRA] Created: (ISPN-1090) Hot Rod protocol improvements for version 2

by Galder Zamarreño (JIRA)

Hot Rod protocol improvements for version 2 ------------------------------------------- Key: ISPN-1090 URL: https://issues.jboss.org/browse/ISPN-1090 Project: Infinispan Issue Type: Enhancement Components: Cache Server Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.BETA1, 5.1.0.Final This JIRA will act as a place to keep track of enhancements to the Hot Rod protocol that should be included in version 2 of the protocol: - We need a new error status code so that clients can detect when a node has been suspected and so react accordingly (i.e. not bubble it up but instead failover). Currently, this can be solved by checking whether the error message contains SuspectException but this is not nice. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

6
18
0 / 0

[JBoss JIRA] Created: (ISPN-848) Enhance HotRod to allow explicit locking of keys

by Erik Salter (JIRA)

Enhance HotRod to allow explicit locking of keys ------------------------------------------------ Key: ISPN-848 URL: https://issues.jboss.org/browse/ISPN-848 Project: Infinispan Issue Type: Feature Request Reporter: Erik Salter Assignee: Manik Surtani Hot Rod clients should allow explicit locking of keys, especially useful for the "find-for-update" design pattern. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

4
6
0 / 0

[JBoss JIRA] (ISPN-1457) replay prepare if it fails

by Mircea Markus (Created) (JIRA)

replay prepare if it fails -------------------------- Key: ISPN-1457 URL: https://issues.jboss.org/browse/ISPN-1457 Project: Infinispan Issue Type: Enhancement Components: Transactions Affects Versions: 5.0.0.FINAL Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.1.0.FINAL Attachments: AbstractCrashTest.java If the prepare fails for whatever reasons the system should automatically try to replay it - the user code would do the same thing. UT for checking that this is implemented is attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

4
6
0 / 0

[JBoss JIRA] (ISPN-1539) Optimisation: reduce the number of RPCs when L1 is enabled (default)

by Mircea Markus (Created) (JIRA)

Optimisation: reduce the number of RPCs when L1 is enabled (default) -------------------------------------------------------------------- Key: ISPN-1539 URL: https://issues.jboss.org/browse/ISPN-1539 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.0.1.FINAL Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.1.0.CR1 cache.put(k,v) does a remote get(1st RPC) and an put(2nd RPC) to the same remote node. This can be merged into a single RPC. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
2
0 / 0

[JBoss JIRA] (ISPN-1543) Split CacheImpl into TransactionalCache and NonTransactionalCache

by Mircea Markus (Created) (JIRA)

Split CacheImpl into TransactionalCache and NonTransactionalCache ------------------------------------------------------------------ Key: ISPN-1543 URL: https://issues.jboss.org/browse/ISPN-1543 Project: Infinispan Issue Type: Feature Request Components: Core API Affects Versions: 5.1.0.BETA4 Reporter: Mircea Markus Assignee: Mircea Markus Priority: Minor Fix For: 5.1.0.FINAL There is a lot of unnecessary complexity in CacheImpl caused by handling two types of caches: transactional and non-transactional. This code (and potentially InvocationContextContainer) can be simplified a lot by splitting the logic into two cache implementations: TransactionalCache and NonTransactionalCache. The common logic would be moved in an AbstractCache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
2
0 / 0

[JBoss JIRA] (ISPN-1988) coalesce same key writes within a transaction

by Mircea Markus (JIRA)

Mircea Markus created ISPN-1988: ----------------------------------- Summary: coalesce same key writes within a transaction Key: ISPN-1988 URL: https://issues.jboss.org/browse/ISPN-1988 Project: Infinispan Issue Type: Feature Request Components: Transactions Affects Versions: 5.1.4.FINAL Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.2.0.FINAL Following code run with optimistic caches: start tx put k, v1 put k, v2 put k, v3 commit Would cause the PrepareCommand that is sent around to contain 3 PutKeyvalueCommands which is sub-optimal. What we can do is to only send the last written value (i.e. k v3) and ignore the previous two (reuse the code in AsyncCacheStore). Besides reducing the payload, from this would benefit the AtomicHashMaps which uses this code quite a lot and also the OptimisticLockingInterceptor which would not attempt to order the keys. I guess this should be a feature that is disabled by default, as I don't think it is required in general. Might as well be not configurable, enabled by default feature. Comments? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2012