You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2014/09/18 19:23:34 UTC
Proton tutorial: synchronous request-response
I checked this in on the examples branch.
------------------------------------------------------------------------
r1626029 | aconway | 2014-09-18 13:11:12 -0400 (Thu, 18 Sep 2014) | 7
lines
NO-JIRA: Added tutorial/sync_client.py to demonstrate a synchronous
request-response client.
This client uses the familiar paradigm of making blocking calls that
send a
request and return the response.
Made some improvements to BlockingThread error handling and timeouts.
------------------------------------------------------------------------
It needs a little work to be realistic (needs to check correlation ids
at least) but it is quite neat.
Most of the current tutorial examples are in an event driven style,
which is great for servers and intermediaries but less familiar on the
client side. This demo shows that you can also do traditional
client-driven request response quite easily. The error handling is
simple: invoke() throws if anything goes wrong.
I did this the hard way first - by writing my own raw event handlers. It
was instructive but, well, hard. Then I noticed Gordon's
BlockingConnection class already did everything I had figured out the
hard way (blocking and error handing) so I rewrote it using that and it
was very easy.
So far I think this is promising.
Cheers,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proton tutorial: synchronous request-response
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Wed, Oct 8, 2014 at 4:40 AM, uromahn <ul...@ulrichromahn.net> wrote:
> I just found the proton-demo repo in Github myself and then noticed this
> post.
>
> Good examples and thanks Rafael for putting in the work to write them for
> folks like me who are struggling to comprehend proton-j and how to actually
> use it. I very much appreciate it.
>
> I have one question though: in your demo, you have developed nine rather
> generic classes/interfaces (AbstractEventHandler, EventHandler, Events,
> Driver, FlowController, Handshaker, Message, Pool, Router) which seem to
> establish some good usage patterns. However, they also seem to be essential
> in order to really use proton-j and hence shouldn't they become part of the
> proton-j library?
>
Yes, I intend to pull at least some of them in shortly. (Hopefully for 0.8
RC2.)
I think the *EventHandler stuff is pretty much a no brainer for "core"
proton-j. The other pieces I would like to pull into a "toolkit" area for
components that are useful and should be available, but aren't necessarily
the one and only way of doing things.
--Rafael
Re: Proton tutorial: synchronous request-response
Posted by uromahn <ul...@ulrichromahn.net>.
I just found the proton-demo repo in Github myself and then noticed this
post.
Good examples and thanks Rafael for putting in the work to write them for
folks like me who are struggling to comprehend proton-j and how to actually
use it. I very much appreciate it.
I have one question though: in your demo, you have developed nine rather
generic classes/interfaces (AbstractEventHandler, EventHandler, Events,
Driver, FlowController, Handshaker, Message, Pool, Router) which seem to
establish some good usage patterns. However, they also seem to be essential
in order to really use proton-j and hence shouldn't they become part of the
proton-j library?
-Uli
--
View this message in context: http://qpid.2158936.n2.nabble.com/Proton-tutorial-synchronous-request-response-tp7613826p7614772.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proton tutorial: synchronous request-response
Posted by Rafael Schloming <rh...@alum.mit.edu>.
I expect to put out 0.8 RC2 sometime next week and I would like to have at
least a preview of the demo stuff as part of it. I'm hoping to do some
bigger cleanups to the Java code and work towards API stability in general
for the 0.9 release which I would like to get out sometime in the December
timeframe.
--Rafael
On Wed, Oct 1, 2014 at 1:28 PM, Martin, Jimmy <
jamesmartin@paypal.com.invalid> wrote:
> That’s good to know. Do you have a tentative timeline for this work?
>
> On 10/1/14, 9:55 AM, "Rafael Schloming" <rh...@alum.mit.edu> wrote:
>
> >Yes, right now the demo consists of some shared convenience/utility code
> >along side the Spout, Drain, and Server classes that define the actual
> >client/server behavior. I intend to pull the utility code into proton-j
> >proper and pull in the Spout, Drain, and Server classes (or possibly a
> >simplified/better documented version of them) as examples.
> >
> >--Rafael
> >
> >On Wed, Oct 1, 2014 at 9:58 AM, Martin, Jimmy <
> >jamesmartin@paypal.com.invalid> wrote:
> >
> >> Rafael,
> >>
> >> Do you envision the code in your demo async framework becoming an
> >>official
> >> part of proton-j in the future? I thought you had said something to that
> >> effect in a previous post.
> >>
> >> -Jimmy
> >>
> >> On 10/1/14, 6:54 AM, "Rafael Schloming" <rh...@alum.mit.edu> wrote:
> >>
> >> >I have a set of examples for proton-j that is more current. They were
> >> >developed midway through the 0.8 development cycle so they may need a
> >> >little bit of updating, but I intend to verify that they work against
> >>the
> >> >release, add a bit of docs and include them in 0.8 RC2.
> >> >
> >> >You can check them out here for now:
> >> >
> >> > https://github.com/rhs/qpid-proton-demo
> >> >
> >> >--Rafael
> >> >
> >> >
> >> >On Tue, Sep 30, 2014 at 12:05 PM, Gibson, Jack
> >> ><ja...@paypal.com.invalid>
> >> >wrote:
> >> >
> >> >> Its great to see some more real world use cases being created but how
> >> >> about some proton-j examples? It seems to be woefully behind to the
> >> >>point
> >> >> where even some of the out of the box examples aren¹t fully
> >>functionally
> >> >> anymoreŠ
> >> >>
> >> >> Jack
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On 9/22/14, 12:51 PM, "Alan Conway" <ac...@redhat.com> wrote:
> >> >>
> >> >> >On Thu, 2014-09-18 at 13:33 -0400, Justin Ross wrote:
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>
> http://svn.apache.org/viewvc/qpid/proton/branches/examples/tutorial/sync_
> >> >> >>client.py?view=markup&pathrev=1626029
> >> >> >>
> >> >> >> I think "invoke" is an unintuitive name there. It's not "invoking
> >> >>the
> >> >> >> request" or "invoking the client". Invoke usually implies a named
> >> >> >>piece of
> >> >> >> application logic. I think in this case "send" or "send_request"
> >> >>would
> >> >> >>be
> >> >> >> better, as in "send the request (and this is a request for which I
> >> >> >>expect a
> >> >> >> synchronous response)".
> >> >> >
> >> >> >Yes I don't really like invoke either but I also don't like send. I
> >> >>want
> >> >> >to say: "send a request *and* wait for a response". The word "send"
> >>is
> >> >> >heavily used already in all the messaging APIs to mean "just send a
> >> >> >message".
> >> >> >
> >> >> >I also considered "call". This really is the moral equivalent of an
> >>RPC
> >> >> >(C for "call") The only difference between this and RPC is dressing
> >>it
> >> >> >up as a method call on a proxy object instead of exposing the
> >> >>underlying
> >> >> >message exchange. However given that we want to expose this as a
> >> >>message
> >> >> >exchange, neither "invoke" nor "call" is very satisfying.
> >> >> >
> >> >> >I'd love a better alternative!
> >> >> >
> >> >> >>
> >> >> >> On Thu, Sep 18, 2014 at 1:23 PM, Alan Conway <ac...@redhat.com>
> >> >> wrote:
> >> >> >>
> >> >> >> > I checked this in on the examples branch.
> >> >> >> >
> >> >> >> >
> >> >>
> >>
> >>>>>>---------------------------------------------------------------------
> >>>>>>--
> >> >>>>-
> >> >> >> > r1626029 | aconway | 2014-09-18 13:11:12 -0400 (Thu, 18 Sep
> >>2014)
> >> >>| 7
> >> >> >> > lines
> >> >> >> >
> >> >> >> > NO-JIRA: Added tutorial/sync_client.py to demonstrate a
> >>synchronous
> >> >> >> > request-response client.
> >> >> >> >
> >> >> >> > This client uses the familiar paradigm of making blocking calls
> >> >>that
> >> >> >> > send a
> >> >> >> > request and return the response.
> >> >> >> >
> >> >> >> > Made some improvements to BlockingThread error handling and
> >> >>timeouts.
> >> >> >> >
> >> >> >> >
> >> >>
> >>
> >>>>>>---------------------------------------------------------------------
> >>>>>>--
> >> >>>>-
> >> >> >> >
> >> >> >> > It needs a little work to be realistic (needs to check
> >>correlation
> >> >>ids
> >> >> >> > at least) but it is quite neat.
> >> >> >> >
> >> >> >> > Most of the current tutorial examples are in an event driven
> >>style,
> >> >> >> > which is great for servers and intermediaries but less familiar
> >>on
> >> >>the
> >> >> >> > client side. This demo shows that you can also do traditional
> >> >> >> > client-driven request response quite easily. The error handling
> >>is
> >> >> >> > simple: invoke() throws if anything goes wrong.
> >> >> >> >
> >> >> >> > I did this the hard way first - by writing my own raw event
> >> >>handlers.
> >> >> >>It
> >> >> >> > was instructive but, well, hard. Then I noticed Gordon's
> >> >> >> > BlockingConnection class already did everything I had figured
> >>out
> >> >>the
> >> >> >> > hard way (blocking and error handing) so I rewrote it using that
> >> >>and
> >> >> >>it
> >> >> >> > was very easy.
> >> >> >> >
> >> >> >> > So far I think this is promising.
> >> >> >> >
> >> >> >> > Cheers,
> >> >> >> > Alan.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >>---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> >> > For additional commands, e-mail: users-help@qpid.apache.org
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >>>---------------------------------------------------------------------
> >> >> >To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> >For additional commands, e-mail: users-help@qpid.apache.org
> >> >> >
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>
> >> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: users-help@qpid.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Proton tutorial: synchronous request-response
Posted by "Martin, Jimmy" <ja...@paypal.com.INVALID>.
That’s good to know. Do you have a tentative timeline for this work?
On 10/1/14, 9:55 AM, "Rafael Schloming" <rh...@alum.mit.edu> wrote:
>Yes, right now the demo consists of some shared convenience/utility code
>along side the Spout, Drain, and Server classes that define the actual
>client/server behavior. I intend to pull the utility code into proton-j
>proper and pull in the Spout, Drain, and Server classes (or possibly a
>simplified/better documented version of them) as examples.
>
>--Rafael
>
>On Wed, Oct 1, 2014 at 9:58 AM, Martin, Jimmy <
>jamesmartin@paypal.com.invalid> wrote:
>
>> Rafael,
>>
>> Do you envision the code in your demo async framework becoming an
>>official
>> part of proton-j in the future? I thought you had said something to that
>> effect in a previous post.
>>
>> -Jimmy
>>
>> On 10/1/14, 6:54 AM, "Rafael Schloming" <rh...@alum.mit.edu> wrote:
>>
>> >I have a set of examples for proton-j that is more current. They were
>> >developed midway through the 0.8 development cycle so they may need a
>> >little bit of updating, but I intend to verify that they work against
>>the
>> >release, add a bit of docs and include them in 0.8 RC2.
>> >
>> >You can check them out here for now:
>> >
>> > https://github.com/rhs/qpid-proton-demo
>> >
>> >--Rafael
>> >
>> >
>> >On Tue, Sep 30, 2014 at 12:05 PM, Gibson, Jack
>> ><ja...@paypal.com.invalid>
>> >wrote:
>> >
>> >> Its great to see some more real world use cases being created but how
>> >> about some proton-j examples? It seems to be woefully behind to the
>> >>point
>> >> where even some of the out of the box examples aren¹t fully
>>functionally
>> >> anymoreŠ
>> >>
>> >> Jack
>> >>
>> >>
>> >>
>> >>
>> >> On 9/22/14, 12:51 PM, "Alan Conway" <ac...@redhat.com> wrote:
>> >>
>> >> >On Thu, 2014-09-18 at 13:33 -0400, Justin Ross wrote:
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>http://svn.apache.org/viewvc/qpid/proton/branches/examples/tutorial/sync_
>> >> >>client.py?view=markup&pathrev=1626029
>> >> >>
>> >> >> I think "invoke" is an unintuitive name there. It's not "invoking
>> >>the
>> >> >> request" or "invoking the client". Invoke usually implies a named
>> >> >>piece of
>> >> >> application logic. I think in this case "send" or "send_request"
>> >>would
>> >> >>be
>> >> >> better, as in "send the request (and this is a request for which I
>> >> >>expect a
>> >> >> synchronous response)".
>> >> >
>> >> >Yes I don't really like invoke either but I also don't like send. I
>> >>want
>> >> >to say: "send a request *and* wait for a response". The word "send"
>>is
>> >> >heavily used already in all the messaging APIs to mean "just send a
>> >> >message".
>> >> >
>> >> >I also considered "call". This really is the moral equivalent of an
>>RPC
>> >> >(C for "call") The only difference between this and RPC is dressing
>>it
>> >> >up as a method call on a proxy object instead of exposing the
>> >>underlying
>> >> >message exchange. However given that we want to expose this as a
>> >>message
>> >> >exchange, neither "invoke" nor "call" is very satisfying.
>> >> >
>> >> >I'd love a better alternative!
>> >> >
>> >> >>
>> >> >> On Thu, Sep 18, 2014 at 1:23 PM, Alan Conway <ac...@redhat.com>
>> >> wrote:
>> >> >>
>> >> >> > I checked this in on the examples branch.
>> >> >> >
>> >> >> >
>> >>
>>
>>>>>>---------------------------------------------------------------------
>>>>>>--
>> >>>>-
>> >> >> > r1626029 | aconway | 2014-09-18 13:11:12 -0400 (Thu, 18 Sep
>>2014)
>> >>| 7
>> >> >> > lines
>> >> >> >
>> >> >> > NO-JIRA: Added tutorial/sync_client.py to demonstrate a
>>synchronous
>> >> >> > request-response client.
>> >> >> >
>> >> >> > This client uses the familiar paradigm of making blocking calls
>> >>that
>> >> >> > send a
>> >> >> > request and return the response.
>> >> >> >
>> >> >> > Made some improvements to BlockingThread error handling and
>> >>timeouts.
>> >> >> >
>> >> >> >
>> >>
>>
>>>>>>---------------------------------------------------------------------
>>>>>>--
>> >>>>-
>> >> >> >
>> >> >> > It needs a little work to be realistic (needs to check
>>correlation
>> >>ids
>> >> >> > at least) but it is quite neat.
>> >> >> >
>> >> >> > Most of the current tutorial examples are in an event driven
>>style,
>> >> >> > which is great for servers and intermediaries but less familiar
>>on
>> >>the
>> >> >> > client side. This demo shows that you can also do traditional
>> >> >> > client-driven request response quite easily. The error handling
>>is
>> >> >> > simple: invoke() throws if anything goes wrong.
>> >> >> >
>> >> >> > I did this the hard way first - by writing my own raw event
>> >>handlers.
>> >> >>It
>> >> >> > was instructive but, well, hard. Then I noticed Gordon's
>> >> >> > BlockingConnection class already did everything I had figured
>>out
>> >>the
>> >> >> > hard way (blocking and error handing) so I rewrote it using that
>> >>and
>> >> >>it
>> >> >> > was very easy.
>> >> >> >
>> >> >> > So far I think this is promising.
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Alan.
>> >> >> >
>> >> >> >
>> >> >> >
>> >>---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >> > For additional commands, e-mail: users-help@qpid.apache.org
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >>
>>>---------------------------------------------------------------------
>> >> >To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> >For additional commands, e-mail: users-help@qpid.apache.org
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> For additional commands, e-mail: users-help@qpid.apache.org
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proton tutorial: synchronous request-response
Posted by Rafael Schloming <rh...@alum.mit.edu>.
Yes, right now the demo consists of some shared convenience/utility code
along side the Spout, Drain, and Server classes that define the actual
client/server behavior. I intend to pull the utility code into proton-j
proper and pull in the Spout, Drain, and Server classes (or possibly a
simplified/better documented version of them) as examples.
--Rafael
On Wed, Oct 1, 2014 at 9:58 AM, Martin, Jimmy <
jamesmartin@paypal.com.invalid> wrote:
> Rafael,
>
> Do you envision the code in your demo async framework becoming an official
> part of proton-j in the future? I thought you had said something to that
> effect in a previous post.
>
> -Jimmy
>
> On 10/1/14, 6:54 AM, "Rafael Schloming" <rh...@alum.mit.edu> wrote:
>
> >I have a set of examples for proton-j that is more current. They were
> >developed midway through the 0.8 development cycle so they may need a
> >little bit of updating, but I intend to verify that they work against the
> >release, add a bit of docs and include them in 0.8 RC2.
> >
> >You can check them out here for now:
> >
> > https://github.com/rhs/qpid-proton-demo
> >
> >--Rafael
> >
> >
> >On Tue, Sep 30, 2014 at 12:05 PM, Gibson, Jack
> ><ja...@paypal.com.invalid>
> >wrote:
> >
> >> Its great to see some more real world use cases being created but how
> >> about some proton-j examples? It seems to be woefully behind to the
> >>point
> >> where even some of the out of the box examples aren¹t fully functionally
> >> anymoreŠ
> >>
> >> Jack
> >>
> >>
> >>
> >>
> >> On 9/22/14, 12:51 PM, "Alan Conway" <ac...@redhat.com> wrote:
> >>
> >> >On Thu, 2014-09-18 at 13:33 -0400, Justin Ross wrote:
> >> >>
> >> >>
> >>
> >>
> http://svn.apache.org/viewvc/qpid/proton/branches/examples/tutorial/sync_
> >> >>client.py?view=markup&pathrev=1626029
> >> >>
> >> >> I think "invoke" is an unintuitive name there. It's not "invoking
> >>the
> >> >> request" or "invoking the client". Invoke usually implies a named
> >> >>piece of
> >> >> application logic. I think in this case "send" or "send_request"
> >>would
> >> >>be
> >> >> better, as in "send the request (and this is a request for which I
> >> >>expect a
> >> >> synchronous response)".
> >> >
> >> >Yes I don't really like invoke either but I also don't like send. I
> >>want
> >> >to say: "send a request *and* wait for a response". The word "send" is
> >> >heavily used already in all the messaging APIs to mean "just send a
> >> >message".
> >> >
> >> >I also considered "call". This really is the moral equivalent of an RPC
> >> >(C for "call") The only difference between this and RPC is dressing it
> >> >up as a method call on a proxy object instead of exposing the
> >>underlying
> >> >message exchange. However given that we want to expose this as a
> >>message
> >> >exchange, neither "invoke" nor "call" is very satisfying.
> >> >
> >> >I'd love a better alternative!
> >> >
> >> >>
> >> >> On Thu, Sep 18, 2014 at 1:23 PM, Alan Conway <ac...@redhat.com>
> >> wrote:
> >> >>
> >> >> > I checked this in on the examples branch.
> >> >> >
> >> >> >
> >>
> >>>>-----------------------------------------------------------------------
> >>>>-
> >> >> > r1626029 | aconway | 2014-09-18 13:11:12 -0400 (Thu, 18 Sep 2014)
> >>| 7
> >> >> > lines
> >> >> >
> >> >> > NO-JIRA: Added tutorial/sync_client.py to demonstrate a synchronous
> >> >> > request-response client.
> >> >> >
> >> >> > This client uses the familiar paradigm of making blocking calls
> >>that
> >> >> > send a
> >> >> > request and return the response.
> >> >> >
> >> >> > Made some improvements to BlockingThread error handling and
> >>timeouts.
> >> >> >
> >> >> >
> >>
> >>>>-----------------------------------------------------------------------
> >>>>-
> >> >> >
> >> >> > It needs a little work to be realistic (needs to check correlation
> >>ids
> >> >> > at least) but it is quite neat.
> >> >> >
> >> >> > Most of the current tutorial examples are in an event driven style,
> >> >> > which is great for servers and intermediaries but less familiar on
> >>the
> >> >> > client side. This demo shows that you can also do traditional
> >> >> > client-driven request response quite easily. The error handling is
> >> >> > simple: invoke() throws if anything goes wrong.
> >> >> >
> >> >> > I did this the hard way first - by writing my own raw event
> >>handlers.
> >> >>It
> >> >> > was instructive but, well, hard. Then I noticed Gordon's
> >> >> > BlockingConnection class already did everything I had figured out
> >>the
> >> >> > hard way (blocking and error handing) so I rewrote it using that
> >>and
> >> >>it
> >> >> > was very easy.
> >> >> >
> >> >> > So far I think this is promising.
> >> >> >
> >> >> > Cheers,
> >> >> > Alan.
> >> >> >
> >> >> >
> >> >> >
> >>---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> > For additional commands, e-mail: users-help@qpid.apache.org
> >> >> >
> >> >> >
> >> >
> >> >
> >> >
> >> >---------------------------------------------------------------------
> >> >To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >For additional commands, e-mail: users-help@qpid.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: users-help@qpid.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Proton tutorial: synchronous request-response
Posted by "Martin, Jimmy" <ja...@paypal.com.INVALID>.
Rafael,
Do you envision the code in your demo async framework becoming an official
part of proton-j in the future? I thought you had said something to that
effect in a previous post.
-Jimmy
On 10/1/14, 6:54 AM, "Rafael Schloming" <rh...@alum.mit.edu> wrote:
>I have a set of examples for proton-j that is more current. They were
>developed midway through the 0.8 development cycle so they may need a
>little bit of updating, but I intend to verify that they work against the
>release, add a bit of docs and include them in 0.8 RC2.
>
>You can check them out here for now:
>
> https://github.com/rhs/qpid-proton-demo
>
>--Rafael
>
>
>On Tue, Sep 30, 2014 at 12:05 PM, Gibson, Jack
><ja...@paypal.com.invalid>
>wrote:
>
>> Its great to see some more real world use cases being created but how
>> about some proton-j examples? It seems to be woefully behind to the
>>point
>> where even some of the out of the box examples aren¹t fully functionally
>> anymoreŠ
>>
>> Jack
>>
>>
>>
>>
>> On 9/22/14, 12:51 PM, "Alan Conway" <ac...@redhat.com> wrote:
>>
>> >On Thu, 2014-09-18 at 13:33 -0400, Justin Ross wrote:
>> >>
>> >>
>>
>>http://svn.apache.org/viewvc/qpid/proton/branches/examples/tutorial/sync_
>> >>client.py?view=markup&pathrev=1626029
>> >>
>> >> I think "invoke" is an unintuitive name there. It's not "invoking
>>the
>> >> request" or "invoking the client". Invoke usually implies a named
>> >>piece of
>> >> application logic. I think in this case "send" or "send_request"
>>would
>> >>be
>> >> better, as in "send the request (and this is a request for which I
>> >>expect a
>> >> synchronous response)".
>> >
>> >Yes I don't really like invoke either but I also don't like send. I
>>want
>> >to say: "send a request *and* wait for a response". The word "send" is
>> >heavily used already in all the messaging APIs to mean "just send a
>> >message".
>> >
>> >I also considered "call". This really is the moral equivalent of an RPC
>> >(C for "call") The only difference between this and RPC is dressing it
>> >up as a method call on a proxy object instead of exposing the
>>underlying
>> >message exchange. However given that we want to expose this as a
>>message
>> >exchange, neither "invoke" nor "call" is very satisfying.
>> >
>> >I'd love a better alternative!
>> >
>> >>
>> >> On Thu, Sep 18, 2014 at 1:23 PM, Alan Conway <ac...@redhat.com>
>> wrote:
>> >>
>> >> > I checked this in on the examples branch.
>> >> >
>> >> >
>>
>>>>-----------------------------------------------------------------------
>>>>-
>> >> > r1626029 | aconway | 2014-09-18 13:11:12 -0400 (Thu, 18 Sep 2014)
>>| 7
>> >> > lines
>> >> >
>> >> > NO-JIRA: Added tutorial/sync_client.py to demonstrate a synchronous
>> >> > request-response client.
>> >> >
>> >> > This client uses the familiar paradigm of making blocking calls
>>that
>> >> > send a
>> >> > request and return the response.
>> >> >
>> >> > Made some improvements to BlockingThread error handling and
>>timeouts.
>> >> >
>> >> >
>>
>>>>-----------------------------------------------------------------------
>>>>-
>> >> >
>> >> > It needs a little work to be realistic (needs to check correlation
>>ids
>> >> > at least) but it is quite neat.
>> >> >
>> >> > Most of the current tutorial examples are in an event driven style,
>> >> > which is great for servers and intermediaries but less familiar on
>>the
>> >> > client side. This demo shows that you can also do traditional
>> >> > client-driven request response quite easily. The error handling is
>> >> > simple: invoke() throws if anything goes wrong.
>> >> >
>> >> > I did this the hard way first - by writing my own raw event
>>handlers.
>> >>It
>> >> > was instructive but, well, hard. Then I noticed Gordon's
>> >> > BlockingConnection class already did everything I had figured out
>>the
>> >> > hard way (blocking and error handing) so I rewrote it using that
>>and
>> >>it
>> >> > was very easy.
>> >> >
>> >> > So far I think this is promising.
>> >> >
>> >> > Cheers,
>> >> > Alan.
>> >> >
>> >> >
>> >> >
>>---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> > For additional commands, e-mail: users-help@qpid.apache.org
>> >> >
>> >> >
>> >
>> >
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >For additional commands, e-mail: users-help@qpid.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proton tutorial: synchronous request-response
Posted by Rafael Schloming <rh...@alum.mit.edu>.
I have a set of examples for proton-j that is more current. They were
developed midway through the 0.8 development cycle so they may need a
little bit of updating, but I intend to verify that they work against the
release, add a bit of docs and include them in 0.8 RC2.
You can check them out here for now:
https://github.com/rhs/qpid-proton-demo
--Rafael
On Tue, Sep 30, 2014 at 12:05 PM, Gibson, Jack <ja...@paypal.com.invalid>
wrote:
> Its great to see some more real world use cases being created but how
> about some proton-j examples? It seems to be woefully behind to the point
> where even some of the out of the box examples aren¹t fully functionally
> anymoreŠ
>
> Jack
>
>
>
>
> On 9/22/14, 12:51 PM, "Alan Conway" <ac...@redhat.com> wrote:
>
> >On Thu, 2014-09-18 at 13:33 -0400, Justin Ross wrote:
> >>
> >>
> http://svn.apache.org/viewvc/qpid/proton/branches/examples/tutorial/sync_
> >>client.py?view=markup&pathrev=1626029
> >>
> >> I think "invoke" is an unintuitive name there. It's not "invoking the
> >> request" or "invoking the client". Invoke usually implies a named
> >>piece of
> >> application logic. I think in this case "send" or "send_request" would
> >>be
> >> better, as in "send the request (and this is a request for which I
> >>expect a
> >> synchronous response)".
> >
> >Yes I don't really like invoke either but I also don't like send. I want
> >to say: "send a request *and* wait for a response". The word "send" is
> >heavily used already in all the messaging APIs to mean "just send a
> >message".
> >
> >I also considered "call". This really is the moral equivalent of an RPC
> >(C for "call") The only difference between this and RPC is dressing it
> >up as a method call on a proxy object instead of exposing the underlying
> >message exchange. However given that we want to expose this as a message
> >exchange, neither "invoke" nor "call" is very satisfying.
> >
> >I'd love a better alternative!
> >
> >>
> >> On Thu, Sep 18, 2014 at 1:23 PM, Alan Conway <ac...@redhat.com>
> wrote:
> >>
> >> > I checked this in on the examples branch.
> >> >
> >> >
> >>------------------------------------------------------------------------
> >> > r1626029 | aconway | 2014-09-18 13:11:12 -0400 (Thu, 18 Sep 2014) | 7
> >> > lines
> >> >
> >> > NO-JIRA: Added tutorial/sync_client.py to demonstrate a synchronous
> >> > request-response client.
> >> >
> >> > This client uses the familiar paradigm of making blocking calls that
> >> > send a
> >> > request and return the response.
> >> >
> >> > Made some improvements to BlockingThread error handling and timeouts.
> >> >
> >> >
> >>------------------------------------------------------------------------
> >> >
> >> > It needs a little work to be realistic (needs to check correlation ids
> >> > at least) but it is quite neat.
> >> >
> >> > Most of the current tutorial examples are in an event driven style,
> >> > which is great for servers and intermediaries but less familiar on the
> >> > client side. This demo shows that you can also do traditional
> >> > client-driven request response quite easily. The error handling is
> >> > simple: invoke() throws if anything goes wrong.
> >> >
> >> > I did this the hard way first - by writing my own raw event handlers.
> >>It
> >> > was instructive but, well, hard. Then I noticed Gordon's
> >> > BlockingConnection class already did everything I had figured out the
> >> > hard way (blocking and error handing) so I rewrote it using that and
> >>it
> >> > was very easy.
> >> >
> >> > So far I think this is promising.
> >> >
> >> > Cheers,
> >> > Alan.
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> > For additional commands, e-mail: users-help@qpid.apache.org
> >> >
> >> >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >For additional commands, e-mail: users-help@qpid.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Proton tutorial: synchronous request-response
Posted by "Gibson, Jack" <ja...@paypal.com.INVALID>.
Its great to see some more real world use cases being created but how
about some proton-j examples? It seems to be woefully behind to the point
where even some of the out of the box examples aren¹t fully functionally
anymoreŠ
Jack
On 9/22/14, 12:51 PM, "Alan Conway" <ac...@redhat.com> wrote:
>On Thu, 2014-09-18 at 13:33 -0400, Justin Ross wrote:
>>
>>http://svn.apache.org/viewvc/qpid/proton/branches/examples/tutorial/sync_
>>client.py?view=markup&pathrev=1626029
>>
>> I think "invoke" is an unintuitive name there. It's not "invoking the
>> request" or "invoking the client". Invoke usually implies a named
>>piece of
>> application logic. I think in this case "send" or "send_request" would
>>be
>> better, as in "send the request (and this is a request for which I
>>expect a
>> synchronous response)".
>
>Yes I don't really like invoke either but I also don't like send. I want
>to say: "send a request *and* wait for a response". The word "send" is
>heavily used already in all the messaging APIs to mean "just send a
>message".
>
>I also considered "call". This really is the moral equivalent of an RPC
>(C for "call") The only difference between this and RPC is dressing it
>up as a method call on a proxy object instead of exposing the underlying
>message exchange. However given that we want to expose this as a message
>exchange, neither "invoke" nor "call" is very satisfying.
>
>I'd love a better alternative!
>
>>
>> On Thu, Sep 18, 2014 at 1:23 PM, Alan Conway <ac...@redhat.com> wrote:
>>
>> > I checked this in on the examples branch.
>> >
>> >
>>------------------------------------------------------------------------
>> > r1626029 | aconway | 2014-09-18 13:11:12 -0400 (Thu, 18 Sep 2014) | 7
>> > lines
>> >
>> > NO-JIRA: Added tutorial/sync_client.py to demonstrate a synchronous
>> > request-response client.
>> >
>> > This client uses the familiar paradigm of making blocking calls that
>> > send a
>> > request and return the response.
>> >
>> > Made some improvements to BlockingThread error handling and timeouts.
>> >
>> >
>>------------------------------------------------------------------------
>> >
>> > It needs a little work to be realistic (needs to check correlation ids
>> > at least) but it is quite neat.
>> >
>> > Most of the current tutorial examples are in an event driven style,
>> > which is great for servers and intermediaries but less familiar on the
>> > client side. This demo shows that you can also do traditional
>> > client-driven request response quite easily. The error handling is
>> > simple: invoke() throws if anything goes wrong.
>> >
>> > I did this the hard way first - by writing my own raw event handlers.
>>It
>> > was instructive but, well, hard. Then I noticed Gordon's
>> > BlockingConnection class already did everything I had figured out the
>> > hard way (blocking and error handing) so I rewrote it using that and
>>it
>> > was very easy.
>> >
>> > So far I think this is promising.
>> >
>> > Cheers,
>> > Alan.
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: users-help@qpid.apache.org
>> >
>> >
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proton tutorial: synchronous request-response
Posted by Alan Conway <ac...@redhat.com>.
On Thu, 2014-09-18 at 13:33 -0400, Justin Ross wrote:
> http://svn.apache.org/viewvc/qpid/proton/branches/examples/tutorial/sync_client.py?view=markup&pathrev=1626029
>
> I think "invoke" is an unintuitive name there. It's not "invoking the
> request" or "invoking the client". Invoke usually implies a named piece of
> application logic. I think in this case "send" or "send_request" would be
> better, as in "send the request (and this is a request for which I expect a
> synchronous response)".
Yes I don't really like invoke either but I also don't like send. I want
to say: "send a request *and* wait for a response". The word "send" is
heavily used already in all the messaging APIs to mean "just send a
message".
I also considered "call". This really is the moral equivalent of an RPC
(C for "call") The only difference between this and RPC is dressing it
up as a method call on a proxy object instead of exposing the underlying
message exchange. However given that we want to expose this as a message
exchange, neither "invoke" nor "call" is very satisfying.
I'd love a better alternative!
>
> On Thu, Sep 18, 2014 at 1:23 PM, Alan Conway <ac...@redhat.com> wrote:
>
> > I checked this in on the examples branch.
> >
> > ------------------------------------------------------------------------
> > r1626029 | aconway | 2014-09-18 13:11:12 -0400 (Thu, 18 Sep 2014) | 7
> > lines
> >
> > NO-JIRA: Added tutorial/sync_client.py to demonstrate a synchronous
> > request-response client.
> >
> > This client uses the familiar paradigm of making blocking calls that
> > send a
> > request and return the response.
> >
> > Made some improvements to BlockingThread error handling and timeouts.
> >
> > ------------------------------------------------------------------------
> >
> > It needs a little work to be realistic (needs to check correlation ids
> > at least) but it is quite neat.
> >
> > Most of the current tutorial examples are in an event driven style,
> > which is great for servers and intermediaries but less familiar on the
> > client side. This demo shows that you can also do traditional
> > client-driven request response quite easily. The error handling is
> > simple: invoke() throws if anything goes wrong.
> >
> > I did this the hard way first - by writing my own raw event handlers. It
> > was instructive but, well, hard. Then I noticed Gordon's
> > BlockingConnection class already did everything I had figured out the
> > hard way (blocking and error handing) so I rewrote it using that and it
> > was very easy.
> >
> > So far I think this is promising.
> >
> > Cheers,
> > Alan.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proton tutorial: synchronous request-response
Posted by Justin Ross <ju...@gmail.com>.
http://svn.apache.org/viewvc/qpid/proton/branches/examples/tutorial/sync_client.py?view=markup&pathrev=1626029
I think "invoke" is an unintuitive name there. It's not "invoking the
request" or "invoking the client". Invoke usually implies a named piece of
application logic. I think in this case "send" or "send_request" would be
better, as in "send the request (and this is a request for which I expect a
synchronous response)".
On Thu, Sep 18, 2014 at 1:23 PM, Alan Conway <ac...@redhat.com> wrote:
> I checked this in on the examples branch.
>
> ------------------------------------------------------------------------
> r1626029 | aconway | 2014-09-18 13:11:12 -0400 (Thu, 18 Sep 2014) | 7
> lines
>
> NO-JIRA: Added tutorial/sync_client.py to demonstrate a synchronous
> request-response client.
>
> This client uses the familiar paradigm of making blocking calls that
> send a
> request and return the response.
>
> Made some improvements to BlockingThread error handling and timeouts.
>
> ------------------------------------------------------------------------
>
> It needs a little work to be realistic (needs to check correlation ids
> at least) but it is quite neat.
>
> Most of the current tutorial examples are in an event driven style,
> which is great for servers and intermediaries but less familiar on the
> client side. This demo shows that you can also do traditional
> client-driven request response quite easily. The error handling is
> simple: invoke() throws if anything goes wrong.
>
> I did this the hard way first - by writing my own raw event handlers. It
> was instructive but, well, hard. Then I noticed Gordon's
> BlockingConnection class already did everything I had figured out the
> hard way (blocking and error handing) so I rewrote it using that and it
> was very easy.
>
> So far I think this is promising.
>
> Cheers,
> Alan.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>