Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@axis.apache.org
Message-ID: <29110518.5531274899716668.JavaMail.jira@thor>
Date: Wed, 26 May 2010 14:48:36 -0400 (EDT)
From: "Andreas Veithen (JIRA)" <jira@apache.org>
To: java-dev@axis.apache.org
Subject: [jira] Commented: (AXIS2-4724) Add Multicast Capabilities to the
 UDP Transport
In-Reply-To: <9908569.4571274679743467.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/AXIS2-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871884#action_12871884 ] 

Andreas Veithen commented on AXIS2-4724:
----------------------------------------

I'd rather propose the following approach. Extract an interface from the current IODispatcher and have two implementations: NonBlockingIODispatcher (with the existing code from IODispatcher) and BlockingIODispatcher. Looking at the public methods of IODispatcher, it should be fairly easy to reimplement the same interface with blocking I/O:

addEndpoint(Endpoint)
removeEndpoint(Endpoint)
stop()

One would then have a single UDPListener, but the type of IODispatcher would be configurable. In a second step, multicast support would be introduced into BlockingIODispatcher (with the necessary changes in the IODispatcher interface and the Endpoint class). Of course, any attempt to use multicast together with NonBlockingIODispatcher would result in an error.

There will be also two other points we have to look into:

1. The source port in the responses sent by the transport should actually be the port on which the request has been received (i.e. if the request goes from port X to Y, then the response should go from Y to X, not from some random port to X). This is necessary to properly correlate request and responses and also because most UDP clients expect that. This implies that the response must be sent using the DatagramSocket or DatagramChannel on which the request was received (and which is managed by the listener!).

2. Currently, request-response uses a blocking I/O call. However, it should be possible to support a true asynchronous invocation style (i.e. doing request-response without blocking a thread).

The first point is tricky because it is not possible to mix blocking and non blocking mode with a single DatagramSocket/Channel. Thus, if the listener uses non blocking I/O, the sender also needs to use it. The second requirement can only be supported with non blocking I/O. Probably what we will have at the end is a design where the UDPListener and UDPSender use a shared IODispatcher instance which is either non blocking (and supports truly asynchronous request-response) or blocking (and supports multicast).

> Add Multicast Capabilities to the UDP Transport
> -----------------------------------------------
>
>                 Key: AXIS2-4724
>                 URL: https://issues.apache.org/jira/browse/AXIS2-4724
>             Project: Axis2
>          Issue Type: Improvement
>          Components: transports
>            Reporter: Hiranya Jayathilaka
>             Fix For: 1.6
>
>
> With this improvement Axis2 will be able to receive SOAP messages from multicast groups and send requests to multicast groups. Also we will be able to support multicast request - unicast response MEP. I will attach the patch soon.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org