Hi,
Thanks very much. I'll use the 1st option then. I'm don't known thrift
enough to make changes in the underlying lib.
Regards
Julien Gréard
Jaguar Project Manager
Evitech
On 09/28/2018 02:35 PM, James E. King III wrote:
I'm not aware of any thrift language implementations that support push
notification. Today thrift is specifically client and server where client
makes all requests and has no facility to receive out-of-band requests. To
do what you want to do with thrift today, you have a couple choices. The
firewall-friendly solution is to have your server become multiplexed and
implement a second service with an API call that blocks until it gets an
event (remember to make the recvTimeout very long). You would then open
two transport connections to the server and use one for your regular
service, and the other for doing "pull" style notification by having a
thread always blocking and waiting for the next event. You cannot share
clients on the same transport which is why you need to open two
connections. The less firewall-friendly way is to have the client also run
a thrift server that receives events, and make your server connect to the
client., but I'd recommend the first way.
It is possible to add this type of support you are looking for in a single
connection (push notification) but it requires significant changes to the
runtime library. I did this before with C# for an employer, the
implementation is in a zip file in THRIFT-66
<https://issues.apache.org/jira/browse/THRIFT-66>. Those changes contain
more than just the ability to have push notification; in essence it allowed
each side to be a client or a server for a given service. It also contains
a different implementation of multiplex that the project did not use,
however I think the "endpoint" abstraction (allowing each side to be a
client or a server for a given service after the connection is established)
is sound and could be used in other languages to facilitate two-way
communication over a single channel.
- Jim
On Fri, Sep 28, 2018 at 4:20 AM Julien Greard <[email protected]> wrote:
Hi,
I have a thrift client/server application written in Python (both
sides). My server is supposed to send some events to the client and I'd
like to use a publish/suscribe design pattern.
I think it might be possible to use the socket opened by the client from
both sides and after the client opens it, it like to reuse it (sometimes
later) from the server side.
Here is the code I'd like to be able to write (pseudo code):
##########################################
*thrift_client.py*
class ThriftClient:
def connection(self):
# 1st thread
self.connect()
self.suscribe()
def receive_events(self, events)
# Another thread called asynchronously
self.dead_with_events(events)
#########################################
*thrift_server.py*
class ThriftServer:
def suscribe(self):
self.clients.add(self.current_client)
def on_events(self, events):
for client in self.clients:
client.receive_events(events)
##########################################
*service.idl*
void receive_events(list<event>)
void suscribe()
#########################################
Could someone tell me if I'm doing it the wrong way ? I know how to use
one-way services or two-ways services but I don't know
if it's possible to get the client from the server.
So far I've been able to get the socket, but there is a long way to be
able to call a generated method like here receive_events from just
having the socket...
I'd be glad to share some code if it helps.
Thanks !
--
Julien Gréard
Jaguar Project Manager
Evitech
