cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Cohen <sco...@javactivity.org>
Subject Re: Using CXF asynchronously
Date Tue, 09 Nov 2010 19:28:27 GMT
I'm feeling about now that my original architectural question has been 
hijacked by a bug report.


On 11/09/2010 01:19 PM, Daniel Kulp wrote:
> 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.
>


Mime
View raw message