Rupert Smith wrote:
Another question.
I noticed in the example frames in the stub code, that there are two
exchange declare methods:
frame(Frame.L3, Frame.METHOD, true, true, (short) 1);
frame(Frame.L1, Frame.METHOD, true, true, (short) 1);
The first is handled in the context of a session, and the second in the
context of a channel.
This is because the Stub.java class was written back before I had code
being generated, and as I had to write each generated class by hand aat
that point I just reused ExchangeDeclare for my example.
More recently I have been working with ToyBroker.java and ToyClient.java
you may want to take a look at these classes for a more up to date example.
I have been trying out different ways of presenting the API for this, and
fitting a set of interfaces onto this stub code, along the lines of the
closely following the protocol idea. I had something like:
interface ExchangeClass
{
public void exchangeDeclare(Session context, MethodExchangeDeclare);
}
So the call for the first frame was happy because it could pass in the
session that handled the method to the delegate that processes it. I ran
into problems with the second call because it was not in a session context,
but handled at the channel level.
I'm not quite sure what you mean by this. The generated code follows the
protocol exactly. Also I'm a bit confused by why you would be using a
delegate on the output side. Here's my attempt to summarize the API the
way it is currently set up.
Output:
The Session class contains one java method for each protocol method.
These methods come in two variants, void methods:
void fooMethod(arg1, arg2, ...);
And methods with results:
Future<FooQueryResult> fooQueryMethod(arg1, arg2, ...);
If a method has a payload, e.g. messageTransfer, the method invocation
may be followed by headers and data like so:
ssn.messageTransfer(destination, confirmMode, acquireMode);
ssn.headers(new DeliveryProperties().routingKey(blah).ttl(blah),
new MessageProperties().messageId(blah).contentType(blah));
ssn.data("message data part 1");
ssn.data("message data part 2");
ssn.end();
Everything in this API is asynchronous. There are two ways to synchronize:
(1) For a method with a result, Future.get() will automatically wait
for that specific result.
(2) There is a Session.sync() method that waits for all outstanding
commands to complete.
Input:
SessionDelegate is the entry point for input. There is a callback on
SessionDelegate for each protocol method:
void fooMethod(Session ssn, FooMethod foo);
There is also a callback for headers:
void headers(Session ssn, Struct ...);
And a callback for incoming data frames:
void data(Session ssn, Frame frame);
There is a ConnectionDelegate that controls how SessionDelegates are
created:
SessionDelegate getSessionDelegate();
This permits SessionDelegates to be both stateless (same delegate shared
for all sessions) or stateful (one delegate per session).
ToyBroker and ToyClient have examples of all of this.
If I can do things both inside and outside of sessions, I probably want to
do everything in a channel context, using an attached session if one is
available.
This is in effect what is happening, however rather than having each
delegate that uses the session try to grab it on its own and check if
it's not null and in the appropriate state, the handler chain inside
Channel.java intercepts all methods at the L3 and L4 layer, translates
from a Event<Channel,?> to an Event<Session,?> and invokes a
Delegate<Session>. You could construct a handler chain that did
everything with a Delegate<Channel> as the generated code doesn't care
what context you use for handling the incoming methods, however I chose
this way as it centralizes the Session lookup.
Again, this probably comes down to my 0-10 ignorance. In 0-10 can I do an
exchange declare outside of a session? Are sessions only to be used for
transactional messaging or something? If I do an exchange declare within a
session, is it transactional? that is, not visible until commit, and can be
rolled back?
ExchangeDeclare can only be done on a Session, and transactional
semantics have only been defined for message transfer.
--Rafael
Rupert
On 08/08/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
So the client and broker can both manage channels, without having to send
any commands in order to do so. But there still has to be a channel object
in the communication layer, that provides the context in which session
open/attach takes place.
Thanks, that explains it for me.
Rupert
On 08/08/07, Rafael Schloming <[EMAIL PROTECTED]> wrote:
Rupert Smith wrote:
So, is there a command to open or create a session, and then another
to
attach it to a channel.
+ a command to open/create a channel on a connection?
All I've really seen of 0-10 so far, is the amqp.0-10-preview.xml,
that has
been checked in on trunk. That doesn't have a 'channel' class in it
(yet?).
In 0-10 the term channel refers to the physical transport for a session,
and although at any given point a session may only be attached to a
single channel, over it's lifespan a session may be connected to
multiple channels.
AMQP assumes that channels are purely a mechanism for multiplexing a
connection, so logically when a connection is established, the whole
range of permitted channels (0 to the negotiated MAX) are ready and
available for use.
The only thing you can actually do to a channel in AMQP without a
session being attached to it is to either open or resume a session, so
at the moment at least there is no need for a channel class.
--Rafael
Rupert
On 08/08/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
In 0-10...
A TCP connection has many channels... (same as 0-8)
A Session may have a lifetime that exceeds the lifetime of a single
connection.
A session may be attached to a (single) channel.
It may then be detached, and later re-attached to a separate channel
on
the
same or a different connection.
After a Session has been detached from a channel (or after the
session has
been clsed) a different session may attach to that channel.
Hope this helps,
Rob
On 08/08/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
Hi, I had another look at this code and have another question. I am
not
particularly well versed yet with the 0-10 protocol, so this may
just be
my
ignorance. Is 'channel' in 0-8 renamed to 'session' for 0-10, and
completely
dropped from the 0-10 protocol? Or does 0-10 have both channels and
sessions?
Reason I ask is because the stub has connection, channel and
session.
Sessions are opened on channels. Connection can have many channels,
but
session and channel are always tied together 1:1.
Should it be that connection can have many sessions and the session
open
method is handled at the connection level?
Rupert
On 18/07/07, Rafael Schloming <[EMAIL PROTECTED]> wrote:
Here are some stubs I've been working on that describe most of the
communication layer. For those who like dealing directly with code,
please dig in. I will be following up with some UML and a higher
level
description tomorrow.
--Rafael
