Forum Stats

  • 3,752,162 Users
  • 2,250,465 Discussions
  • 7,867,742 Comments

Discussions

UDP Server hangs

807588
807588 Member Posts: 34,540
edited Mar 4, 2009 4:36AM in Java Programming
Hello,

I'm trying to code a client/server application, based on udp. When the client send requests to the server on low rate, everything works just fine. But, multiple clients try to access the servers, some requests may causes the server to hangs. Here are relevant snippets from the thread dumps of both client and server when hang:

SERVER:
"UDPListener" prio=10 tid=0x08a19c00 nid=0x5c7c runnable [0x3043f000..0x3043fdb0]
java.lang.Thread.State: RUNNABLE
at java.net.PlainDatagramSocketImpl.receive0(Native Method)
- locked <0x3c61c120> (a java.net.PlainDatagramSocketImpl)
at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
- locked <0x3c61c120> (a java.net.PlainDatagramSocketImpl)
at java.net.DatagramSocket.receive(DatagramSocket.java:712)
- locked <0x325770d8> (a java.net.DatagramPacket)
- locked <0x3c61c180> (a java.net.DatagramSocket)
at com.site.commons.pattern.kota.HashRAMRMIService$1.run(HashRAMRMIService.java:464)

CLIENT:
"http-8080-3" daemon prio=10 tid=0x090b7000 nid=0x3b84 runnable [0x181e5000..0x181e5fb0]
java.lang.Thread.State: RUNNABLE
at java.net.PlainDatagramSocketImpl.receive0(Native Method)
- locked <0x91ddcf48> (a java.net.PlainDatagramSocketImpl)
at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
- locked <0x91ddcf48> (a java.net.PlainDatagramSocketImpl)
at java.net.DatagramSocket.receive(DatagramSocket.java:712)
- locked <0x91de01f8> (a java.net.DatagramPacket)
- locked <0x91ddcf20> (a java.net.DatagramSocket)
at com.site.commons.pattern.kota.management.DataPartitioner.getViaUDP(DataPartitioner.java:169)
at com.site.advertiser.AdvertiserServlet.doGet(AdvertiserServlet.java:371)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:856)
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:565)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1509)
at java.lang.Thread.run(Thread.java:619)

I'm attaching a code snippet demonstarting how the server side socket is established and serving requests:
socket = new DatagramSocket( port(name) );

new Thread( "UDPListener-" + name )
{
public void run()
{
while( true )
{
try
{
byte[] buf = new byte[2048];

DatagramPacket packet = new DatagramPacket( buf, buf.length );

socket.receive( packet );

Serializable key = (Serializable) new ObjectInputStream( new ByteArrayInputStream( buf ) ).readObject();

Serializable value = get( key );

byte[] asByteArray = null;

if( value != null )
{
asByteArray = asByteArray( value );
}
else
{
asByteArray = new byte[0];
}

InetAddress address = packet.getAddress();

int port = packet.getPort();

packet = new DatagramPacket(asByteArray, asByteArray.length, address, port);

socket.send(packet);
}
catch ( Exception e )
{
logger.error( "Failed to serve udp request", e );
}
}
}
}.start();
Is this hang expected in scenario of multiple client accessing one udp server?

10x,

Barak.

Comments

  • 807588
    807588 Member Posts: 34,540
    Does the client program send a packet and then expect a reply? Because the reply won't always happen. UDP is a lossy protocol; it will drop packets, deliver packets out of order, and deliver multiple copies of packets. Your client sends a request and the network loses the packet; then your client will forever wait for the reply.

    If you need reliable delivery use TCP instead.
  • 807588
    807588 Member Posts: 34,540
    Hi,

    Thanks for the fast reply. My client indeed waits for the reply. Let me desribe the entire story. On the first my client/server application was RMI based. I was thinking that since the server and the clients share the same LAN (and the LAN should be reliable), I could spare the overread of the RMI protocol and move to UDP, but the reality fits well with your explanation :-)

    Before I go back to RMI, is there a way to configure timeouts on the client side, to it won't wait forever in such cases?

    Thanks a lot,

    Barak.
  • EJP
    EJP Member Posts: 32,920 Gold Crown
    DatagramSocket.setSoTimeout()
  • JoachimSauer
    JoachimSauer Member Posts: 4,780
    BarakY wrote:
    [...] I could spare the overread of the RMI protocol and move to UDP, but the reality fits well with your explanation :-)
    You know, there are several levels of abstraction between RMI and UDP. You could move to a custom TCP-based protocol for example. There you'd still have the reliability, but could interact on a lower level and have more control.
  • 807588
    807588 Member Posts: 34,540
    Sounds yammi :-)

    Can you guide me where can I find some pointers/refs of these issues?
    Do you suggest considering low-level socket programming?
    Do you think such programming will result with better performance?

    Barak.
  • EJP
    EJP Member Posts: 32,920 Gold Crown
    Can you guide me where can I find some pointers/refs of these issues?
    The Javadoc.
    Do you suggest considering low-level socket programming?
    Isn't that exactly what he said?
    Do you think such programming will result with better performance?
    Compared to what?
  • 807588
    807588 Member Posts: 34,540
    Compared to what?
    To Sun RMI implementation.
  • JoachimSauer
    JoachimSauer Member Posts: 4,780
    BarakY wrote:
    Compared to what?
    To Sun RMI implementation.
    Possibly, not necessarily. What it does give you is more control, but also more work. You can easily control what gets sent when and therefore have the chance to improve performance.
This discussion has been closed.