Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # dev >> 3.4 blocker? rename MultiTransactionRecord to MultiRequest


Copy link to this message
-
Re: 3.4 blocker? rename MultiTransactionRecord to MultiRequest
I agree with Ted. Particularly if they aren't using multi ops, then it's a
non issue. Moreover, I don't see how changing the name of the class itself
would affect anything over the wire or in the datastore itself. Multi ops
are snapshotted. But the name of the class itself shouldn't affect being
able to read the snapshot off disk. I don't see any impact.

On Fri, Oct 28, 2011 at 1:08 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:

> The datastore is pretty much unchanged.
>
> If you don't use multi, then there should be zero impact.  If you have a
> 3.4 quorum and some 3.3 and some 3.4 clients the 3.3 clients will be unable
> (obviously) to do multi operations while the 3.4 clients will be able.  To
> all observers, multi's just look like a bunch of conventional operations
> happened except that a keen observer will note that they always see the
> entire multi or none of it.
>
>
> On Thu, Oct 27, 2011 at 10:29 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>
>> Marshall, Ted can you clarify - what's the impact on b/w compatibility
>> of these multiset changes?
>>
>> For example, can someone use 3.4 and then revert back to 3.3 codebase?
>> Or is the datastore incompatible with this? (I'm assuming 3.3 -> 3.4
>> is fine).
>>
>> Patrick
>>
>> On Thu, Oct 27, 2011 at 9:31 AM, Mahadev Konar <[EMAIL PROTECTED]>
>> wrote:
>> > Thomas,
>> >  Doesnt look like its a blocker to me. It isnt a public API. Renaming
>> > should be fine. Jute doesnt serializes the name of the record. So as
>> > long as the fields and opcode are the same, it should be backwards
>> > compatible as well. If you have a simple enough patch for rename I can
>> > include it in 3.4 as well (just to avoid any complications regarding
>> > backwards/forward compatibility later). Sounds reasonable?
>> >
>> > thanks
>> > mahadev
>> >
>> > On Thu, Oct 27, 2011 at 8:50 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> >> Submit a patch and slate it for 3.4.0/3.5.0, Mahadev can decide
>> >> whether he wants to include it in the next rc or not.
>> >>
>> >> Patrick
>> >>
>> >> On Thu, Oct 27, 2011 at 2:57 AM, Thomas Koch <[EMAIL PROTECTED]> wrote:
>> >>> Hi,
>> >>>
>> >>> I've opened ZK-1257 with this description:
>> >>>
>> >>> <quote>
>> >>> Understanding the code behind multi operations doesn't get any easier
>> when the
>> >>> code violates naming consistency.
>> >>> All other Request classes are called xxxRequest, only for multi its
>> >>> xxxTransactionRecord! Also "Transaction" is wrong, because there is
>> the
>> >>> concepts of transactions that are transmitted between quorum peers or
>> >>> committed to disc. MultiTransactionRecord however is a Request from a
>> client.
>> >>> </quote>
>> >>>
>> >>> I think the rename could also happen after 3.4 since
>> MultiTransactionRecord is
>> >>> not part of the API? If not, I strongly recommend to do the rename
>> before the
>> >>> release.
>> >>>
>> >>> Regards,
>> >>>
>> >>> Thomas Koch, http://www.koch.ro
>> >>>
>> >>
>> >
>>
>
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB