Hello.
   Why dont you just include java thread local data in every wsgi
request so that wsgi server wont need to make rpc call?
   Architecture where backend should ask frontend back (especially
same thread) before replying original request looks vary bad imo.

2012/5/30 Tobia Conforto <[email protected]>:
> Hello
>
> I need a Python application server with a peculiar 'callback' feature
> and I would like some advice on whether uWSGI is the right tool for the
> job.
>
> The peculiar feature is that the Python application should be able to
> issue back RPC calls to the calling server (some Java software under my
> control) and have the RPCs replied, before returning a response to the
> original WSGI request, all on the same line (tcp connection).
>
> Here is the sequence of calls (please copy and paste it to an editor if
> you are not using a fixed font):
>
>  Java Frontend                                        Python App Server
> =================                                      =================
>
> -----------------
> BEGIN: issue HTTP
> request to Python
>                    (open or grab tcp connection)
>                   ----[WSGI or uWSGI request]---->
>                                                       (some processing)
>                  <-------[some kind of RPC]------
> (Java processing)
>                   -------[RPC return value]------>
>                                                       (more processing)
>                  <----[WSGI / uWSGI response]----
>                    (close or release connection)
> END: process HTTP
> response received
> -----------------
>
> The tricky part is that the RPC call should be made to the same *thread*
> that issued the original WSGI call, not to the server in general.  This
> tells me that the RPC and WSGI calls should be made on the same tcp
> connection, with the same protocol, and that protocol should permit such
> a bi-directional and nested sequence of requests and replies.
>
> Also, after issuing the WSGI request on the channel, the Java client has
> no way to know whether Python will reply with the HTTP response or with
> one or more RPC calls, so the protocol must be that flexible.
>
> I like uWSGI's wealth of features and I'm not afraid to write a client
> for its binary protocol (or the subset I need) in Java, but I would like
> some confirmation that this flow is actually supported by uWSGI.
>
> Which of its features / packets would you recommend for this setup?
>
> In case it is not possible, do you know of any generic binary protocol
> that allows bi-directional nested requests?  Some kind of RPC?  Protocol
> Buffers?  I can always write my own, but I'd rather avoid re-inventing
> the wheel.
>
> -Tobia
> _______________________________________________
> uWSGI mailing list
> [email protected]
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi



-- 
--------------------------------------------
Турнаев Евгений Викторович
+7 906 875 09 43
--------------------------------------------
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to