You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Arnaud Simon <as...@redhat.com> on 2007/06/19 16:24:36 UTC
[java] 0.10 support
Hello,
Even if we have agreed on meeting in Glasgow sometime between the 21rst
and the 23rdf of August, I would like us to establish a plan for
migrating to 0.10. I have added a list of tasks for migrating to 0.10
(it is based on what Gordon has done for C++). It would be nice to put
estimate on those tasks and also to allocate them to people (note that
some tasks may be missing). More generally it would be good to know what
people involvement for the 0.10 migration is.
==model:==
* new query methods for exchange and binding (and possibly queue)
* minor changes to method arguments etc
- separation of 'auto-delete' from 'exclusive' in queue.declare
- removal of responses and no-wait field from several methods
- 'reject-unroutable' flag
* new flow control for message transfer
* new acking method for deliveries
* dtx - expose basic functionality through client
* changes to encoding of transfer
==execution layer:==
* track execution mark for outgoing requests
* manage execution mark for incoming framesets
* generic correlation support (details still vague)
==session layer:==
* session abstraction
- Channel should be Session
- channel exceptions are now session aborts
- channel open and close should be altered
- ack and hwm exchange
* session management
- maintain map of detached sessions, with timeouts
- simple case: sessions destroyed on detach
- failover: re-attach session to a channel on a new connection
- manage requested timeout
* replay buffer management
- record all outgoing frames along with a sequence number
- on receipt of an ack, delete as appropriate
* session re-establishment & replay
- implement session resumption (broker side only)
- re-establish connection (client side only)
- send any frames not seen by peer
==framing:==
* new field table encoding (including lots of new value types)
* new uuid type
* new type for 'long sets' (for ack structures)
* revised frame encoding
* decoding from (& encoding to?) discontinuous data
* revised architecture (chains, assembly of segments & framesets,
memory management etc)
Re: [java] 0.10 support
Posted by Gordon Sim <gs...@redhat.com>.
Arnaud Simon wrote:
> I have added a list of tasks for migrating to 0.10 (it is based on
> what Gordon has done for C++).
Caveat: my list was quite c++ specific so may not make as much sense to
the java side of things (e.g. we already have a message class, memory
management is more of an issue for us etc).
One task you did miss out from the model was the 'alternate exchange' as
the new mechanism for handling message returns.
Re: [java] 0.10 support
Posted by Alan Conway <ac...@redhat.com>.
On Fri, 2007-06-29 at 09:21 +0200, Arnaud Simon wrote:
> Hi,
>
> I have attached a design document (I hope Rupert will be pleased :)).
Excellent doc. The color coded stack is great, and looks very like how I
envision the C++ stack.
On the multi-protocol-broker issue: It is possible to map between Basic
messages and Message messages as they have almost identical fields (but
in very different places.) The C++ broker does it, it supports both
Basic and Message classes over 0-9 framing. It was a big pain to do.
The other key to multi-version is the separation of the model layer (top
box in Arnauds diagram) from the rest of the framing stack. In C++ the
model layer maps AMQP class/method to C++ class method, I imagine java
does similar. So e.g.
namespace amqp0_9 {
class QueueOperations {...} // generated.
class QueueImpl : public QueueOperations {
void declare(Ticket, Exchange, .. bool nowait) { do stuff }
};
namespace amqp0_10 {
class QueueOperations { ... } // generated
class QueueImpl : public QueueOperations {
// Removed nowait.
void declare(Ticket t, ...) { queue09.declare(t, ..., false); }
private:
amqp0_9::QueueImpl queue09;
}
};
Note that the classes in different versions are *not* related by
inheritance, as inheritance (in c++ and java at least) does not support
addition, removal and modification of methods in a useful way. However
the logic from the previous version can be re-used via delegation or the
new version can redefine method entirely as appropriate.
Cheers,
Alan.
Re: [java] 0.10 support
Posted by Carl Trieloff <cc...@redhat.com>.
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 <ro...@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 <ru...@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 <gs...@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.
>> > >
>> >
>>
>
Re: [java] 0.10 support
Posted by Rupert Smith <ru...@googlemail.com>.
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 <ro...@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 <ru...@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 <gs...@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.
> > >
> >
>
Re: [java] 0.10 support
Posted by Robert Godfrey <ro...@gmail.com>.
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 <ru...@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 <gs...@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.
> >
>
Re: [java] 0.10 support
Posted by Rupert Smith <ru...@googlemail.com>.
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 <gs...@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.
>
Re: [java] 0.10 support
Posted by Gordon Sim <gs...@redhat.com>.
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.
Re: [java] 0.10 support
Posted by Arnaud Simon <as...@redhat.com>.
On Fri, 2007-06-29 at 10:17 +0100, Robert Godfrey wrote:
> The issue that has to be considered is that in an organisation that
> has committed itself to AMQP, there may already be deployments of 0.8
> brokers and clients. In particular several independent systems may be
> deployed using 0.8 brokers. These systems will not all upgrade to
> 0-10 at the same time. A single application may connect to two
> systems, and if these two systems do not upgrade simultaneously, then
> we have a huge problem.
Ok, it makes sense but the applications should really be using multiple
connection factories, I mean one per system. It may not be the case but
if it was we could have solved this issue by changing 0.10 name space.
> I think therefore the sensible option is to engineer the client in
> such a way as that it can connect to both 0-8 and 0-10 brokers while
> maintaining a JMS interface. There is no compatability at the AMQP
> level, but from the JMS level it will look the same.
>
> This *really* is a requirement!
So, we'll support it :)
Re: [java] 0.10 support
Posted by Robert Godfrey <ro...@gmail.com>.
On 29/06/07, Gordon Sim <gs...@redhat.com> wrote:
> Robert Godfrey wrote:
> > The issue that has to be considered is that in an organisation that
> > has committed itself to AMQP, there may already be deployments of 0.8
> > brokers and clients. In particular several independent systems may be
> > deployed using 0.8 brokers. These systems will not all upgrade to
> > 0-10 at the same time. A single application may connect to two
> > systems, and if these two systems do not upgrade simultaneously, then
> > we have a huge problem.
> >
> > I think therefore the sensible option is to engineer the client in
> > such a way as that it can connect to both 0-8 and 0-10 brokers while
> > maintaining a JMS interface. There is no compatability at the AMQP
> > level, but from the JMS level it will look the same.
>
> One (admittedly rather crude) way of achieving that might be to move all
> the 0-8 code to a qpid08 package. That way you could create
> qpid.AMQConnections and/or qpid08.AMQConnections in the same process.
>
> Do you envisage 0-8 support being dropped once 0-11 is reached? Or do
> you see it being required to 1-0 and beyond?
>
I think in terms of my experiance supporting back one version should
be sufficient... gives people enough time to complete migration from
the old to the new version. I think the situation will become easier
once we move to 0-10 as I think (and will try to ensure) that the
changes from 0-10 to 1-0 will be smaller, and possible to support
without two separate code bases.
For the next release the solution doesn't have to be pretty, and two
connection factories and separate packaging would be fine by me...
-- Rob
Re: [java] 0.10 support
Posted by Gordon Sim <gs...@redhat.com>.
Robert Godfrey wrote:
> The issue that has to be considered is that in an organisation that
> has committed itself to AMQP, there may already be deployments of 0.8
> brokers and clients. In particular several independent systems may be
> deployed using 0.8 brokers. These systems will not all upgrade to
> 0-10 at the same time. A single application may connect to two
> systems, and if these two systems do not upgrade simultaneously, then
> we have a huge problem.
>
> I think therefore the sensible option is to engineer the client in
> such a way as that it can connect to both 0-8 and 0-10 brokers while
> maintaining a JMS interface. There is no compatability at the AMQP
> level, but from the JMS level it will look the same.
One (admittedly rather crude) way of achieving that might be to move all
the 0-8 code to a qpid08 package. That way you could create
qpid.AMQConnections and/or qpid08.AMQConnections in the same process.
Do you envisage 0-8 support being dropped once 0-11 is reached? Or do
you see it being required to 1-0 and beyond?
Re: [java] 0.10 support
Posted by Robert Godfrey <ro...@gmail.com>.
The issue that has to be considered is that in an organisation that
has committed itself to AMQP, there may already be deployments of 0.8
brokers and clients. In particular several independent systems may be
deployed using 0.8 brokers. These systems will not all upgrade to
0-10 at the same time. A single application may connect to two
systems, and if these two systems do not upgrade simultaneously, then
we have a huge problem.
I think therefore the sensible option is to engineer the client in
such a way as that it can connect to both 0-8 and 0-10 brokers while
maintaining a JMS interface. There is no compatability at the AMQP
level, but from the JMS level it will look the same.
This *really* is a requirement!
-- Rob
On 29/06/07, Arnaud Simon <as...@redhat.com> wrote:
> Hi Martin,
>
> Many thanks for you comments.
>
> > Arnaud,
> > Thanks for putting that document together. I haven't been keeping up
> > with the 0_10 work as much as I'd like but with M2 coming to an end
> > I'll have to dive back in there. 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.
>
> I am not sure of the benefit of that as the 0.8 protocol is not
> compatible with 0.10, a 0.8 client cannot talk to a 0.10 broker. As you
> said it is usually more difficult to get all your clients migrating to
> the new protocol then it would make more sense to have the broker using
> two addresses i.e. one for 0.8 and a new one for 0.10 clients. Then you
> would be able to smoothly migrate your clients to 0.10 when the 0.8 ones
> are still running.
>
> An important thing to consider though is that the model layer has also
> changed. Thus, I am not sure having a broker or a client compatible with
> the two protocols could easily be achievable.
>
> > As we are designing the changes for 0_10 I think it is important to
> > think about multiple protocol version support. Ideally going forward
> > from 0_10 the protocol (from what I understand) will not have such
> > radical changes as we have going from 0_8 to 0_10, as such supporting
> > 0_11 etc from our next client should be one of our goals.
>
> Version control is indeed important and I really think that it should be
> on our face to face agenda. However, it does not only depends on the
> implementation design but also on the 0.11 specs.
>
> > If we do decide to support 0_8 as well the next client we will of
> > course have to remember that the project has people using this
> > software in production. As a result we cannot just change our client
> > API. New functionality is easy to add but altering the behaviour of
> > existing methods will be extremely annoying to existing users. All
> > changes to existing APIs should be well documented and have the
> > ability to maintain their functionality in the selected protocol
> > version. Ideally current clients should be using the JMS interfaces so
> > reducing the change problem but we shouldn't assume this. As we move
> > forward with the implementation we could start to think about what
> > methods that are public in our client code that should actually be
> > public and part of any API we wish to put forward.
>
> Introducing an AMQP API is part of the work that Rajith has started. We
> have also to discuss that at the AMQP level as it impacts all
> implementations. I think that it is going to be a 0.11 focus. I would
> say that we can achieve 0.10 support before that though.
>
>
>
Re: [java] 0.10 support
Posted by Arnaud Simon <as...@redhat.com>.
Hi Martin,
Many thanks for you comments.
> Arnaud,
> Thanks for putting that document together. I haven't been keeping up
> with the 0_10 work as much as I'd like but with M2 coming to an end
> I'll have to dive back in there. 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.
I am not sure of the benefit of that as the 0.8 protocol is not
compatible with 0.10, a 0.8 client cannot talk to a 0.10 broker. As you
said it is usually more difficult to get all your clients migrating to
the new protocol then it would make more sense to have the broker using
two addresses i.e. one for 0.8 and a new one for 0.10 clients. Then you
would be able to smoothly migrate your clients to 0.10 when the 0.8 ones
are still running.
An important thing to consider though is that the model layer has also
changed. Thus, I am not sure having a broker or a client compatible with
the two protocols could easily be achievable.
> As we are designing the changes for 0_10 I think it is important to
> think about multiple protocol version support. Ideally going forward
> from 0_10 the protocol (from what I understand) will not have such
> radical changes as we have going from 0_8 to 0_10, as such supporting
> 0_11 etc from our next client should be one of our goals.
Version control is indeed important and I really think that it should be
on our face to face agenda. However, it does not only depends on the
implementation design but also on the 0.11 specs.
> If we do decide to support 0_8 as well the next client we will of
> course have to remember that the project has people using this
> software in production. As a result we cannot just change our client
> API. New functionality is easy to add but altering the behaviour of
> existing methods will be extremely annoying to existing users. All
> changes to existing APIs should be well documented and have the
> ability to maintain their functionality in the selected protocol
> version. Ideally current clients should be using the JMS interfaces so
> reducing the change problem but we shouldn't assume this. As we move
> forward with the implementation we could start to think about what
> methods that are public in our client code that should actually be
> public and part of any API we wish to put forward.
Introducing an AMQP API is part of the work that Rajith has started. We
have also to discuss that at the AMQP level as it impacts all
implementations. I think that it is going to be a 0.11 focus. I would
say that we can achieve 0.10 support before that though.
Re: [java] 0.10 support
Posted by Martin Ritchie <ri...@apache.org>.
On 29/06/07, Arnaud Simon <as...@redhat.com> wrote:
> Hi,
>
> I have attached a design document (I hope Rupert will be pleased :)).
> The aim is to quickly provide 0.10 support by maximizing code reuse. We
> will then incrementally update the design and the code for improving
> management/clustering/performance enhancement/backward
> compatibility/AMQP API/etc.
> I am sure you'll have some useful comments and ideas that will impact
> this design. However, keep in mind that for now on I really aim at
> maximizing code reuse.
>
> Arnaud
Arnaud,
Thanks for putting that document together. I haven't been keeping up
with the 0_10 work as much as I'd like but with M2 coming to an end
I'll have to dive back in there. 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.
As we are designing the changes for 0_10 I think it is important to
think about multiple protocol version support. Ideally going forward
from 0_10 the protocol (from what I understand) will not have such
radical changes as we have going from 0_8 to 0_10, as such supporting
0_11 etc from our next client should be one of our goals.
If we do decide to support 0_8 as well the next client we will of
course have to remember that the project has people using this
software in production. As a result we cannot just change our client
API. New functionality is easy to add but altering the behaviour of
existing methods will be extremely annoying to existing users. All
changes to existing APIs should be well documented and have the
ability to maintain their functionality in the selected protocol
version. Ideally current clients should be using the JMS interfaces so
reducing the change problem but we shouldn't assume this. As we move
forward with the implementation we could start to think about what
methods that are public in our client code that should actually be
public and part of any API we wish to put forward.
> On Tue, 2007-06-19 at 15:41 +0100, Rupert Smith wrote:
> > Presumably you mean for the Java? This is the Java version of a scope
> > of work drawn up for the C++ by Gordon?
> >
> > It would be nice to see this grow into a reasonably clean 'design
> > document' for the Java going forward to 0.10. I'm a big fan of the
> > design first, code later approach, rather than trying to divy up work
> > for such a complex thing on the basis of a high level summary. The
> > result will be more coherent, I feel, if we get a chance to establish
> > a reviewed design first. Nice work, and I think it will provide a very
> > good framework for the Java F2F to work around.
> >
> > Can I suggest this forms the starting point of a Wiki for the 0.10
> > design?
> >
> > Rupert
> >
> > On 19/06/07, Arnaud Simon <as...@redhat.com> wrote:
> > Hello,
> >
> > Even if we have agreed on meeting in Glasgow sometime between
> > the 21rst
> > and the 23rdf of August, I would like us to establish a plan
> > for
> > migrating to 0.10. I have added a list of tasks for migrating
> > to 0.10
> > (it is based on what Gordon has done for C++). It would be
> > nice to put
> > estimate on those tasks and also to allocate them to people
> > (note that
> > some tasks may be missing). More generally it would be good to
> > know what
> > people involvement for the 0.10 migration is.
> >
> > ==model:==
> > * new query methods for exchange and binding (and possibly
> > queue)
> > * minor changes to method arguments etc
> > - separation of 'auto-delete' from 'exclusive' in
> > queue.declare
> > - removal of responses and no-wait field from several
> > methods
> > - 'reject-unroutable' flag
> > * new flow control for message transfer
> > * new acking method for deliveries
> > * dtx - expose basic functionality through client
> > * changes to encoding of transfer
> >
> > ==execution layer:==
> > * track execution mark for outgoing requests
> > * manage execution mark for incoming framesets
> > * generic correlation support (details still vague)
> >
> > ==session layer:==
> > * session abstraction
> > - Channel should be Session
> > - channel exceptions are now session aborts
> > - channel open and close should be altered
> > - ack and hwm exchange
> > * session management
> > - maintain map of detached sessions, with timeouts
> > - simple case: sessions destroyed on detach
> > - failover: re-attach session to a channel on a new
> > connection
> > - manage requested timeout
> > * replay buffer management
> > - record all outgoing frames along with a sequence number
> > - on receipt of an ack, delete as appropriate
> > * session re-establishment & replay
> > - implement session resumption (broker side only)
> > - re-establish connection (client side only)
> > - send any frames not seen by peer
> >
> > ==framing:==
> > * new field table encoding (including lots of new value
> > types)
> > * new uuid type
> > * new type for 'long sets' (for ack structures)
> > * revised frame encoding
> > * decoding from (& encoding to?) discontinuous data
> > * revised architecture (chains, assembly of segments &
> > framesets,
> > memory management etc)
> >
> >
>
>
--
Martin Ritchie
Re: [java] 0.10 support
Posted by Rupert Smith <ru...@googlemail.com>.
On 29/06/07, Arnaud Simon <as...@redhat.com> wrote:
> I have attached a design document (I hope Rupert will be pleased :)).
:-D Absolutely! I think you have a talent for squeezing new code into an
existing solution that is somewhat complex in its structure (going by dtx
stuff too). Also, I definitely like the idea of minimal code change to
arrive at a working solution; it means you are finding the shortest path to
go from a working system to a working system, with the necessary 'breaking
it to fix it' step in between. It also means that the possibility of merging
bug fixes down from M2 onto trunk remains open to the greatest extent
possible; important as customers using M2 will find bugs, the fixes to which
should be carried forward into the 0.10 code.
Rupert
Re: [java] 0.10 support
Posted by Arnaud Simon <as...@redhat.com>.
Hi,
I have attached a design document (I hope Rupert will be pleased :)).
The aim is to quickly provide 0.10 support by maximizing code reuse. We
will then incrementally update the design and the code for improving
management/clustering/performance enhancement/backward
compatibility/AMQP API/etc.
I am sure you'll have some useful comments and ideas that will impact
this design. However, keep in mind that for now on I really aim at
maximizing code reuse.
Arnaud
On Tue, 2007-06-19 at 15:41 +0100, Rupert Smith wrote:
> Presumably you mean for the Java? This is the Java version of a scope
> of work drawn up for the C++ by Gordon?
>
> It would be nice to see this grow into a reasonably clean 'design
> document' for the Java going forward to 0.10. I'm a big fan of the
> design first, code later approach, rather than trying to divy up work
> for such a complex thing on the basis of a high level summary. The
> result will be more coherent, I feel, if we get a chance to establish
> a reviewed design first. Nice work, and I think it will provide a very
> good framework for the Java F2F to work around.
>
> Can I suggest this forms the starting point of a Wiki for the 0.10
> design?
>
> Rupert
>
> On 19/06/07, Arnaud Simon <as...@redhat.com> wrote:
> Hello,
>
> Even if we have agreed on meeting in Glasgow sometime between
> the 21rst
> and the 23rdf of August, I would like us to establish a plan
> for
> migrating to 0.10. I have added a list of tasks for migrating
> to 0.10
> (it is based on what Gordon has done for C++). It would be
> nice to put
> estimate on those tasks and also to allocate them to people
> (note that
> some tasks may be missing). More generally it would be good to
> know what
> people involvement for the 0.10 migration is.
>
> ==model:==
> * new query methods for exchange and binding (and possibly
> queue)
> * minor changes to method arguments etc
> - separation of 'auto-delete' from 'exclusive' in
> queue.declare
> - removal of responses and no-wait field from several
> methods
> - 'reject-unroutable' flag
> * new flow control for message transfer
> * new acking method for deliveries
> * dtx - expose basic functionality through client
> * changes to encoding of transfer
>
> ==execution layer:==
> * track execution mark for outgoing requests
> * manage execution mark for incoming framesets
> * generic correlation support (details still vague)
>
> ==session layer:==
> * session abstraction
> - Channel should be Session
> - channel exceptions are now session aborts
> - channel open and close should be altered
> - ack and hwm exchange
> * session management
> - maintain map of detached sessions, with timeouts
> - simple case: sessions destroyed on detach
> - failover: re-attach session to a channel on a new
> connection
> - manage requested timeout
> * replay buffer management
> - record all outgoing frames along with a sequence number
> - on receipt of an ack, delete as appropriate
> * session re-establishment & replay
> - implement session resumption (broker side only)
> - re-establish connection (client side only)
> - send any frames not seen by peer
>
> ==framing:==
> * new field table encoding (including lots of new value
> types)
> * new uuid type
> * new type for 'long sets' (for ack structures)
> * revised frame encoding
> * decoding from (& encoding to?) discontinuous data
> * revised architecture (chains, assembly of segments &
> framesets,
> memory management etc)
>
>
Re: [java] 0.10 support
Posted by Rupert Smith <ru...@googlemail.com>.
Presumably you mean for the Java? This is the Java version of a scope of
work drawn up for the C++ by Gordon?
It would be nice to see this grow into a reasonably clean 'design document'
for the Java going forward to 0.10. I'm a big fan of the design first, code
later approach, rather than trying to divy up work for such a complex thing
on the basis of a high level summary. The result will be more coherent, I
feel, if we get a chance to establish a reviewed design first. Nice work,
and I think it will provide a very good framework for the Java F2F to work
around.
Can I suggest this forms the starting point of a Wiki for the 0.10 design?
Rupert
On 19/06/07, Arnaud Simon <as...@redhat.com> wrote:
>
> Hello,
>
> Even if we have agreed on meeting in Glasgow sometime between the 21rst
> and the 23rdf of August, I would like us to establish a plan for
> migrating to 0.10. I have added a list of tasks for migrating to 0.10
> (it is based on what Gordon has done for C++). It would be nice to put
> estimate on those tasks and also to allocate them to people (note that
> some tasks may be missing). More generally it would be good to know what
> people involvement for the 0.10 migration is.
>
> ==model:==
> * new query methods for exchange and binding (and possibly queue)
> * minor changes to method arguments etc
> - separation of 'auto-delete' from 'exclusive' in queue.declare
> - removal of responses and no-wait field from several methods
> - 'reject-unroutable' flag
> * new flow control for message transfer
> * new acking method for deliveries
> * dtx - expose basic functionality through client
> * changes to encoding of transfer
>
> ==execution layer:==
> * track execution mark for outgoing requests
> * manage execution mark for incoming framesets
> * generic correlation support (details still vague)
>
> ==session layer:==
> * session abstraction
> - Channel should be Session
> - channel exceptions are now session aborts
> - channel open and close should be altered
> - ack and hwm exchange
> * session management
> - maintain map of detached sessions, with timeouts
> - simple case: sessions destroyed on detach
> - failover: re-attach session to a channel on a new connection
> - manage requested timeout
> * replay buffer management
> - record all outgoing frames along with a sequence number
> - on receipt of an ack, delete as appropriate
> * session re-establishment & replay
> - implement session resumption (broker side only)
> - re-establish connection (client side only)
> - send any frames not seen by peer
>
> ==framing:==
> * new field table encoding (including lots of new value types)
> * new uuid type
> * new type for 'long sets' (for ack structures)
> * revised frame encoding
> * decoding from (& encoding to?) discontinuous data
> * revised architecture (chains, assembly of segments & framesets,
> memory management etc)
>
>
Re: [java] 0.10 support
Posted by Robert Godfrey <ro...@gmail.com>.
On 19/06/07, Arnaud Simon <as...@redhat.com> wrote:
> I think that we can start right now safely working on the framing,
> session and execution layers that are common to the client and the
> broker (maybe the execution layer is slightly different). Those layer
> should not impact on our cluster,
These layers are impacted by clusering, very definitely (I assume that
we will be building the clustering at the Session layer).
The execution layer in the broker and the client may well be different
- or at least differently configured. The threading model in client
and broker should be different.
I really want to think about how we do our framing too... the 0-10
model is very different; and I think we have the opportunity to look
at how Qpid/J handles the byte buffers so that we do less copying...
-- Rob
> Message/Queue/DeliveryManager and
> management/monitoring design. Moreover I really see having those layer
> done as the main step toward providing 0.10 support.
>
> Arnaud
>
> On Tue, 2007-06-19 at 16:01 +0100, Robert Godfrey wrote:
> > Yep, we need to think about management, and about security.
> >
> > At the F2F it would also be good to think about how clustering is
> > going to affect our design.
> >
> > -- Rob
> >
> > On 19/06/07, Martin Ritchie <ri...@apache.org> wrote:
> > > On 19/06/07, Robert Godfrey <ro...@gmail.com> wrote:
> > > > I think we really want to examine our Message / Queue /
> > > > DeliveryManager / Subscription model as well ... this is not
> > > > necessarily driven by 0-10, just that the code is a bit "confused"
> > > >
> > > > -- Rob
> > >
> > > I would like to include management/monitoring of these items in the
> > > examination so that we can develop a cohesive solution.
> > >
> > > > On 19/06/07, Arnaud Simon <as...@redhat.com> wrote:
> > > > > Hello,
> > > > >
> > > > > Even if we have agreed on meeting in Glasgow sometime between the 21rst
> > > > > and the 23rdf of August, I would like us to establish a plan for
> > > > > migrating to 0.10. I have added a list of tasks for migrating to 0.10
> > > > > (it is based on what Gordon has done for C++). It would be nice to put
> > > > > estimate on those tasks and also to allocate them to people (note that
> > > > > some tasks may be missing). More generally it would be good to know what
> > > > > people involvement for the 0.10 migration is.
> > > > >
> > > > > ==model:==
> > > > > * new query methods for exchange and binding (and possibly queue)
> > > > > * minor changes to method arguments etc
> > > > > - separation of 'auto-delete' from 'exclusive' in queue.declare
> > > > > - removal of responses and no-wait field from several methods
> > > > > - 'reject-unroutable' flag
> > > > > * new flow control for message transfer
> > > > > * new acking method for deliveries
> > > > > * dtx - expose basic functionality through client
> > > > > * changes to encoding of transfer
> > > > >
> > > > > ==execution layer:==
> > > > > * track execution mark for outgoing requests
> > > > > * manage execution mark for incoming framesets
> > > > > * generic correlation support (details still vague)
> > > > >
> > > > > ==session layer:==
> > > > > * session abstraction
> > > > > - Channel should be Session
> > > > > - channel exceptions are now session aborts
> > > > > - channel open and close should be altered
> > > > > - ack and hwm exchange
> > > > > * session management
> > > > > - maintain map of detached sessions, with timeouts
> > > > > - simple case: sessions destroyed on detach
> > > > > - failover: re-attach session to a channel on a new connection
> > > > > - manage requested timeout
> > > > > * replay buffer management
> > > > > - record all outgoing frames along with a sequence number
> > > > > - on receipt of an ack, delete as appropriate
> > > > > * session re-establishment & replay
> > > > > - implement session resumption (broker side only)
> > > > > - re-establish connection (client side only)
> > > > > - send any frames not seen by peer
> > > > >
> > > > > ==framing:==
> > > > > * new field table encoding (including lots of new value types)
> > > > > * new uuid type
> > > > > * new type for 'long sets' (for ack structures)
> > > > > * revised frame encoding
> > > > > * decoding from (& encoding to?) discontinuous data
> > > > > * revised architecture (chains, assembly of segments & framesets,
> > > > > memory management etc)
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Martin Ritchie
> > >
>
>
Re: [java] 0.10 support
Posted by Arnaud Simon <as...@redhat.com>.
I think that we can start right now safely working on the framing,
session and execution layers that are common to the client and the
broker (maybe the execution layer is slightly different). Those layer
should not impact on our cluster, Message/Queue/DeliveryManager and
management/monitoring design. Moreover I really see having those layer
done as the main step toward providing 0.10 support.
Arnaud
On Tue, 2007-06-19 at 16:01 +0100, Robert Godfrey wrote:
> Yep, we need to think about management, and about security.
>
> At the F2F it would also be good to think about how clustering is
> going to affect our design.
>
> -- Rob
>
> On 19/06/07, Martin Ritchie <ri...@apache.org> wrote:
> > On 19/06/07, Robert Godfrey <ro...@gmail.com> wrote:
> > > I think we really want to examine our Message / Queue /
> > > DeliveryManager / Subscription model as well ... this is not
> > > necessarily driven by 0-10, just that the code is a bit "confused"
> > >
> > > -- Rob
> >
> > I would like to include management/monitoring of these items in the
> > examination so that we can develop a cohesive solution.
> >
> > > On 19/06/07, Arnaud Simon <as...@redhat.com> wrote:
> > > > Hello,
> > > >
> > > > Even if we have agreed on meeting in Glasgow sometime between the 21rst
> > > > and the 23rdf of August, I would like us to establish a plan for
> > > > migrating to 0.10. I have added a list of tasks for migrating to 0.10
> > > > (it is based on what Gordon has done for C++). It would be nice to put
> > > > estimate on those tasks and also to allocate them to people (note that
> > > > some tasks may be missing). More generally it would be good to know what
> > > > people involvement for the 0.10 migration is.
> > > >
> > > > ==model:==
> > > > * new query methods for exchange and binding (and possibly queue)
> > > > * minor changes to method arguments etc
> > > > - separation of 'auto-delete' from 'exclusive' in queue.declare
> > > > - removal of responses and no-wait field from several methods
> > > > - 'reject-unroutable' flag
> > > > * new flow control for message transfer
> > > > * new acking method for deliveries
> > > > * dtx - expose basic functionality through client
> > > > * changes to encoding of transfer
> > > >
> > > > ==execution layer:==
> > > > * track execution mark for outgoing requests
> > > > * manage execution mark for incoming framesets
> > > > * generic correlation support (details still vague)
> > > >
> > > > ==session layer:==
> > > > * session abstraction
> > > > - Channel should be Session
> > > > - channel exceptions are now session aborts
> > > > - channel open and close should be altered
> > > > - ack and hwm exchange
> > > > * session management
> > > > - maintain map of detached sessions, with timeouts
> > > > - simple case: sessions destroyed on detach
> > > > - failover: re-attach session to a channel on a new connection
> > > > - manage requested timeout
> > > > * replay buffer management
> > > > - record all outgoing frames along with a sequence number
> > > > - on receipt of an ack, delete as appropriate
> > > > * session re-establishment & replay
> > > > - implement session resumption (broker side only)
> > > > - re-establish connection (client side only)
> > > > - send any frames not seen by peer
> > > >
> > > > ==framing:==
> > > > * new field table encoding (including lots of new value types)
> > > > * new uuid type
> > > > * new type for 'long sets' (for ack structures)
> > > > * revised frame encoding
> > > > * decoding from (& encoding to?) discontinuous data
> > > > * revised architecture (chains, assembly of segments & framesets,
> > > > memory management etc)
> > > >
> > > >
> > >
> >
> >
> > --
> > Martin Ritchie
> >
Re: [java] 0.10 support
Posted by Robert Godfrey <ro...@gmail.com>.
Yep, we need to think about management, and about security.
At the F2F it would also be good to think about how clustering is
going to affect our design.
-- Rob
On 19/06/07, Martin Ritchie <ri...@apache.org> wrote:
> On 19/06/07, Robert Godfrey <ro...@gmail.com> wrote:
> > I think we really want to examine our Message / Queue /
> > DeliveryManager / Subscription model as well ... this is not
> > necessarily driven by 0-10, just that the code is a bit "confused"
> >
> > -- Rob
>
> I would like to include management/monitoring of these items in the
> examination so that we can develop a cohesive solution.
>
> > On 19/06/07, Arnaud Simon <as...@redhat.com> wrote:
> > > Hello,
> > >
> > > Even if we have agreed on meeting in Glasgow sometime between the 21rst
> > > and the 23rdf of August, I would like us to establish a plan for
> > > migrating to 0.10. I have added a list of tasks for migrating to 0.10
> > > (it is based on what Gordon has done for C++). It would be nice to put
> > > estimate on those tasks and also to allocate them to people (note that
> > > some tasks may be missing). More generally it would be good to know what
> > > people involvement for the 0.10 migration is.
> > >
> > > ==model:==
> > > * new query methods for exchange and binding (and possibly queue)
> > > * minor changes to method arguments etc
> > > - separation of 'auto-delete' from 'exclusive' in queue.declare
> > > - removal of responses and no-wait field from several methods
> > > - 'reject-unroutable' flag
> > > * new flow control for message transfer
> > > * new acking method for deliveries
> > > * dtx - expose basic functionality through client
> > > * changes to encoding of transfer
> > >
> > > ==execution layer:==
> > > * track execution mark for outgoing requests
> > > * manage execution mark for incoming framesets
> > > * generic correlation support (details still vague)
> > >
> > > ==session layer:==
> > > * session abstraction
> > > - Channel should be Session
> > > - channel exceptions are now session aborts
> > > - channel open and close should be altered
> > > - ack and hwm exchange
> > > * session management
> > > - maintain map of detached sessions, with timeouts
> > > - simple case: sessions destroyed on detach
> > > - failover: re-attach session to a channel on a new connection
> > > - manage requested timeout
> > > * replay buffer management
> > > - record all outgoing frames along with a sequence number
> > > - on receipt of an ack, delete as appropriate
> > > * session re-establishment & replay
> > > - implement session resumption (broker side only)
> > > - re-establish connection (client side only)
> > > - send any frames not seen by peer
> > >
> > > ==framing:==
> > > * new field table encoding (including lots of new value types)
> > > * new uuid type
> > > * new type for 'long sets' (for ack structures)
> > > * revised frame encoding
> > > * decoding from (& encoding to?) discontinuous data
> > > * revised architecture (chains, assembly of segments & framesets,
> > > memory management etc)
> > >
> > >
> >
>
>
> --
> Martin Ritchie
>
Re: [java] 0.10 support
Posted by Martin Ritchie <ri...@apache.org>.
On 19/06/07, Robert Godfrey <ro...@gmail.com> wrote:
> I think we really want to examine our Message / Queue /
> DeliveryManager / Subscription model as well ... this is not
> necessarily driven by 0-10, just that the code is a bit "confused"
>
> -- Rob
I would like to include management/monitoring of these items in the
examination so that we can develop a cohesive solution.
> On 19/06/07, Arnaud Simon <as...@redhat.com> wrote:
> > Hello,
> >
> > Even if we have agreed on meeting in Glasgow sometime between the 21rst
> > and the 23rdf of August, I would like us to establish a plan for
> > migrating to 0.10. I have added a list of tasks for migrating to 0.10
> > (it is based on what Gordon has done for C++). It would be nice to put
> > estimate on those tasks and also to allocate them to people (note that
> > some tasks may be missing). More generally it would be good to know what
> > people involvement for the 0.10 migration is.
> >
> > ==model:==
> > * new query methods for exchange and binding (and possibly queue)
> > * minor changes to method arguments etc
> > - separation of 'auto-delete' from 'exclusive' in queue.declare
> > - removal of responses and no-wait field from several methods
> > - 'reject-unroutable' flag
> > * new flow control for message transfer
> > * new acking method for deliveries
> > * dtx - expose basic functionality through client
> > * changes to encoding of transfer
> >
> > ==execution layer:==
> > * track execution mark for outgoing requests
> > * manage execution mark for incoming framesets
> > * generic correlation support (details still vague)
> >
> > ==session layer:==
> > * session abstraction
> > - Channel should be Session
> > - channel exceptions are now session aborts
> > - channel open and close should be altered
> > - ack and hwm exchange
> > * session management
> > - maintain map of detached sessions, with timeouts
> > - simple case: sessions destroyed on detach
> > - failover: re-attach session to a channel on a new connection
> > - manage requested timeout
> > * replay buffer management
> > - record all outgoing frames along with a sequence number
> > - on receipt of an ack, delete as appropriate
> > * session re-establishment & replay
> > - implement session resumption (broker side only)
> > - re-establish connection (client side only)
> > - send any frames not seen by peer
> >
> > ==framing:==
> > * new field table encoding (including lots of new value types)
> > * new uuid type
> > * new type for 'long sets' (for ack structures)
> > * revised frame encoding
> > * decoding from (& encoding to?) discontinuous data
> > * revised architecture (chains, assembly of segments & framesets,
> > memory management etc)
> >
> >
>
--
Martin Ritchie
Re: [java] 0.10 support
Posted by Robert Godfrey <ro...@gmail.com>.
I think we really want to examine our Message / Queue /
DeliveryManager / Subscription model as well ... this is not
necessarily driven by 0-10, just that the code is a bit "confused"
-- Rob
On 19/06/07, Arnaud Simon <as...@redhat.com> wrote:
> Hello,
>
> Even if we have agreed on meeting in Glasgow sometime between the 21rst
> and the 23rdf of August, I would like us to establish a plan for
> migrating to 0.10. I have added a list of tasks for migrating to 0.10
> (it is based on what Gordon has done for C++). It would be nice to put
> estimate on those tasks and also to allocate them to people (note that
> some tasks may be missing). More generally it would be good to know what
> people involvement for the 0.10 migration is.
>
> ==model:==
> * new query methods for exchange and binding (and possibly queue)
> * minor changes to method arguments etc
> - separation of 'auto-delete' from 'exclusive' in queue.declare
> - removal of responses and no-wait field from several methods
> - 'reject-unroutable' flag
> * new flow control for message transfer
> * new acking method for deliveries
> * dtx - expose basic functionality through client
> * changes to encoding of transfer
>
> ==execution layer:==
> * track execution mark for outgoing requests
> * manage execution mark for incoming framesets
> * generic correlation support (details still vague)
>
> ==session layer:==
> * session abstraction
> - Channel should be Session
> - channel exceptions are now session aborts
> - channel open and close should be altered
> - ack and hwm exchange
> * session management
> - maintain map of detached sessions, with timeouts
> - simple case: sessions destroyed on detach
> - failover: re-attach session to a channel on a new connection
> - manage requested timeout
> * replay buffer management
> - record all outgoing frames along with a sequence number
> - on receipt of an ack, delete as appropriate
> * session re-establishment & replay
> - implement session resumption (broker side only)
> - re-establish connection (client side only)
> - send any frames not seen by peer
>
> ==framing:==
> * new field table encoding (including lots of new value types)
> * new uuid type
> * new type for 'long sets' (for ack structures)
> * revised frame encoding
> * decoding from (& encoding to?) discontinuous data
> * revised architecture (chains, assembly of segments & framesets,
> memory management etc)
>
>