cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Villoud Pierre Julien <pierre-julien.vill...@atosorigin.com>
Subject RE: Using CXF asynchronously
Date Wed, 10 Nov 2010 15:19:06 GMT
Hi and thanks for your answer (@Steve I'm sorry, I didn't mean to steal your question...)

I'm using the 2.2.10 version. So what happens if a lot of call like this happen :
client.invoke(new ClientCallback(), "methodName", params...);

You think that the request should timeout ? I'm really not expecting anything in return that's
why i'm calling the invoke function like this. I have a Hello World method but I don't have
much time to test. If it's not something you already have heard of, I will go back to synchronous
calls and work on that as soon as I can.

Thanks again

Pierre-Julien

-----Message d'origine-----
De : Daniel Kulp [mailto:dkulp@apache.org]
Envoyé : mardi 9 novembre 2010 20:19
À : users@cxf.apache.org
Cc : Villoud Pierre Julien
Objet : Re: Using CXF asynchronously

On Tuesday 09 November 2010 12:46:19 pm Villoud Pierre Julien wrote:
> About asynchronism, I'm using the asynchronism mecanism of CXF by calling
> the invoke method like that :
>
> client.invoke(new ClientCallback(), "methodName", params...);
>
> And after a while, I'm getting Out of Memory errors and cxf is complaining
> about not being able to create a new thread... I must restart the service
> to purge the memory. Is is possible de call the invoke method and not
> expects a callback, for instance by calling :
>
> client.invoke(null, "methodName", params...);
>
> Is this method creating a new thread for each callback, and since mine is
> not used, stays in memory ?
>

Hmm... what version of CXF?  At one point long ago, we were creating a new
thread for all of this.   However, we changed that to adding them to the
workqueue so that it can be configured and bounded.

While waiting for a response, they would consume memory and such.   However,
with HTTP, at some point, those request SHOULD timeout and trigger the
callback, release the resources, etc...

Is there any way to reproduce this with some sort of async hello world or
something?

Dan




> Thanks in advance
>
> Pierre-Julien
>
> -----Message d'origine-----
> De : Steve Cohen [mailto:scohen@javactivity.org]
> Envoyé : mardi 9 novembre 2010 18:12
> À : users@cxf.apache.org
> Objet : Using CXF asynchronously
>
> The company I work for is rearchitecting operator workstations for a
> legacy telephony application.
>
> The legacy workstation still runs on MS-DOS(!) and communicates with a
> legacy backend, both client and server written in C.  The "interface"
> such as it is, is a bunch of C header files.  Data is passed by datagram
> between client and server and the headers are needed on both sides to
> make sense of the data.  Since none of the people who developed this 20
> years ago will be around, maintenance is a nightmare.
>
> Probably because of its origins in a pre-multithreading universe, this
> system was developed using primarily asynchronous methods.  Client sends
> a datagram to server, makes no attempt to wait for a return.  Server
> periodically sends "synchronization" messages to client (sometimes
> triggered by the results of methods invoked by the datagrams from the
> client).  These synchronization methods are also by datagram.
>
> Since the server-side is NOT going to be totally rewritten. and must,
> after the rewrite, continue to support the old operator workstations as
> well as the new ones, the scheme I am thinking of is as follows:
>
> 1). add an Apache Web Server to the server and a CXF wrapper around the
> existing server functionality.
>
> 2) rewrite the Client as a java swing application that encompasses a CXF
> client.
>
> 3) each operation now initiated from the client will be an asynchronous
> Web Service call.  These calls would be one-way
>
> 4) to handle the synchronization requirement mentioned above, I am
> envisioning a separate thread in the client that makes an asynchronous
> "RegisterForSynchMessages()" call to the server.  This would be polled
> continually and would expect REPEATED messages through this channel.
> That is, the server side handler for this call must continue to run even
> after it sends a response.  It will never complete and must continue to
> send such responses back through the channel.
>
> Is this achievable using CXF's asynchronous support?
>
>
>
> Ce message et les pièces jointes sont confidentiels et réservés à l'usage
> exclusif de ses destinataires. Il peut également être protégé par le
> secret professionnel. Si vous recevez ce message par erreur, merci d'en
> avertir immédiatement l'expéditeur et de le détruire. L'intégrité du
> message ne pouvant être assurée sur Internet, la responsabilité du groupe
> Atos Origin ne pourra être recherchée quant au contenu de ce message. Bien
> que les meilleurs efforts soient faits pour maintenir cette transmission
> exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard
> et sa responsabilité ne saurait être recherchée pour tout dommage
> résultant d'un virus transmis.
>
> This e-mail and the documents attached are confidential and intended solely
> for the addressee; it may also be privileged. If you receive this e-mail
> in error, please notify the sender immediately and destroy it. As its
> integrity cannot be secured on the Internet, the Atos Origin group
> liability cannot be triggered for the message content. Although the sender
> endeavours to maintain a computer virus-free network, the sender does not
> warrant that this transmission is virus-free and will not be liable for
> any damages resulting from any virus transmitted.

--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog



Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de
ses destinataires. Il peut également être protégé par le secret professionnel. Si vous
recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire.
L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe
Atos Origin ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs
efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur
ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée
pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee;
it may also be privileged. If you receive this e-mail in error, please notify the sender immediately
and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group
liability cannot be triggered for the message content. Although the sender endeavours to maintain
a computer virus-free network, the sender does not warrant that this transmission is virus-free
and will not be liable for any damages resulting from any virus transmitted.


Mime
View raw message