[JBoss JIRA] Created: (ISPN-448) Consider all topology cache updates to be done by coordinator in Hot Rod
by Galder Zamarreno (JIRA)
Consider all topology cache updates to be done by coordinator in Hot Rod
------------------------------------------------------------------------
Key: ISPN-448
URL: https://jira.jboss.org/browse/ISPN-448
Project: Infinispan
Issue Type: Task
Components: Cache Server
Reporter: Galder Zamarreno
Assignee: Galder Zamarreno
Fix For: 5.0.0.BETA1
Based on the discussion below, consider all topology cache updates to be done by coordinator to avoid concurrency issues when updating it.
> Looks good.
> What is causing this unsuccessful add? If it is caused by timeouts due
> to multiple caches operating on the same key an alternative would be
> to only perform the operation on the coordinator and rest of the
> members to have node added listeners ...
Currently, each node when it starts, it's responsible of adding itself to the view and when it stops, it's responsible from removing itself. Apart from this, there's a crashed member listener running only in coordinator that detects whether any member left without updating the topology view. Your suggestion to have the coordinator control it all seems like could work and get around potential timeouts.
I'll create a JIRA to investigate this but won't do it for CR1 since I'm expect this to be a major issue. Metadata size is small and it's not constantly uddated.
--
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, 7 months
[JBoss JIRA] Created: (ISPN-1194) Consolidate rehash and replication state retrieval code
by Manik Surtani (JIRA)
Consolidate rehash and replication state retrieval code
-------------------------------------------------------
Key: ISPN-1194
URL: https://issues.jboss.org/browse/ISPN-1194
Project: Infinispan
Issue Type: Feature Request
Components: Distributed Cache, State transfer
Affects Versions: 5.0.0.FINAL
Reporter: Manik Surtani
Assignee: Dan Berindei
Priority: Blocker
Fix For: 5.1.0.BETA1, 5.1.0.Final
As discussed. Abstract the actual code that handles moving of state so that it can be used both for rehashing as well as state transfer for replicated caches, thereby removing dependence on JGroups' FLUSH and partial state transfer.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] Created: (ISPN-302) Enable templated values for manually adding instances via jopr
by Galder Zamarreno (JIRA)
Enable templated values for manually adding instances via jopr
--------------------------------------------------------------
Key: ISPN-302
URL: https://jira.jboss.org/jira/browse/ISPN-302
Project: Infinispan
Issue Type: Feature Request
Components: JMX, reporting and management
Reporter: Galder Zamarreno
Assignee: Galder Zamarreno
Fix For: 4.1.0.BETA1
Enable templated values for manually adding instances via jopr
>> For manually importing - you should in the plugin descriptor put the JMX-remoting url as
>> >> default -- perhaps with the port as XXX, so the user does not have to copy& paste from an
>> >> external location, but only click in the text field and replace XXX by the real port.
>> >> same for Objectname of the cache manager.
> >
> > I did that. I told you it did not work and your reply was that it was fragile and you didn't looked into it further...
You / we were talking about c:template - which would allow to have several templates -- see jmx-plugin
e.g http://git.fedorahosted.org/git/rhq/rht.git?p=rhq/rhq.git;a=blob;f=module...
from line 47 on
What you can do, an which works is
<c:simple-property name="v1Community" type="string" default="public"/>
Here the default value 'public' is shown to the user for this property.
Sorry that I was confusing things
Heiko
--
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, 7 months
[JBoss JIRA] Created: (ISPN-1084) support optimistic locking with ETags and If-Match in rest server
by Michal Linhard (JIRA)
support optimistic locking with ETags and If-Match in rest server
-----------------------------------------------------------------
Key: ISPN-1084
URL: https://issues.jboss.org/browse/ISPN-1084
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Affects Versions: 5.0.0.CR1, 4.2.2.BETA1
Reporter: Michal Linhard
Assignee: Trustin Lee
currently it is not possible to do optimistic locking using the ETag feature in the REST server, because the "If-Match" HTTP header is ignored.
We allow to put a value many times with the same "If-Match" header, but according to the spec:
{quote}
"A request intended to update a resource (e.g., a PUT) MAY include an If-Match header field to signal that the request method MUST NOT be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource. This allows the user to indicate that they do not wish the request to be successful if the resource has been changed without their knowledge. "
{quote}
(copied from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] Created: (ISPN-200) Distributed queries
by Manik Surtani (JIRA)
Distributed queries
-------------------
Key: ISPN-200
URL: https://jira.jboss.org/jira/browse/ISPN-200
Project: Infinispan
Issue Type: Feature Request
Components: Distributed Cache, Querying
Reporter: Manik Surtani
Assignee: Manik Surtani
Fix For: 5.1.0.BETA1, 5.1.0.GA
The holy grail of querying.
* Indexes are _never_ shared.
* Each node maintains local indexes for state it is responsible
for (-Dinfinispan.query.indexLocalOnly=true).
* Indexes could be in memory or disk.
* Queries themselves are distributed.
* The query object is built and broadcast to the entire cluster.
* Each node executes the query on its own _local_ index, returning
results.
* The calling node returns a CacheQuery impl that lazily fetches
and collates results from the cluster.
* I expect this Map/Reduce model to perform very well since the
workload is split up and happens in parallel across multiple CPUs
against much smaller (individual) datasets.
* Works with all cache modes, including DIST.
* Need to make sure duplicates are handled, as well as 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
12 years, 7 months
[JBoss JIRA] Created: (ISPN-813) "Infinispan Cache Manager" option doesn't show up in the drop down menu for "Manually add" function
by Michal Linhard (JIRA)
"Infinispan Cache Manager" option doesn't show up in the drop down menu for "Manually add" function
---------------------------------------------------------------------------------------------------
Key: ISPN-813
URL: https://jira.jboss.org/browse/ISPN-813
Project: Infinispan
Issue Type: Bug
Components: JMX, reporting and management
Affects Versions: 4.2.0.CR2
Reporter: Michal Linhard
Assignee: Manik Surtani
infinispan 4.2.0.CR2
RHQ version: 3.0.0 build number: 59e9341
postgresql 8.4.5
I've setup RHQ with infinispan-jopr-plugin as described here:
http://community.jboss.org/wiki/MonitoringInfinispanwithRHQ
I'm running this on my local machine having these virtual interfaces
192.168.10.101 test1
192.168.10.102 test2
192.168.10.103 test3
192.168.10.104 test4
192.168.10.105 test5
192.168.10.106 test6
test1 - test4 running jboss 5.1.0.GA with infinispan-gridfs-webdav demo (ran with -Dcom.sun.management.jmxremote.port=6991 to 9664 respectively)
test1 - test2 running rhq-agent bound to respective interface
test5 running rhq-server
sucessfully installed RHQ server
sucessfully installed agents test1 test2
sucessfully imported platforms test1 and test2
sucessfully installed infinispan-jopr-plugin, updated agents
tried to manually add Infinispan Cache Manager according to the instructions:
"To add Infinispan instances manually, go to Resources > Platforms > localhost and then click on Inventory. At the bottom of the page, there's a section that says "Manually Add" and next to it there's a drop down list. Open this list, select "Infinispan Cache Manager" and click Ok."
but the option "Infinispan Cache Manager" doesn't appear in the drop down box.
i don't know wheter this is a RHQ bug or plugin bug or wheter there's something wrong with my installation steps.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months