axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaliya Ekanayake" <jal...@opensource.lk>
Subject Re: [Axis2] Imporvement in Axis2 transport layer
Date Thu, 10 Nov 2005 16:59:44 GMT
Hi Ajith see the comments,

----- Original Message ----- 
  From: Ajith Ranabahu 
  To: axis-dev@ws.apache.org 
  Sent: Thursday, November 10, 2005 11:27 AM
  Subject: Re: [Axis2] Imporvement in Axis2 transport layer


  Hi all,
  I've noticed this behavior of the transport during  the recent interop tests  with Microsoft.
Out RM interop tests work nicely but the client keeps on listening even after the 202 for
the terminate sequence message. We should have a way to tell the listener to shut down at
somepoint and in the case of RM, it would be the 202 for the terminate sequence. (Oh BTW the
listener should be configurable according to the policy too.

  The listener that I am suggesing is merely a transport listner and have no idea about policy
stuff. Handlers should be configured according to the policy in the Axis2 engine and the listener
simply accepts transport level messages and hand over them to some acceptor, whcich will then
invokes an engine with proper handlers according to the policy.

   If you can have a look at the following WSDL http://131.107.72.15/ReliableMessaging_Service_Indigo/ReliableRequestReplyDual.svc?wsdl
  you'll see the policy assertion that says about the listener timeout)

  >Listener time out will affect only to whcih incoming enpoint or RMSequence that we are
listening to. The single listener will keep on listening but will not do anything after time
outs.

  Jaliya, I'm a bit 0- on the idea of having a single listener. 

  >In the current architecture, if we need to run several client instances (on separate
JVMs) in a given machine we keep on generating the port numbers for the listeners. I don't
think this will be a feasible option when we are inside a network with firewalls. Just consider
how we can open these ports for remote interop tests.

  but if we have a fixed listner port for the entire system then we can give pemissions to
this port and let all client instances to commuincate with this.

  It'll make things hard when the listner needs to be timed out! 
  This time out is different to what I explained in the single listener concept.

  Instead what I see as appropriate is a mechanism to create listners passing a configuration
(which ofcourse includes the timeout and other stuff) and the listener dies down after the
given interval. 

  thoughts ?


  On 11/10/05, Jaliya Ekanayake <jaliya@opensource.lk> wrote:
    Hi,

    I have been thinking of this problem and came up with this possible
    improvement

    In  the client side we can have a single message listener(it can do sending
    as well) registered as a service or background process for the entire 
    system.
    So it will be an axis2 message listener for that machine.
    We will introduce new transport which will just write the out going messages
    to the queue(or database) without worrying about the actual sending of it. 
    Our agent will continuously monitor this queue(or database) and send any
    message in the outgoing queue and when ever a response is present it will be
    put them into the incoming queue.
    Now if the service invocation is time consuming, then user can select this 
    transport and let the request to be sent. Later the client application can
    check the queue for any responses that it was expecting.( this can be in
    different instance of the client application, the only information it needs 
    is the correlation information)

    One other improvement is to send the messages using the normal transport and
    write the correlation information to the queue so if there are no responses
    for an INOUT mep then it can set some flag in the message context and let it 
    return.
    Then the Call will decide whether to wait or whether to inform the user that
    the messages will take time.
    In any case, user can retrieve responses using the listener.

    There can be other improvements on this idea, so please comment. 

    Thanks,

    Jaliya



    ----- Original Message -----
    From: "Saminda Abeyruwan" <saminda@opensource.lk>
    To: < axis-dev@ws.apache.org>
    Sent: Thursday, November 10, 2005 9:14 AM
    Subject: [Axis2] Imporvement in Axis2 transport layer


    > Hi all,
    >
    > My concern is regarding complete async message invocation.  As my 
    > understaning of the transport mechanism,  during async duel invocation,
    > sender {HttpClient} expect 202 from server. Now the "out" stream for this
    > at server side  return when MessageReceiver returns and when doPost() {if 
    > it is servlet case}method returns. At one point in server side
    > CommonsHttpTrasnsportSender will create an another HttpClient and send the
    > response due "reply-to" is not anonymus.
    > 
    > Now assume a "time eating" service hangs and does not allow the MR to
    > return,  then at client side instead of getting 202,  it will time out {at
    > sometime}. Sometimes later the response might come to listener. But the 
    > timeout is not Runtime exception and the client will exit even though we
    > have a response.
    >
    > If we can correct this scenario, "there may be  mediators which take a
    > long time to process" will come handy with the development of Synapse, 
    > with async invocation.
    >
    > How can we overcome this problem.
    >
    > Thanks
    >
    > Saminda
    >






  -- 
  Ajith Ranabahu 
Mime
View raw message