Re: [infinispan-dev] Idle timeout default for Hot Rod servers - ISPN-385
by galder@jboss.org
See below:
----- "Manik Surtani" <manik(a)jboss.org> wrote:
> On 21 Apr 2010, at 11:28, galder(a)redhat.com wrote:
>
> > Hi,
> >
> > As a result of https://jira.jboss.org/jira/browse/ISPN-385, I'm
> adding a new command line parameter to the Hot Rod server that allows
> users to set an idle timeout. The effect of this timeout is that if a
> Hot Rod server has not received any commands from a given connection
> within that timeout, it will close it. The aim of this timeout is to
> battle against clients that might be sending partial or incomplete
> operations. Closing this connections allows for such incorrect ops to
> be discarded.
> >
> > If you pass 0, the idle timeout is disabled. By default, I have set
> the timeout to 1 minute but I wonder whether it's too low, or whether
> 0 would be a better default. The reason I say this is cos partial or
> incomplete operations is more of an edge case than the norm. Once the
> clients have been debugged, this should not be the norm, hence why I'm
> wondering whether 0 would be a better default.
>
> Well, it could be a DOS attack so 0 is not a good default. :)
Hmmm, good point. I'll leave it on 1 minute for the time being.
>
> > Also, any idle timeout settings would need to take in account client
> settings, or viceversa. There's no much point on a client pooling
> connections and setting idle timeout to 2 minutes when the server will
> close idle connections after 1 minute.
>
> Keepalives? Wasn't there a mechanism for clients to ping the server
> to keep a connection alive?
Good point, keep alives would definitely work and would stop the server from
closing the connection.
There's definitely the capability for keep alives, that's why we defined the PING command. I dunno though if Mircea has implemented the keep alive logic.
>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
14 years, 6 months
Bug : read after end of stream @ AbstractMarshaller
by Philippe Van Dyck
Hi all,
since I use an InflaterInputStream to send objects to S3 using JClouds
Blobstore, I need a very strict management of streams.
In AbstractMarshaller, while ((bytesRead = inputStream.read(buf, 0,
buf.length)) != -1) bytes.write(buf, 0, bytesRead) will read after the
stream's end, waiting for '-1' to happen.
You cannot do that with a GZIPInputStream because you will get a
"java.io.EOFException: Unexpected end of ZLIB input stream".
Should I file a bug or correct the code ?
phil
14 years, 6 months
Am I missing something ?
by Philippe Van Dyck
Hi All,
just a quick question.. what could motivate Infinispan to check my store
*each* time I get an entry from the its cache ??
While I was debugging the BlobCacheStore I noticed that all my 'get' endend
up in a decompression of an entry downloaded from S3...
Did I miss somthing in my config ?:
1) jgroups as transport
2) jmx enabled
3) transaction enabled (Atomikos)
4) distribution mode
5) l1 enabled
6) two owners (actually only one alive... does this have an impact ?)
7) no passivation
8) cache is shared
9) cache is no preloaded
10) then the config for the cache store
11) eviction manual (my own)
12) one minute max locking
And *each* time I 'get' something from the cache... it goes to the store.
I must be missing something ;-)
phil
<?xml version="1.0" encoding="UTF-8"?>
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:infinispan:config:4.0">
<global>
<transport
transportClass="org.infinispan.remoting.transport.jgroups.JGroupsTransport">
<properties>
<property name="configurationFile" value="jgroups.xml" />
</properties>
</transport>
<globalJmxStatistics enabled="true" />
</global>
<namedCache name="qi4j">
<jmxStatistics enabled="true" />
<transaction
transactionManagerLookupClass="org.qi4j.entitystore.s3jclouds.AtomikosTransactionManagerLookup"
/>
<clustering mode="distribution">
<l1 enabled="true" lifespan="100000" />
<hash numOwners="2" rehashRpcTimeout="120000" />
</clustering>
<loaders passivation="false" shared="true" preload="false">
<loader
class="org.qi4j.entitystore.s3jclouds.cacheStore.Bzip2CloudCacheStore"
fetchPersistentState="false" ignoreModifications="false"
purgeOnStartup="false" purgeSynchronously="true">
<properties>
<property name="identity" value="nahnah" />
<property name="password" value="nah" />
<property name="bucketPrefix" value="storetest2" />
<property name="cloudService" value="s3" />
</properties>
</loader>
</loaders>
<!--
<deadlockDetection enabled="true"
spinDuration="1000"></deadlockDetection>
-->
<eviction strategy="LRU" wakeUpInterval="-1" maxEntries="1" />
<locking lockAcquisitionTimeout="60000" concurrencyLevel="32" />
<unsafe unreliableReturnValues="true" />
</namedCache>
</infinispan>
14 years, 6 months
Re: [infinispan-dev] Streamed rehashing
by Manik Surtani
Hey dude - sorry for the late response. I'm cc'ing infinispan-dev BTW. Gotta keep the community in the loop! :)
On 15 Apr 2010, at 16:48, Vladimir Blagojevic wrote:
>
> On 2010-04-13, at 11:09 AM, Manik Surtani wrote:
>
>>>
>>> I would register RehashedSTM (an impl of STM) into container under cacheName.append("_REHASH") or whatever other token. RehashedSTM will capture the logic of serializing/deserializing rehashing state.
>>
>> Yeah that would work...
>>
>>> We can have maybe DistManagerImpl implement STM. Not sure though if DistManagerImpl can be registered under multiple names in container....
>>
>> Hmm, that may prove tricky... any particular reason? DMI could just have a reference to a RehashingSTM...
>>
>
> Good progress so far.
>
>
>
> JOIN question:
>
> During join, as is, joiner simply gets synchronous response with a state by sending RehashControlCommand to state producer. Since we are essentially doing a simple channel#getState now we can no longer rely on RehashControlCommand to carry information needed to do a join transfer - namely newCH and joiner. We have to pick up these values from DistributionManagerImpl.
>
> We already have access to both old and new ch on DistributionImpl since we broadcast JOIN_REHASH_START to all nodes. Therefore, we have access to both old and new CH through DistributionImpl.getConsistentHash() which at this moment is UnionConsistentHash. All good!
Cool.
> However, RehashingSTM does not have access to joiner Address since neither DistributionManagerImpl not DistributionManager expose it. And we need joiner to decide if certain cache entry should be included into a state as producer produces state for joiner. Can we expose joiner in DistributionManager? Or is there another clever way to obtain it?
Can this not be sent as a part of the getState request? Or as a part of the streaming protocol? E.g.,
1. getState opens streams between a joiner and various state producers.
2. before state producers start streaming state, they need to wait for the joiner to publish it's address on the stream
> LEAVE question:
>
> I am now looking at push state. I don't think there is another way to accomplish leave but to invert state transfer. Instead of pushing state to receivers, we need to inform all state receiver nodes to initiate state transfer to a certain node. How do you feel about this? A bit of a kludge, no?
Yes, but this is still a logical PUSH since it is initiated by the state sender. :)
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
14 years, 6 months
Re: [infinispan-dev] Getting rid of GZipInputStream
by galder@jboss.org
Hi Philippe,
So, to sum up, trying to fix https://jira.jboss.org/jira/browse/ISPN-133 won't solve your problem, correct? Did you test this out by any chance?
Did you test Bzip2Compressor streams to see if that worked?
Cheers,
----- "philippe van dyck" <pvdyck(a)gmail.com> wrote:
> Hi all,
>
> the problem is in the JDK and linked to a 10 years old -never fixed-
> bug in GZipInputStream...
> I propose to get rid of GZipInputStream and use Apache Commons
> Bzip2Compressor streams in the CloudCacheStore.
>
> (And BTW, using len=inputStream.available() is a very bad idea with
> GZipInputStream...)
>
> WDYT ?
>
> phil
>
> Début du message réexpédié :
>
> > De : Philippe Van Dyck <pvdyck(a)gmail.com>
> > Date : 16 avril 2010 10:45:19 HAEC
> > À : infinispan -Dev List <infinispan-dev(a)lists.jboss.org>
> > Objet : Bug : read after end of stream @ AbstractMarshaller
> >
> > Hi all,
> >
> > since I use an InflaterInputStream to send objects to S3 using
> JClouds Blobstore, I need a very strict management of streams.
> > In AbstractMarshaller, while ((bytesRead = inputStream.read(buf, 0,
> buf.length)) != -1) bytes.write(buf, 0, bytesRead) will read after the
> stream's end, waiting for '-1' to happen.
> > You cannot do that with a GZIPInputStream because you will get a
> "java.io.EOFException: Unexpected end of ZLIB input stream".
> > Should I file a bug or correct the code ?
> >
> > phil
> Début du message réexpédié :
>
> > De : Philippe Van Dyck <pvdyck(a)gmail.com>
> > Date : 16 avril 2010 10:52:22 HAEC
> > À : infinispan -Dev List <infinispan-dev(a)lists.jboss.org>
> > Objet : Réexp : Bug : read after end of stream @ AbstractMarshaller
> >
> > Ok, I took a closer look.
> > Actually, it is related to HTTPCORE-199, and this bug is fixed.
> > What about using int len = inputStream.available(); in
> AbstractMarshaller again ?
> >
> > phil
> >
> > ---------- Forwarded message ----------
> > From: Philippe Van Dyck <pvdyck(a)gmail.com>
> > Date: Fri, Apr 16, 2010 at 10:45 AM
> > Subject: Bug : read after end of stream @ AbstractMarshaller
> > To: infinispan -Dev List <infinispan-dev(a)lists.jboss.org>
> >
> >
> > Hi all,
> >
> > since I use an InflaterInputStream to send objects to S3 using
> JClouds Blobstore, I need a very strict management of streams.
> > In AbstractMarshaller, while ((bytesRead = inputStream.read(buf, 0,
> buf.length)) != -1) bytes.write(buf, 0, bytesRead) will read after the
> stream's end, waiting for '-1' to happen.
> > You cannot do that with a GZIPInputStream because you will get a
> "java.io.EOFException: Unexpected end of ZLIB input stream".
> > Should I file a bug or correct the code ?
> >
> > phil
> >
> Début du message réexpédié :
>
> > De : Philippe Van Dyck <pvdyck(a)gmail.com>
> > Date : 16 avril 2010 11:50:54 HAEC
> > À : infinispan -Dev List <infinispan-dev(a)lists.jboss.org>
> > Objet : Réexp : Bug : read after end of stream @ AbstractMarshaller
> >
> > Ok, JDK Bug
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519463
> >
> > The workaround is to simply ignore (!) the EOFException...
> >
> > WDYT ?
> >
> > phil
> >
> > ---------- Forwarded message ----------
> > From: Philippe Van Dyck <pvdyck(a)gmail.com>
> > Date: Fri, Apr 16, 2010 at 10:52 AM
> > Subject: Fwd: Bug : read after end of stream @ AbstractMarshaller
> > To: infinispan -Dev List <infinispan-dev(a)lists.jboss.org>
> >
> >
> > Ok, I took a closer look.
> > Actually, it is related to HTTPCORE-199, and this bug is fixed.
> > What about using int len = inputStream.available(); in
> AbstractMarshaller again ?
> >
> > phil
> >
> >
> > ---------- Forwarded message ----------
> > From: Philippe Van Dyck <pvdyck(a)gmail.com>
> > Date: Fri, Apr 16, 2010 at 10:45 AM
> > Subject: Bug : read after end of stream @ AbstractMarshaller
> > To: infinispan -Dev List <infinispan-dev(a)lists.jboss.org>
> >
> >
> > Hi all,
> >
> > since I use an InflaterInputStream to send objects to S3 using
> JClouds Blobstore, I need a very strict management of streams.
> > In AbstractMarshaller, while ((bytesRead = inputStream.read(buf, 0,
> buf.length)) != -1) bytes.write(buf, 0, bytesRead) will read after the
> stream's end, waiting for '-1' to happen.
> > You cannot do that with a GZIPInputStream because you will get a
> "java.io.EOFException: Unexpected end of ZLIB input stream".
> > Should I file a bug or correct the code ?
> >
> > phil
> >
> >
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
14 years, 6 months
Idle timeout default for Hot Rod servers - ISPN-385
by galder@redhat.com
Hi,
As a result of https://jira.jboss.org/jira/browse/ISPN-385, I'm adding a new command line parameter to the Hot Rod server that allows users to set an idle timeout. The effect of this timeout is that if a Hot Rod server has not received any commands from a given connection within that timeout, it will close it. The aim of this timeout is to battle against clients that might be sending partial or incomplete operations. Closing this connections allows for such incorrect ops to be discarded.
If you pass 0, the idle timeout is disabled. By default, I have set the timeout to 1 minute but I wonder whether it's too low, or whether 0 would be a better default. The reason I say this is cos partial or incomplete operations is more of an edge case than the norm. Once the clients have been debugged, this should not be the norm, hence why I'm wondering whether 0 would be a better default.
Also, any idle timeout settings would need to take in account client settings, or viceversa. There's no much point on a client pooling connections and setting idle timeout to 2 minutes when the server will close idle connections after 1 minute.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 6 months
HotRod, ClientIntelligence and client-side key location
by Manik Surtani
I've been thinking about how we handle this, and I think we have a problem with smart clients where clients have the ability to locate the key on the server cluster in order to direct the request to the specific node.
The problem is in hash code calculation. The HotRod protocol caters for this with regards to calculating node address hash code by passing this in the topology map (see "Hasher Client Topology Change Header" in [1]), but the only way this can be meaningfully used is if the client has the ability to calculate the hash code of the key in the same manner the servers do. Firstly, this is hard when consumed by non-Java clients as you'd need to implement the way the JDK calculates the hash code of a byte array. Second, you'd need detailed and specific knowledge of any bit spreading that takes place within Infinispan - and this is internal implementation detail which may change from release to release.
So the way I see it I can't see how non-Java clients will be able to locate keys and then direct requests to the necessary nodes. In fact, even with Java clients the only way this could be done would be to send back marshalled Addresses in the topology map, *and* have the same version of the Infinispan server libs installed on the client, *and* ensure that the same JDK/JVM version is used on the client.
Can we think of a better way to do this? If not, is it worth still supporting client-side consistent hash based key location for the weird but vaguely workable scenario for Java-based clients?
Thoughts?
Cheers
Manik
[1] http://community.jboss.org/wiki/HotRodProtocol
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
14 years, 6 months
Re: [infinispan-dev] [jgroups-dev] Race condition with RspFilter
by Vladimir Blagojevic
https://jira.jboss.org/jira/browse/JGRP-1193
On 2010-04-21, at 2:09 AM, Bela Ban wrote:
> Can we capture this in the JIRA ?
>
> Vladimir Blagojevic wrote:
>> On 2010-04-20, at 3:24 AM, galder(a)jboss.org wrote:
>>
>>
>>> What values does RspFilerResult contain exactly?
>>>
>>>
>>
>> On top of my head I would say:
>>
>> public enum RspFilterResult{
>> ACCEPTABLE_NEEDS_MORE_RESPONSES,
>> ACCEPTABLE_PROCESSED_ALL,
>> UNACCEPTABLE_NEEDS_MORE_RESPONSES,
>> UNACCEPTABLE_PROCESSED_ALL,
>> }
>>
>>
>
> --
> Bela Ban
> Lead JGroups / Clustering Team
> JBoss
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Javagroups-development mailing list
>
14 years, 6 months