CODEWITHSUNDEEP
javaudpnettyapache-camel
mdnghtblue
mdnghtblue

Reputation: 1117

Camel Netty UDP listener listening on 0.0.0.0 and not receiving packets

I'm new to Camel, Netty and UDP, but I've been researching this for a while and still can't figure out what's going on.

All I'm trying to do is implement a UDP listener using Camel and Netty (currently on Windows 7, but will be moving the project to Linux). My spring config is as follows:

<camel:camelContext id="test">
    <camel:route>
        <camel:from uri="netty:udp://localhost:5150?sync=false"/>
        <camel:to uri="log:cameltest?level=DEBUG"/>     
        <camel:to uri="file://outbox"/>
    </camel:route>
</camel:camelContext>

The listener appears to starts fine (running through Eclipse). However, when I do a netstat, I see this:

UDP    0.0.0.0:5150
UDP    [::ffff:127.0.0.1]:5150

when I am expecting it to be listening on 127.0.0.1. Nothing I've read online is clear on if this is expected behavior for Camel/Netty/UDP.

I'm testing this by sending from a Java NIO UDP Client. If an NIO UDP Server is listening, it receives the packet fine (all done through localhost).

I also tested a Camel/Netty/TCP listener and that works fine.

Why is the listener listening to all local addresses? And if so, why isn't it receiving my packet from localhost?

Upvotes: 2

Views: 3319

Answers (1)

mdnghtblue
mdnghtblue

Reputation: 1117

I figured it out. This was my final spring context:

<bean class="org.jboss.netty.handler.codec.string.StringDecoder" id="stringDecoder">
    <constructor-arg value="ISO_8859_1" />
</bean>

<camel:camelContext id="test">
    <camel:route>
        <camel:from uri="netty:udp://localhost:5150?decoder=#stringDecoder&amp;disconnectOnNoReply=false&amp;sync=false"/>
        <camel:to uri="log:cameltest?level=DEBUG"/>     
        <camel:to uri="file://outbox"/>
    </camel:route>
</camel:camelContext>

After doing some research on UDP and Netty, I found out that listening on 0.0.0.0:[port#] seemed to be the default behavior for Netty/UDP. For more information on what 0.0.0.0 means, see this link.

A fellow programmer suggested (because I'm essentially working with a framework within a framework), to take out the camel stuff and try to get it working in Netty. I tried this and I was able to get it working, and was also able to send to it from my NIO UDP Client. For a while I thought the problem was in camel because I couldn't see anything wrong with the Netty implementation.

After hours of step-by-step debugging in the Netty/UDP, Camel/TCP, and the "broken" Camel/UDP, I noticed that the Camel Netty implementation used a ConnectionlessBootstrap from the org.jboss package to bind the connection. In my Netty implementation, I was using Bootstrap from the io.netty package.

I found an example using the ConnectionlessBootstrap and org.jboss package from http://massapi.com/class/org/jboss/netty/bootstrap/ConnectionlessBootstrap.java.html. When I got it working, I compared the implementation to mine, and noticed he had an encoder and decoder on both ends. This is where I got the idea to add a CharsetUtil.ISO_8859_1 decoder to my listener and managed to get the project working.

I also noticed I was only able to send to it once at a time. Setting the property disconnectOnNoReply to false allowed the listener to receive multiple times without disconnecting.

Hope this helps someone out in the future. :)

[edit] Actually after further testing, the "disconnectOnNoReply" may not be needed. I just tried it without it and it works.

Upvotes: 8

Related Questions