July 2010 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-126) Management console to graph nodes visually

by Manik Surtani (JIRA)

Management console to graph nodes visually ------------------------------------------ Key: ISPN-126 URL: https://jira.jboss.org/jira/browse/ISPN-126 Project: Infinispan Issue Type: Feature Request Components: JMX and reporting Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.GA This should also include colour coded visuals to report activity, status, health etc. Need to investigate what JOPR can provide here, via the agent. -- 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

12 years, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (ISPN-121) Create a cache store to work with GAE/J's JPA implementation

by Manik Surtani (JIRA)

Create a cache store to work with GAE/J's JPA implementation ------------------------------------------------------------ Key: ISPN-121 URL: https://jira.jboss.org/jira/browse/ISPN-121 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.BETA1, 4.1.0.GA A cache store that could store state on Google AppEngine for Java's JPA backend. -- 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

12 years, 10 months

1
4
0 / 0

[JBoss JIRA] Created: (ISPN-360) create NodeJoined event

by Mircea Markus (JIRA)

create NodeJoined event ----------------------- Key: ISPN-360 URL: https://jira.jboss.org/jira/browse/ISPN-360 Project: Infinispan Issue Type: Feature Request Components: Listeners, State transfer Reporter: Mircea Markus Assignee: Manik Surtani In relation to http://community.jboss.org/message/529547#529547 It's an well known scenario to start a cluster, and only after the ENTIRE cluster is started to start and do work. Right now, we have CacheStarted and ViewChanged notifications. First only tells us that the local node is started but other nodes might still be in the process of starting. Second one tells us that the view has changed, but not that the cluster has started, i.e. the cache might be in the process of rebalancing state etc. A possible solution would be to have an NodeJoined event, that would be called whenever a new node finished joining the cluster. Finished joining means state transfer happened and that node is started. For a possible workaround to this feature see the forum post. -- 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

12 years, 11 months

4
12
0 / 0

[JBoss JIRA] Created: (ISPN-530) Hot Rod client should load balance between different owners for a key

by Galder Zamarreno (JIRA)

Hot Rod client should load balance between different owners for a key --------------------------------------------------------------------- Key: ISPN-530 URL: https://jira.jboss.org/browse/ISPN-530 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Galder Zamarreno Assignee: Mircea Markus Fix For: 5.0.0.BETA1 While doing the demo for JUDCon, I realised that smart routing on the client side always choses the same node for the same key. IOW, assume you have k1 stored in nodes A, B and the cluster is formed of nodes A, B and C. Now, when the client figures out that the owner is A, any further requests on k1 will be sent to A. This has the possibility of overloading A. I think the client should, from the given list of owners of a key, do round robin between them for requests on the same key. -- 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, 11 months

4
6
0 / 0

[JBoss JIRA] Created: (ISPN-380) Be compliant with JBoss AS logging requirements

by Manik Surtani (JIRA)

Be compliant with JBoss AS logging requirements ----------------------------------------------- Key: ISPN-380 URL: https://jira.jboss.org/jira/browse/ISPN-380 Project: Infinispan Issue Type: Feature Request Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR1, 4.1.0.Final This (JBoss internal) document has details of standardised logging formats and codes, to enable easy i18n, etc. in future. https://docspace.corp.redhat.com/docs/DOC-30217 -- 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

13 years

2
16
0 / 0

[JBoss JIRA] Created: (ISPN-559) refactor transaction class hierarchy

by Mircea Markus (JIRA)

refactor transaction class hierarchy ------------------------------------ Key: ISPN-559 URL: https://jira.jboss.org/browse/ISPN-559 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.0.0.Final Actual transactional logic should be implemented in InitiatorTransaction (vs RemoteTransaction) Rename TxXaAdapter should be renamed to TxCoordinator -- 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

13 years

3
7
0 / 0

[JBoss JIRA] Created: (ISPN-471) HotRod client in Python

by Manik Surtani (JIRA)

HotRod client in Python ----------------------- Key: ISPN-471 URL: https://jira.jboss.org/browse/ISPN-471 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 C++ 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

13 years

1
6
0 / 0

[JBoss JIRA] Created: (ISPN-221) Parse JPA-QL like DSL to generate Lucene Query objects for searching

by Manik Surtani (JIRA)

Parse JPA-QL like DSL to generate Lucene Query objects for searching -------------------------------------------------------------------- Key: ISPN-221 URL: https://jira.jboss.org/jira/browse/ISPN-221 Project: Infinispan Issue Type: Feature Request Components: Querying Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.BETA1, 5.0.0.GA This will allow people to use JPA-QL to build queries rather than Lucene query objects. Will probably use an Antlr grammar, possibly reuse stuff from Hibernate? -- 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

13 years

4
17
0 / 0

[JBoss JIRA] Created: (ISPN-194) Finalise Query API based on tech preview in 4.0.0

by Manik Surtani (JIRA)

Finalise Query API based on tech preview in 4.0.0 ------------------------------------------------- Key: ISPN-194 URL: https://jira.jboss.org/jira/browse/ISPN-194 Project: Infinispan Issue Type: Feature Request Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.BETA1, 4.1.0.GA See ISPN-32 which is a tech preview of the query API. In addition to the dependencies set out in this JIRA, there is also a dependency on http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-397 -- 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

13 years

3
11
0 / 0

[JBoss JIRA] Created: (ISPN-256) Enable Infinispan SPIs to implement their own commands

by Galder Zamarreno (JIRA)

Enable Infinispan SPIs to implement their own commands ------------------------------------------------------ Key: ISPN-256 URL: https://jira.jboss.org/jira/browse/ISPN-256 Project: Infinispan Issue Type: Feature Request Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Much nicer IMHO would be a nice SPI / plug point to allow applications to extend the set of commands. Let an app create an ExtensionCommand; if that comes in off the channel pass it off to the handler the application registered. This could for example be used instead of the solution currently used in http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818. In HHH-3818, the cache is used as a notification vehicle which is a bit of a hack and has some limitations for example when trying to implement a similar solution for evict(key) op. Another use case for it would be HTTP session ownership, from Brian Stansberry: (09:32:09 AM) brian_stansberry: ... it's just that only 1 server at a time s/b able to use a session (09:32:25 AM) brian_stansberry: so on failover i send an extension command requesting ownership (09:33:19 AM) brian_stansberry: there's actually a servlet spec requirement that only one server at a time access a session (09:33:23 AM) brian_stansberry: ejb spec too (09:33:37 AM) brian_stansberry: we don't properly handle that ... (09:34:18 AM) brian_stansberry: basically it's a lock ... (09:34:35 AM) brian_stansberry: that's all it is, a distributed lock (09:35:03 AM) brian_stansberry: but once you have the distributed lock it's yours until you give it up (09:35:29 AM) brian_stansberry: so once 1 request acquires it, subsequent requests to same server can just use a local lock ... (09:41:59 AM) brian_stansberry: the key thing is there should only be a cluster-wide operation once per session (09:42:11 AM) brian_stansberry: unless there is failover -- 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

13 years, 1 month

4
13
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2010