Stream dilemma
by Vladimir Blagojevic
Brian and I talked privately about changing CacheLoader API to use
object based stream parameters rather than plain input/output streams.
Please comment.
-----Original Message-----
From: Brian Stansberry
Sent: Saturday, August 26, 2006 2:29 PM
To: Vladimir Blagojevic
Subject: RE: Stream dilemma
I much prefer the latter. Earlier on a thread about this we determined
we wanted cross-CacheLoader interoperability and thus were going to
formally specify the format of the state as a sequence of serialized
NodeData objects. Therefore by the interface contract the cache loader
must use an ObjectInput/OutputSteam to do its job; it's not like the
loader implementor has freedom to use some
com.xyz.CustomStateEncodingInput/OutputStream. Given that, providing
the ObjectInput/OutputStream to the cache loader makes a lot more sense
for the reasons you stated. The CacheLoader's job is simply to read the
objects and store them; it shouldn't have access to the stream
underlying the ObjectInput/OutputStream as providing that access limits
the flexibility of the StateTransferGenerator/Integrator.
Once you provide the ObjectInput/OutputStream, that also logically
implies that the overloaded methods with the byte[] should go away.
Either the CacheLoader has to know how to manage the lifecycle of an
ObjectInput/OutputStream or it doesn't.
Vladimir Blagojevic wrote:
> Hey Brian,
>
> I am trying to find the best solution for persistent state
> loading/storing and I want to bounce this off you.
>
> Dilemma is whether to allow cacheloader implementers to create and
> close the stream themselves in load/store cacheloader implementations
> or not. If we keep current API signature with InputStream/OutputStream
> then cacheloader implementers have to wrap this stream with a variant
> of ObjectInputStream/ObjectOutputStream and then if they create this
> stream then they have to close it themselves. Which is fine I believe
> because we write/read persistent state last in state transfer. We also
> have to rely on cacheloader implementers that they know what they are
> doing. They might not for example propagate io exceptions to us and
> thus we have no idea that something went wrong.
>
> If we change current API signature to accept
> ObjectInputStream/ObjectOutputStream then we sort of have more control
> about which stream we pass to cacheloader implementers (we have
> reference to that stream), more control about closing it and we
> require less intelligence from cacheloader implementers about dealing
> with these streams.
> They simply read/write and do not catch any io exceptions and let
> everything propagate to the caller.
>
> I know I have not summarized this nicely. I am just sort of thinking
> out loud.
>
> All the best,
> Vladimir
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
19 years, 1 month
RE: [jbosscache-dev] Removal of old dev-jbosscache@jboss.com alias inExchange
by Ben Wang
OK by me. Sorry, my previous email was actually meant to sent to dev - jboss clustering since the thread is not about JBC only. :-)
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Friday, August 25, 2006 8:01 PM
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] Removal of old dev-jbosscache(a)jboss.com alias inExchange
Hi all.
How that we have this public mail list for jboss cache dev-related conversations, I don't see any reason to still have the old dev- jbosscache(a)jboss.com alias in Exchange. If there are no objections, can I ask JBIT to remove this alias?
I'd very much rather all dev related conversations are on the public mail list and any private ones thereafter directed to individual email accounts.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 1 month
NodeData streaming marker
by Vladimir Blagojevic
Hi,
As some of you are aware we talked about introducing a delimiter node
inserted between transient and persistent state. Since we have to look
for this node in the stream during streaming state transfer the search
should be very very efficient operation. Note that this is done only for
streaming state transfer and cacheloader implementations are unaware of
this.
Optimal solution IMO would be to extend NodeData class with
NodeDataMarker subclass and introduce a method
public boolean NodeData.isMarker()
that would return false in NodeData superclass and true in
NodeDataMarker subclass of NodeData.
We would write an instance of NodeDataMarker as a delimiter between
transient and persistent part of the stream. As we read instances of
NodeData in StreamingStateTransferIntegrator the search for
NodeDataMarker is fast and should not affect overall performance at all.
If I do not hear any objections or better proposals I will commit this
on Monday.
Vladimir
19 years, 1 month
RE: [jbosscache-dev] Re: [JBoss JIRA] Resolved: (JGRP-65)Performancetests and publish results
by Galder Zamarreno
+1 on getting JGRP-130 resolved first
Galder Zamarreño
Support Engineer
JBoss, a division of RedHat
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Brian Stansberry
Sent: 25 August 2006 15:56
To: Manik Surtani; Bela Ban
Cc: jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] Re: [JBoss JIRA] Resolved: (JGRP-65)Performancetests and publish results
If what we're talking about here is switching to a TCP-based stack as
the default, I'd be concerned about doing that until
http://jira.jboss.com/jira/browse/JGRP-130 is resolved.
If we're just talking using the optimized configs for each protocol, yes
definitely.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Yep, +1
>
>
>> In that case, let's complete the JIRA Brian created and then simply
>> copy over the config to JBossCache
>>
>> Manik Surtani wrote:
>>> I was also talking about the default XML files shipped with JBC for
>>> standalone use.
>>>
>>> Multiplexer related changes would only be for usage within AS. --
>>> Manik Surtani
>>>
>>> Lead, JBoss Cache
>>> JBoss, a division of Red Hat
>>>
>>> Email: manik(a)jboss.org
>>> Telephone: +44 7786 702 706
>>> MSN: manik(a)surtani.org
>>> Yahoo/AIM/Skype: maniksurtani
>>>
>>>
>>> On 25 Aug 2006, at 13:18, Bela Ban wrote:
>>>
>>>> Yes - Brian has a JIRA task open regarding this, for the
>>>> Multiplexer. Meaning, you wouldn't be affected
>>>>
>>>> Manik Surtani wrote:
>>>>> Would this mean a prudent change in the default configs shipped
>>>>> with JBC/JBossAS? --
>>>>> Manik Surtani
>>>>>
>>>>> Lead, JBoss Cache
>>>>> JBoss, a division of Red Hat
>>>>>
>>>>> Email: manik(a)jboss.org <mailto:manik@jboss.org>
>>>>> Telephone: +44 7786 702 706
>>>>> MSN: manik(a)surtani.org <mailto:manik@surtani.org>
>>>>> Yahoo/AIM/Skype: maniksurtani
>>>>>
>>>>>
>>>>> On 25 Aug 2006, at 12:39, Bela Ban wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Ben Wang wrote:
>>>>>>> Bela,
>>>>>>>
>>>>>>> Very good documentation and good numbers. I think once
>>>>>>> threadless stack is ready in 2.5, we will see dramatic
>>>>>>> performance boost on JBoss Cache level as well!
>>>>>>
>>>>>> Absolutely ! Parellel processing will definitely help both
>>>>>> JBossCache and clustering (ClusterPartition).
>>>>>>
>>>>>>> So looks like TCP performs better than UDP now. Is this the
>>>>>>> first time that we have seen this?
>>>>>>
>>>>>> No, that's always been the case for those smaller clusters. It
>>>>>> will be interesting to see what happens on a 64 node cluster
>>>>>> though.
>>>>>>
>>>>>> --Bela Ban
>>>>>> Lead JGroups / Manager JBoss Clustering Group JBoss - a division
>>>>>> of Red Hat
>>>>>
>>>>
>>>> --Bela Ban
>>>> Lead JGroups / Manager JBoss Clustering Group JBoss - a division
>>>> of Red Hat
>>>>
>>>
>>>
>>
>> --
>> Bela Ban
>> Lead JGroups / Manager JBoss Clustering Group JBoss - a division of
>> Red Hat
>>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 1 month
RE: [jbosscache-dev] Re: [JBoss JIRA] Resolved: (JGRP-65) Performancetests and publish results
by Brian Stansberry
If what we're talking about here is switching to a TCP-based stack as
the default, I'd be concerned about doing that until
http://jira.jboss.com/jira/browse/JGRP-130 is resolved.
If we're just talking using the optimized configs for each protocol, yes
definitely.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Yep, +1
>
>
>> In that case, let's complete the JIRA Brian created and then simply
>> copy over the config to JBossCache
>>
>> Manik Surtani wrote:
>>> I was also talking about the default XML files shipped with JBC for
>>> standalone use.
>>>
>>> Multiplexer related changes would only be for usage within AS. --
>>> Manik Surtani
>>>
>>> Lead, JBoss Cache
>>> JBoss, a division of Red Hat
>>>
>>> Email: manik(a)jboss.org
>>> Telephone: +44 7786 702 706
>>> MSN: manik(a)surtani.org
>>> Yahoo/AIM/Skype: maniksurtani
>>>
>>>
>>> On 25 Aug 2006, at 13:18, Bela Ban wrote:
>>>
>>>> Yes - Brian has a JIRA task open regarding this, for the
>>>> Multiplexer. Meaning, you wouldn't be affected
>>>>
>>>> Manik Surtani wrote:
>>>>> Would this mean a prudent change in the default configs shipped
>>>>> with JBC/JBossAS? --
>>>>> Manik Surtani
>>>>>
>>>>> Lead, JBoss Cache
>>>>> JBoss, a division of Red Hat
>>>>>
>>>>> Email: manik(a)jboss.org <mailto:manik@jboss.org>
>>>>> Telephone: +44 7786 702 706
>>>>> MSN: manik(a)surtani.org <mailto:manik@surtani.org>
>>>>> Yahoo/AIM/Skype: maniksurtani
>>>>>
>>>>>
>>>>> On 25 Aug 2006, at 12:39, Bela Ban wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Ben Wang wrote:
>>>>>>> Bela,
>>>>>>>
>>>>>>> Very good documentation and good numbers. I think once
>>>>>>> threadless stack is ready in 2.5, we will see dramatic
>>>>>>> performance boost on JBoss Cache level as well!
>>>>>>
>>>>>> Absolutely ! Parellel processing will definitely help both
>>>>>> JBossCache and clustering (ClusterPartition).
>>>>>>
>>>>>>> So looks like TCP performs better than UDP now. Is this the
>>>>>>> first time that we have seen this?
>>>>>>
>>>>>> No, that's always been the case for those smaller clusters. It
>>>>>> will be interesting to see what happens on a 64 node cluster
>>>>>> though.
>>>>>>
>>>>>> --Bela Ban
>>>>>> Lead JGroups / Manager JBoss Clustering Group JBoss - a division
>>>>>> of Red Hat
>>>>>
>>>>
>>>> --Bela Ban
>>>> Lead JGroups / Manager JBoss Clustering Group JBoss - a division
>>>> of Red Hat
>>>>
>>>
>>>
>>
>> --
>> Bela Ban
>> Lead JGroups / Manager JBoss Clustering Group JBoss - a division of
>> Red Hat
>>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
19 years, 1 month
RE: [jbosscache-dev] Removal of old dev-jbosscache@jboss.com aliasin Exchange
by Brian Stansberry
+1.
> Manik Surtani wrote:
>> Hi all.
>>
>> How that we have this public mail list for jboss cache dev-related
>> conversations, I don't see any reason to still have the old
>> dev-jbosscache(a)jboss.com alias in Exchange. If there are no
>> objections, can I ask JBIT to remove this alias?
>>
>> I'd very much rather all dev related conversations are on the public
>> mail list and any private ones thereafter directed to individual
>> email accounts.
>>
>> Cheers,
>> --
>> Manik Surtani
19 years, 1 month
RE: [jbosscache-dev] Removal of old dev-jbosscache@jboss.com alias inExchange
by Galder Zamarreno
+1
Galder Zamarreño
Support Engineer
JBoss, a division of RedHat
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: 25 August 2006 13:01
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] Removal of old dev-jbosscache(a)jboss.com alias inExchange
Hi all.
How that we have this public mail list for jboss cache dev-related
conversations, I don't see any reason to still have the old dev-
jbosscache(a)jboss.com alias in Exchange. If there are no objections,
can I ask JBIT to remove this alias?
I'd very much rather all dev related conversations are on the public
mail list and any private ones thereafter directed to individual
email accounts.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 1 month
JBossCache 2.0.0 and JGroups backward compat
by Manik Surtani
Just to remind everyone and to check up on expectations, JBossCache
2.0.0 will depend on (at a minimum) JGroups 2.4 (or 2.5, depending on
what we ship with), and will not be backward compatible with JGroups
2.2.x.
Let me know if there are any concerns.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
19 years, 1 month
Re: [JBoss JIRA] Resolved: (JGRP-65) Performance tests and publish results
by Manik Surtani
Would this mean a prudent change in the default configs shipped with
JBC/JBossAS?
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 25 Aug 2006, at 12:39, Bela Ban wrote:
>
>
> Ben Wang wrote:
>> Bela,
>>
>> Very good documentation and good numbers. I think once threadless
>> stack is ready in 2.5, we will see dramatic performance boost on
>> JBoss Cache level as well!
>
> Absolutely ! Parellel processing will definitely help both
> JBossCache and clustering (ClusterPartition).
>
>> So looks like TCP performs better than UDP now. Is this the first
>> time that we have seen this?
>
> No, that's always been the case for those smaller clusters. It will
> be interesting to see what happens on a 64 node cluster though.
>
> --
> Bela Ban
> Lead JGroups / Manager JBoss Clustering Group
> JBoss - a division of Red Hat
19 years, 1 month
Removal of old dev-jbosscache@jboss.com alias in Exchange
by Manik Surtani
Hi all.
How that we have this public mail list for jboss cache dev-related
conversations, I don't see any reason to still have the old dev-
jbosscache(a)jboss.com alias in Exchange. If there are no objections,
can I ask JBIT to remove this alias?
I'd very much rather all dev related conversations are on the public
mail list and any private ones thereafter directed to individual
email accounts.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
19 years, 1 month