July 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1229) Use ProtocolStackConfigurator to edit the JGroups configuration instead of regular expressions

by Dan Berindei (JIRA)

Use ProtocolStackConfigurator to edit the JGroups configuration instead of regular expressions ---------------------------------------------------------------------------------------------- Key: ISPN-1229 URL: https://issues.jboss.org/browse/ISPN-1229 Project: Infinispan Issue Type: Enhancement Components: Test Suite Affects Versions: 5.0.0.CR7 Reporter: Dan Berindei Assignee: Manik Surtani Priority: Minor Fix For: 5.1.0.Final JGroupsConfigBuilder uses regular expressions to modify the JGroups protocol configuration, it should use the JGroups programmatic configuration support instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
6
0 / 0

[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

13 years, 3 months

3
3
0 / 0

[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

13 years, 3 months

5
7
0 / 0

[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

13 years, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-1218) warning about IndexWorkFlushEventListener should not be logged

by Sanne Grinovero (JIRA)

warning about IndexWorkFlushEventListener should not be logged -------------------------------------------------------------- Key: ISPN-1218 URL: https://issues.jboss.org/browse/ISPN-1218 Project: Infinispan Issue Type: Bug Components: Querying Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Optional The following warning is logged by the Query engine, but it doesn't actually apply to Query: {quote}[org.hibernate.search.backend.impl.TransactionalWorker] It appears changes are being pushed to the index out of a transaction. Register the IndexWorkFlushEventListener listener on flush to correctly manage Collections!{quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
3
0 / 0

[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

13 years, 3 months

3
32
0 / 0

[JBoss JIRA] Created: (ISPN-575) Corruption in data when using a permanent store between stop-start cycles

by Sanne Grinovero (JIRA)

Corruption in data when using a permanent store between stop-start cycles ------------------------------------------------------------------------- Key: ISPN-575 URL: https://jira.jboss.org/browse/ISPN-575 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.1.0.CR2 Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 4.1.0.Final We verified the issue while using the Lucene Directory; using the Directory under stress leads to no issues even during long running tests of several hours. If during the same stress test a permanent store is enabled, all works still fine, until the CacheManager is stopped. No errors during the stop(), but after starting it again the checksum on some data fails and the index is unusable. -- 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 months

4
19
0 / 0

[JBoss JIRA] Created: (ISPN-230) Enable JNDI binding of Cache/CacheManager out of the box

by Galder Zamarreno (JIRA)

Enable JNDI binding of Cache/CacheManager out of the box -------------------------------------------------------- Key: ISPN-230 URL: https://jira.jboss.org/jira/browse/ISPN-230 Project: Infinispan Issue Type: Feature Request Reporter: Galder Zamarreno Priority: Minor Fix For: 4.1.0.BETA1 Note that implementing this has no urgency since it does not really help Brian S for the JBoss AS integration. See: http://lists.jboss.org/pipermail/infinispan-dev/2009-October/001663.html So, I'm thinking that we could have a <jndi name="xyz"/> configuration option both at the global level (for Cache Manager) and at the Cache level. So, - if <jndi/> was present in the global section, we'd bind CacheManager to java:CacheManager - if <jndi name="xyz"/> was present in the global section, we'd bind CacheManager to java:xyz - if <jndi/> was present in the cache section, we'd bind Cache to java:<name-of-the-cache> - if <jndi name="xyz"/> was present in the cache section, we'd bind Cache to java:xyz -- 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 months

3
3
0 / 0

[JBoss JIRA] Created: (ISPN-231) Replace use of ScheduledThreadPoolExecutor if affected by contention

by Galder Zamarreno (JIRA)

Replace use of ScheduledThreadPoolExecutor if affected by contention -------------------------------------------------------------------- Key: ISPN-231 URL: https://jira.jboss.org/jira/browse/ISPN-231 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreno Assignee: Galder Zamarreno Priority: Minor Fix For: 4.1.0.BETA1 Verify whether JGRP-1051 affects Infinispan. -- 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 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-1205) Redesign marshallers to be per named cache instance, per thread

by Pete Muir (JIRA)

Redesign marshallers to be per named cache instance, per thread --------------------------------------------------------------- Key: ISPN-1205 URL: https://issues.jboss.org/browse/ISPN-1205 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.0.0.CR6 Reporter: Pete Muir Assignee: Manik Surtani Fix For: 5.1.0.BETA1 Since we have switched to explicit classloaders in Infinispan 5.0, we can now pass the correct classloader to use into JBoss Marshalling, rather than rely on the TCCL. However at the moment marshallers are per thread, not per named cache instance. We will need to change the way marshallers are created to make a marshaller per-thread-per-named-cache-instance. This will also require investigation of the best way of propagating this through the DI system. Dan has previously suggested using the InvocationContext -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

3
11
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2011