[infinispan-dev] API stability policy for major vs minor vs patch releases
Diego Didona
didona at gsd.inesc-id.pt
Thu Feb 24 11:35:06 EST 2011
Thank you very much.
So actually the redirection is not transparent to the client, nor there
is a "run time" redirection, since the client declares in the HTTP
request the keys it's going to use.
If this last sentence is correct, for the time being I don't have any
further question. Thank you for your explanation.
Regards,
Diego
> Responding to this here in case it's interesting to other members.
>
> I'm using some of the new features introduced in 4.2 to really boost performance.
>
> My distributed cache nodes expose their business logic -- consisting of multiple ISPN caches -- via REST. There is a very high data contention rate that acquiring a cluster-wide lock is too expensive. Also, a single business operation touches multiple caches, each with their own natural keys.
>
> So to get the throughput I needed:
>
> 1. I used ISPN's "eagerLockSingleNode" option. There's an explanation on the Wiki about it.
> 2. I made sure that the keys across multiple caches would be collocated, even across a rehash. I had to create a custom key container that would return the same hash code. There is no guarantee that two keys generated by ISPN's key factory would be on the same node after a rehash.
> 3. The DistributionMangerImpl allows you to get the owner of a key -- and whether a key "isLocal()". So since I'm using HTTP, I can examine the request, get the keys, and find out who owns them. I can then send a redirect (30x) back to the clients, and they forward the request to the data owner.
> 4. Because of the ISPN configuration, I now can start a transaction on the data owner and acquire only local locks.
>
> This improved throughput in my system considerably -- almost by a 4x factor.
>
> Hope this helps.
>
> Erik
>
> -----Original Message-----
> From: infinispan-dev-bounces at lists.jboss.org [mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Diego Didona
> Sent: Wednesday, February 23, 2011 5:52 PM
> To: infinispan -Dev List
> Subject: Re: [infinispan-dev] API stability policy for major vs minor vs patch releases
>
> Hi Erik!
> I'm a little bit off-topic but I would like to ask you what do you mean by "redirection". Can you explain it to me?
> Thanks
> Diego
>> +1.5B
>>
>> This method is a core component of my local transaction/redirection implementation. Hopefully, this was an oversight and not intended to be removed.
>>
>> Erik
>>
>> -----Original Message-----
>> From: infinispan-dev-bounces at lists.jboss.org
>> [mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Paul
>> Ferraro
>> Sent: Wednesday, February 23, 2011 12:01 PM
>> To: infinispan-dev at lists.jboss.org
>> Subject: [infinispan-dev] API stability policy for major vs minor vs
>> patch releases
>>
>> In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I came across a NoSuchMethodError. Specifically, a couple AS components utilize DistributionManager.isLocal(String), which was dropped from the public API sometime after 4.2.1.CR1.
>>
>> While the fix is trivial enough (in the end I'll need to perform several component release to compensate), this raises the larger issue of a API stability policy for major vs minor vs patch releases. At the very least, I don't think its wise to remove methods from a public interface in a patch release. In my opinion, removing methods from a public API should only happen across major releases, and even then, only after being formally deprecated.
>>
>> Thoughts?
>>
>> Paul
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Diego Didona
GSD INESC-ID
More information about the infinispan-dev
mailing list