June 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-219) More sophisticated discovery of Infinispan instances from JOPR agent

by Galder Zamarreno (JIRA)

More sophisticated discovery of Infinispan instances from JOPR agent -------------------------------------------------------------------- Key: ISPN-219 URL: https://jira.jboss.org/jira/browse/ISPN-219 Project: Infinispan Issue Type: Task Components: JMX, reporting and management Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.CR1 Currently, JOPR agent to Infinispan discovery is hardcoded to localhost. This needs further sophistication as indicated in: Oct 01 10:39:25 <galderz> pilhuhn, one question Oct 01 10:39:40 <galderz> the <plugin-configuration>, who uses it? Oct 01 10:40:05 <pilhuhn> that is used to pass in connection properties Oct 01 10:40:15 <galderz> to who? Oct 01 10:40:27 <galderz> to the jopr plugin itself? Oct 01 10:40:42 <pilhuhn> So in the ispn case, the remote jnp url would go int there , yes the plugin itself Oct 01 10:40:56 <pilhuhn> in the plugin DiscoveryCOmponent you e.g. do Oct 01 10:41:01 <galderz> right, so that currently is not in use at all, correct? Oct 01 10:41:07 <pilhuhn> yes Oct 01 10:41:23 <pilhuhn> Configuration c = resourceDiscoveryContext.getConfiguration(); Oct 01 10:41:49 <galderz> and what's c:template about? Oct 01 10:42:04 <pilhuhn> String jnp Url = c.getSimpleProperty("xxx", "jmx:servive......"); with xxx being the property name from the deployment descirptor Oct 01 10:42:23 <pilhuhn> c:template allows you to provide tempates for the values a user can enter Oct 01 10:44:12 <pilhuhn> have a look at http://viewvc.rhq-project.org/cgi-bin/viewvc.cgi/rhq/trunk/modules/plugin... Oct 01 10:44:27 <galderz> so, let me get one thing straight Oct 01 10:44:43 <galderz> does it make sense to have anything other than localhost in the connectorAddress? Oct 01 10:44:56 <pilhuhn> There are 2 templates for Twitter and identi.ca that pre-fill the basic connection properties for that plugin to connect to the remote services Oct 01 10:45:07 <galderz> at the end of the day, can u assume the plugin will always be local to the infinispan instance? Oct 01 10:45:44 <pilhuhn> This depends on your usage. If you want an agent on all nodes with ispn on, then you can assume localhost Oct 01 10:46:02 <galderz> well, we have to make a choice Oct 01 10:46:11 <galderz> or rethink this cos either Oct 01 10:46:19 <pilhuhn> if you say that you only want one agent for e.g. 10 ispn nodes, then not :-> Oct 01 10:46:21 <galderz> the rhq-plugin.xml is generated at build it Oct 01 10:46:59 <galderz> i think that at least Oct 01 10:47:17 <pilhuhn> A plugin can support manual-add and autodiscovery. Meaning that you can autodiscover ispn on the localhost and stil have a user manually add an instance on a remote host - here he has to provide the correct connection properties Oct 01 10:47:19 <galderz> that the port and host need to have a ${:} format Oct 01 10:47:54 <galderz> so that at least, when u start the agent, u can pass (optionally) the location of the infinispan instance Oct 01 10:48:04 <pilhuhn> That is done via c.getSimpleProperty(propertyName, defaultValue) in the plugin code Oct 01 10:48:28 <pilhuhn> but yes, you could do it your way too Oct 01 10:48:48 <galderz> hmmm, not sure if I like default values in code rather than in xml Oct 01 10:49:05 <galderz> but let me have a think about it Oct 01 10:49:33 <galderz> so, to get this right Oct 01 10:49:42 <galderz> how do u call up on the default template? Oct 01 10:49:58 <galderz> iow, how do I get the default template values? Oct 01 10:50:25 <pilhuhn> hm. dunno if you can get them. Oct 01 10:50:40 <pilhuhn> stop Oct 01 10:50:44 <pilhuhn> let me rephrase Oct 01 10:51:34 <pilhuhn> IIrc you get this just passed in (the default values you specify in plugin-xml) when you call c.getSimpleProperty(); Oct 01 10:54:22 <galderz> another question, how can an agent connect to multiple infinispan instances? Oct 01 10:54:27 <galderz> each in different host and port? Oct 01 10:55:00 <pilhuhn> yes Oct 01 10:55:06 <galderz> how? Oct 01 10:55:19 <pilhuhn> You just need one resource in inventory per ispn instance Oct 01 10:55:40 <galderz> but the agent, how does it connect to each? Oct 01 10:55:49 <galderz> the agent has a single connectorAddress Oct 01 10:56:05 <galderz> so how on earth does it discover several instances in diff nodes? Oct 01 10:57:22 <pilhuhn> you could in the Discovery component e.g. sweep a whole subnet. Just do a loop for each IP, and if an ispn instance is found, create one DiscoveredResourceDetails object per instance found and return all of those instances Oct 01 10:58:25 <pilhuhn> or you could, if you have found one, (require one to start at localhost) ask this ispn instance for connection data of other instances in the grid and then create the DiscoveredResourceDetails objects for all of those Oct 01 10:58:28 <galderz> right, so the connector address is no longer a simple property Oct 01 10:58:38 <galderz> but makes sense to implement it as a list property Oct 01 10:58:45 <pilhuhn> no Oct 01 10:59:13 <pilhuhn> each resource runs in a separate context. per resource we instantiate one IspnComponent class Oct 01 10:59:32 <pilhuhn> with its own set of values for the plugin config Oct 01 10:59:49 <galderz> i don't get this Oct 01 10:59:57 <galderz> the plugin runs in an agent Oct 01 11:00:01 <galderz> that executes the discoveru Oct 01 11:00:05 <pilhuhn> yes Oct 01 11:00:13 <galderz> how do u past a list of ispn isstance urls to that plugin? Oct 01 11:00:20 <galderz> so that discovery can act on each of them? Oct 01 11:00:34 <pilhuhn> ah ok, yes that could be done via list Oct 01 11:00:37 <galderz> i.e. node1:6996, node2:6996...etc Oct 01 11:00:43 <pilhuhn> But then the user needs to provide the list Oct 01 11:00:59 <galderz> via a sys property Oct 01 11:01:14 <pilhuhn> what I was thinking is that you require 1 ispn instance on the host, the agent runs on. Oct 01 11:01:15 <galderz> it's not uncommon to have properties that act either as single value or lists Oct 01 11:02:01 <galderz> i..e tcpping host names Oct 01 11:02:09 <galderz> the possibilities are varios here, i agree Oct 01 11:02:17 <pilhuhn> ispn should know its topology? Oct 01 11:02:30 <galderz> ispn knows about the cluster Oct 01 11:02:37 <galderz> but an agent could be managing diff clusters Oct 01 11:02:40 <galderz> that don't talk to each other Oct 01 11:03:02 <galderz> anyway, this requires further thought Oct 01 11:03:22 <galderz> the easiest way is simply: 1 agent, 1 ispn instance Oct 01 11:03:38 <pilhuhn> yes Oct 01 11:04:00 <galderz> i'll suggest diff solutions in the list and see which ones make most sense to implement before GA -- 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

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-573) Allow LAN RPCs to be SYNC while WAN RPCs to be ASYNC

by Manik Surtani (JIRA)

Allow LAN RPCs to be SYNC while WAN RPCs to be ASYNC ---------------------------------------------------- Key: ISPN-573 URL: https://jira.jboss.org/browse/ISPN-573 Project: Infinispan Issue Type: Feature Request Components: RPC Affects Versions: 4.1.0.CR2 Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.Final This will allow for interesting WAN architectures where RPC messages to members within the same LAN would be sent synchronously and RPC messages to remote members across a WAN to be sent asynchronously. This will allow for a cluster to span 2 data centres, (configured using TCP, for example), while allowing for *some* backups to be in the same data centre while others reside in a remote data centre. >From an email thread: "So even if you have 4 owners, 2 in each DC, the "local" replication, there will be no way to write to the local backup synchronously and the remote backups asynchronously. I.e., either all comms are sync or all comms are async. Maybe this is something we can add in Infinispan. I.e., with node hints (https://jira.jboss.org/browse/ISPN-180) (*) we could detect which recipients are local and which are remote, and accordingly split the RPC into 2: a sync local RPC and an async remote RPC. (*) Node hinting isn't strictly necessary; the naming convention you mentioned earlier would work in this regard as well, although I think these hints is probably a better universal solution since we need this for other things anyway." -- 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, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-129) Ability to manage cluster-wide configuration via a central management console

by Manik Surtani (JIRA)

Ability to manage cluster-wide configuration via a central management console ----------------------------------------------------------------------------- Key: ISPN-129 URL: https://jira.jboss.org/jira/browse/ISPN-129 Project: Infinispan Issue Type: Feature Request Components: JMX, reporting and management Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.GA Perhaps a lightweight form of JBoss AS' profile service, or something similar. -- 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
2
0 / 0

[JBoss JIRA] Created: (ISPN-127) Ability to bring up/take down nodes based on SLAs

by Manik Surtani (JIRA)

Ability to bring up/take down nodes based on SLAs ------------------------------------------------- Key: ISPN-127 URL: https://jira.jboss.org/jira/browse/ISPN-127 Project: Infinispan Issue Type: Feature Request Components: JMX and reporting Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.GA Need to look at what JOPR can provide by way of bringing up or killing instances based on overall load. Perhaps other metrics such as time of day could be used as well. Would be very useful to help build out a truly 'elastic' data grid. -- 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-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] Updated: (ISPN-58) Create a TaskQueueExecutorFactory and TaskQueueScheduledExecutorFactory

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-58?page=com.atlassian.jira.plugin.sy... ] Manik Surtani updated ISPN-58: ------------------------------ Fix Version/s: 6.0.0.Final (was: 5.1.0.BETA1) (was: 5.1.0.Final) > Create a TaskQueueExecutorFactory and TaskQueueScheduledExecutorFactory > ----------------------------------------------------------------------- > > Key: ISPN-58 > URL: https://issues.jboss.org/browse/ISPN-58 > Project: Infinispan > Issue Type: Sub-task > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 6.0.0.Final > > > These executors will not spawn separate threads, but hook in to Google's TaskQueue API > http://code.google.com/appengine/docs/java/taskqueue/overview.html > This will enable Infinispan to run without spawning any additional threads, thereby enabling it to run on Google's App Engine runtime. > Will need to expose a URI (/taskqueueexecutor ?) which is invoked to process arbitrary Callable/Runnables. May need to use the DataStore to store the actual Callable/Runnable, and pass the taskqueueexecutor the key of the stored object. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-57) Support Google App Engine

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-57?page=com.atlassian.jira.plugin.sy... ] Manik Surtani updated ISPN-57: ------------------------------ Fix Version/s: 6.0.0.Final (was: 5.1.0.BETA1) (was: 5.1.0.Final) > Support Google App Engine > ------------------------- > > Key: ISPN-57 > URL: https://issues.jboss.org/browse/ISPN-57 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Reporter: Adrian Cole > Assignee: Manik Surtani > Fix For: 6.0.0.Final > > > Google App Engine for Java is a restricted JVM. It prevents such things as file access and thread creation. Currently, Infinispan requires at least thread creation and depending on the cachestore mechanism, potentially file as well. > This is a container to investigate other related issues that may prevent Infinispan from running on GAE. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-741) Implement Continuous Query on Infinispan

by Mircea Markus (JIRA)

Implement Continuous Query on Infinispan ---------------------------------------- Key: ISPN-741 URL: https://jira.jboss.org/browse/ISPN-741 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.1.0.Final Implement continuous query on infinispan based on the tech preview: http://github.com/mmarkus/infinispan-continuous-query. Documentation on API and functionality: http://community.jboss.org/wiki/ContinuousQuerywithInfinispan -- 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, 10 months

2
2
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-1030) Inform the wider community about Spring INFINISPAN

by Olaf Bergner (JIRA)

Inform the wider community about Spring INFINISPAN -------------------------------------------------- Key: ISPN-1030 URL: https://issues.jboss.org/browse/ISPN-1030 Project: Infinispan Issue Type: Sub-task Reporter: Olaf Bergner Assignee: Manik Surtani We need to tell the community about Spring INFINISPAN, what it is good for, how it is to be used. This should comprise * providing a sample application, * blogging about it and * document it in our wiki. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2011