[JBoss JIRA] Created: (ISPN-385) Add idle timeout to memcached and hot rod servers.
by Galder Zamarreno (JIRA)
Add idle timeout to memcached and hot rod servers.
--------------------------------------------------
Key: ISPN-385
URL: https://jira.jboss.org/jira/browse/ISPN-385
Project: Infinispan
Issue Type: Task
Components: Cache Server
Reporter: Galder Zamarreno
Assignee: Galder Zamarreno
Fix For: 4.1.0.BETA1
Add an IdleStateHandler to memcached and hot rod servers so that idle connections can be closed automatically. This is necessary to handle error conditions such as cases where clients erroneously indicate the server that it needs to read 20 bytes but they only send 10 bytes. Without such handler, the server will carry on waiting for bytes forever. The handler will provide a defence mechanism for such cases.
The timeout will be configurable via the command line. Besides, clients wanting to do some connection pooling will require to configure this accordingly in the server. In other words, there's hardly any point in having servers configured with idle timeout of 30 seconds and clients closing connections after 60 seconds of idle time. These two should be aligned accordingly.
--
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
[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
[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