Punnoose, Roshan wrote: > I'm sorry to confuse, by ACK I mean a status message as to the progress > of the request. I want the server to be able to send back many responses > to one client request. This means pushing back the response to the > client endpoint many times, while the client uses the callback to > process each response. > Ok, but this way you loose the main advantage of asynchronous invocations (i.e. the client can do something different in the meantime. If you send "acks", the client computation is interrupted).
> So to create the sender, I only need to set the To to the ReplyTo from > the request right? Before submitting the request, the client specifies the 'To'. The 'From' and 'ReplyTo' headers are the same, if the client does not specify the opposite, so: ----- client options.setTo(new EndpointReference(<service_endpoint>); .... sender.sendReceiveNonBlocking(request); ----- server // receives the request and gets the message context implementing the // Service interface (see http://www.wso2.net/kb/106) // if now you want to send your 'ack' sender = create service client .... options.setTo(inMsgCtx.getFrom()); ... sender.fireAndForget(ack); ... I think it should be that simple. (Probably should > have a RelatesTo for the message id also) > Yes, probably you'll need the RelatesTo in you ack messages. Michele > Roshan Punnoose > Phone: 301-497-6039 > > -----Original Message----- > From: Michele Mazzucco [mailto:[EMAIL PROTECTED] > Sent: Friday, September 15, 2006 3:50 AM > To: [email protected] > Subject: Re: [Axis2] NonBlocking Client > > > > Punnoose, Roshan wrote: >> What I am trying to do is return multiple times from the service. So > the >> service could return ACKs till it is finally ready to return the > correct >> document. So I thought that when the client first calls, I would > return >> an ACK and kick off another thread to do some real processing. Then at >> the end of that thread, would I have to create a client on the server >> side to talk back to my client's callback? > > Yes, but your design makes no sense to me. Let me explain. If the client > is set up for non blocking invocation, it will wait until a result (or > an error) is received. Meantime, the client is free to do whatever it > wants. If the client is set up for blocking invocation, instead, it > waits until the result (or error) is ready. So you don't need to send an > ack to let the client know that the server has received the client > request. > Anyway, if you really want to do what you say, it would be much better > the following solution (assume you're using AXIOM and RawXXX receivers): > > > public OMElement foo(OMElement request) { > // create a sender object to send the ack. > > // compute your result > // put your result inside the result > OMElement result = .... > return result; > } > > Michele >> Roshan Punnoose >> Phone: 301-497-6039 >> >> -----Original Message----- >> From: Michele Mazzucco [mailto:[EMAIL PROTECTED] >> Sent: Thursday, September 14, 2006 12:38 PM >> To: [email protected] >> Subject: Re: [Axis2] NonBlocking Client >> >> It depends on the MEP. If the operation signature is in-out you don't >> need any sender client (just return the produced value). Otherwise > (i.e. >> if it is in-only and want to redirect the request -- or the response > -- >> than you need a sender object on the server side as well). >> >> Michele >> >> Punnoose, Roshan wrote: >>> Thanks, that makes sense. >>> >>> On the server side, if I have the address that came over from the >>> wsa:ReplyTo, and I want to push a message out to it, do I have to >> create >>> an axis client on the server side with the target EPR being the >>> wsa:ReplyTo from before? Is that the easiest way to do it? >>> >>> Roshan Punnoose >>> Phone: 301-497-6039 >>> >>> -----Original Message----- >>> From: Michele Mazzucco [mailto:[EMAIL PROTECTED] >>> Sent: Thursday, September 14, 2006 4:21 AM >>> To: [email protected] >>> Subject: Re: [Axis2] NonBlocking Client >>> >>> Hi Roshan, >>> >>> you have to override the methods of the Callback class (isComplete() >> and >>> setComplete()). >>> >>> >>> Regards, >>> Michele >>> >>> Punnoose, Roshan wrote: >>>> Hi, >>>> >>>> I have a non-blocking client with the callback on a separate >> listener. >>>> Is there anyway that I can keep that callback open even after the >>>> response, while the server will be able to send more responses back >> to >>>> the same callback? Then close it on the client side after I receive >>> what >>>> I want from the server? >>>> >>>> Roshan Punnoose >>>> Phone: 301-497-6039 >>>> >>>> -----Original Message----- >>>> From: Neil Aggarwal [mailto:[EMAIL PROTECTED] >>>> Sent: Wednesday, September 13, 2006 5:43 PM >>>> To: [email protected] >>>> Subject: Axis using more than 256MB for a 9MB file >>>> >>>> Hello: >>>> >>>> I have a web service deployed using Axis 1.4 >>>> >>>> In that service, I have a method that accepts a >>>> String containing an XML document. >>>> >>>> When I try to upload a 9MB XML file into my service, >>>> Axis seems to be taking up a HUGE amount of memory. >>>> >>>> If I set the JVM to 256MB of heap, it runs out of >>>> memory and throws an OutOfMemoryException. >>>> >>>> If I set the JVM to 512MB of heap, I get the file >>>> just fine. >>>> >>>> The problem occurs *before* my web service method >>>> is even invoked. >>>> >>>> The service is running on Tomcat on Windows. >>>> >>>> Any ideas why Axis would consume so much memory? >>>> >>>> Thanks, >>>> Neil >>>> >>>> >>>> -- >>>> Neil Aggarwal, (214)986-3533, www.JAMMConsulting.com >>>> FREE! Eliminate junk email and reclaim your inbox. >>>> Visit http://www.spammilter.com for details. >>>> >>>> >>>> > --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>>> > --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
