qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: [java] 0.10 support
Date Fri, 29 Jun 2007 13:01:39 GMT

often the best way to deal with this is create a translation process, 
that straps the two
versions together - and forwards from the one version to the next. It 
adds another
process but once the migration is complete it can be tossed.

Carl.


Rupert Smith wrote:
> I see your point and it reminds me that you did explain this before.
> Pointing it out on the dev-list was probably worthwhile anyway to make 
> sure
> everyone is clear on the reasoning behind the choice.
>
> Rupert
>
> On 29/06/07, Robert Godfrey <rob.j.godfrey@gmail.com> wrote:
>>
>> The problem is that you can't translate an 0-8 message into a 0-10
>> message, they are completely different (different content classes and
>> everything)...  So if you are connecting to a 0-10 upgraded system,
>> you have to speak 0-10; the broker really can't have a 0-8 client
>> publishing messages, and then deliver them to a 0-10 client.
>>
>> So, whatever, you need the client to support multiple versions.  It
>> may also be useful to have the broker support multiple versions; but
>> for me - since there is no translation - this is the same as just
>> running a 0-8 broker and a 0-10 broker side by side...
>>
>> -- Rob
>>
>>
>>
>> On 29/06/07, Rupert Smith <rupertlssmith@googlemail.com> wrote:
>> > I think Gordon has a point worth thinking over carefully in choosing
>> between
>> > putting 0.8/0.10 support in the broker or in the client, with 
>> respect to
>> the
>> > upgrade path of existing clients. Consider the following:
>> >
>> > Situation today:
>> >
>> > App1 0.8 Client -> 0.8 Broker -> App1 0.8 Client.
>> >
>> > 1. Putting 0.8/0.10 in the Client:
>> >
>> > App1 0.8 Client         -> 0.8 Broker  -> App1 0.8 Client.
>> >                         /              \
>> > New App 0.8/0.10 Client -> 0.10 Broker -> New App 0.8/0.10 Client.
>> >
>> > * Old clients cannot take advantage of improvements in the broker.
>> > * We have to maintain two branches of broker code.
>> > * If the 0.8 broker is completely discontinued, the old App1 will be
>> forced
>> > to upgrade.
>> >
>> > 2. Putting 0.8/0.10 in the Broker:
>> >
>> > App1 0.8 Client     -> 0.8/0.10 Broker -> App1 0.8 Client.
>> >                     /\                 /\
>> > New App 0.10 Client -> 0.8/0.10 Broker -> New App 0.10 Client.
>> >
>> > * Old clients can upgrade to new client code in their own time frame.
>> > * Old clients can take advantage of bug fixes in new brokers as a drop
>> in
>> > replacement.
>> > * Old and new apps can share a single broker instance.
>> >
>> > Is making a 0.8/0.10 dual support broker significantly harder than 
>> doing
>> it
>> > for the client?
>> >
>> > Rupert
>> >
>> > On 29/06/07, Gordon Sim <gsim@redhat.com> wrote:
>> > >
>> > > Martin Ritchie wrote:
>> > > > I would very much like to request
>> > > > that we think about supporting 0_8 *and* 0_10 in the client 
>> code at
>> > > > least. This could be by having two sets of classes below the model
>> > > > layer such that the client can only speak one protocol at a time.
>> This
>> > > > would be beneficial for migrating existing customers to the newer
>> > > > protocol. Deployed clients are generally harder to change then 
>> their
>> > > > broker so if the client could support both protocols an 
>> incremental
>> > > > upgrade could be possible.
>> > >
>> > > "Deployed clients are generally harder to change" would suggest 
>> to me
>> > > that what was needed was a _broker_ that supported 0-8 and 0-10, 
>> since
>> > > not all clients could be upgraded when a broker is upgraded.
>> > >
>> > > When you say that it might be ok if "client can only speak one
>> protocol
>> > > at a time" do you mean a particular client process? If so, could 
>> that
>> > > not be achieved simply by pointing it to a different version of the
>> qpid
>> > > libraries?
>> > >
>> > > If on the other hand the requirement is to allow a particular
>> connection
>> > > within a process to choose one of the two versions, that would 
>> not be
>> > > quite as simple. If this is what you were thinking, do you have more
>> > > detail on what the underlying use case would be? I.e. is it a client
>> > > that needs to relay from one version of a broker to another? Or 
>> is it
>> > > quite different parts of a system that just happen to be in the same
>> > > process but might have different migration paths?
>> > >
>> > > I agree with your other points.
>> > >
>> >
>>
>


Mime
View raw message