Re: [jgroups-dev] org.jgroups.protocols.UDP - failed sending message to null
Adrian Tarau <[email protected]> Thu, 16 Dec 2010 14:37:33 -0500
| Newsgroups | gmane.comp.java.javagroups.devel |
|---|---|
| Message-ID | <[email protected]> |
It's in the ticket, 2.10. I see thread interruption handling so it's not
that causing the exception, it's an IOException and it happens on the
multicast receiver & timer thread.
The error message "Invalid argument" reminds me of failures when I did
some experiments with MulticastSocket. After several attempts to track
where the exception is thrown it is actually the MulticastSocket, it
fails in UDP:
/private void _send(InetAddress dest, int port, boolean mcast, byte[]
data, int offset, int length) throws Exception {
DatagramPacket packet=new DatagramPacket(data, offset, length,
dest, port);
try {
if(mcast) {
if(mcast_sock != null && !mcast_sock.isClosed())
* mcast_sock.send(packet);*
}
else {
if(sock != null && !sock.isClosed())
sock.send(packet);
}
}
catch(Exception ex) {
throw new Exception("dest=" + dest + ":" + port + " (" +
length + " bytes)", ex);
}
}
/
The DatagramPacket buffer has 103 bytes and it tries to send to
228.110.10.10:46553(tried different addresses but it still fails).
On 12/16/2010 02:21 PM, Bela Ban wrote:
> It escaped me which version you use, but this was fixed in 2.9 or 2.10
> IIRC. The bug was caused by the sending thread getting interrupted.
>
> Note that this didn't cause any incorrect behavior, it was just not nice
> to see the exceptions in the log.
>
> On 12/16/10 3:58 PM, Adrian Tarau wrote:
>
>> Per Bela's recommendation we will continue to discuss an
>> issue(https://issues.jboss.org/browse/JGRP-1263) and try to find the
>> what could cause this failure.
>>
>> I get occasionally failures(and when it happens the logs are full of
>> these messages) like this "org.jgroups.protocols.UDP - failed sending
>> message to null" and since the stack trace is not dumped when logging is
>> performed there is not indication where the failure happens.
>>
>> Looking in the source code the failure is caused by a call to "send" in
>> TP.class. We already know dest = null since it is printed in the message
>> but other than that I do not know what else to provide to trouble shoot
>> this issue.
>>
>> /try {
>> send(msg, dest, multicast);
>> }
>> catch(InterruptedIOException iex) {
>> ;
>> }
>> catch(InterruptedException interruptedEx) {
>> Thread.currentThread().interrupt(); // let someone else handle the
>> interrupt
>> }
>> catch(Throwable e) {
>> if(log.isErrorEnabled()) {
>> log.error("failed sending message to " + dest + " (" + msg.size() + "
>> bytes): " + e);
>> }
>> }/
>>
>> I understood from Bela that the failure was logged before with the stack
>> trace but it was changed because the output was too verbose. I agree
>> sometime(when you know exactly when/why you block code might fail) it
>> doesn't worth poluting the log files with information but catching
>> Throwable and hiding the stack trace for any exception is a little bit
>> to...aggressive and I'm saying this with all respect to the developers
>> who worked on JGroups.
>>
>> The exception is actually this "ERROR org.jgroups.protocols.UDP - failed
>> sending message to null (100 bytes): java.lang.Exception:
>> dest=/228.110.10.10:46553 (103 bytes)". Today I was lucky to catch these
>> failures under the development environment and here it is the thread
>> stack trace:
>>
>> /Timer-1,default,barabula-15963@4918 daemon, prio=5, in group 'JGroups',
>> status: 'RUNNING'
>> at org.jgroups.protocols.TP.down(TP.java:951)
>> at org.jgroups.protocols.PING.sendMcastDiscoveryRequest(PING.java:72)
>> at org.jgroups.protocols.PING.sendGetMembersRequest(PING.java:55)
>> at org.jgroups.protocols.Discovery$PingSenderTask$1.run(Discovery.java:492)
>> at
>> org.jgroups.util.TimeScheduler$RobustRunnable.run(TimeScheduler.java:194)
>> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>> at
>> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
>> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
>> at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
>>
>> at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
>>
>> at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>
>> at java.lang.Thread.run(Thread.java:619)
>> /
>> Anybody know why I get these failures? I got these failure with the
>> standard UDP.xml configuration and also with my configuration
>>
>> Thanks.
>>
>> PS. My UDP configuration
>>
>>
>> /<!--
>> Default stack using IP multicasting. It is similar to the "udp"
>> stack in stacks.xml, but doesn't use streaming state transfer and flushing
>> author: Bela Ban
>> version: $Id: udp.xml,v 1.40 2010/02/08 07:11:15 belaban Exp $
>> -->
>>
>> <config xmlns="urn:org:jgroups"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="urn:org:jgroups
>> http://www.jgroups.org/schema/JGroups-2.8.xsd">
>> <UDP
>> mcast_addr="${jgroups.udp.mcast_addr:228.8.8.8}"
>> mcast_port="${jgroups.udp.mcast_port:45553}"
>> tos="8"
>> ucast_recv_buf_size="20M"
>> ucast_send_buf_size="640K"
>> mcast_recv_buf_size="25M"
>> mcast_send_buf_size="640K"
>> loopback="true"
>> discard_incompatible_packets="true"
>> max_bundle_size="64K"
>> max_bundle_timeout="30"
>> ip_ttl="${jgroups.udp.ip_ttl:2}"
>> enable_bundling="false"
>> enable_diagnostics="true"
>> thread_naming_pattern="cl"
>> timer.num_threads="2"
>>
>> thread_pool.enabled="true"
>> thread_pool.min_threads="1"
>> thread_pool.max_threads="2"
>> thread_pool.keep_alive_time="5000"
>> thread_pool.queue_enabled="true"
>> thread_pool.queue_max_size="10000"
>> thread_pool.rejection_policy="discard"
>>
>> oob_thread_pool.enabled="false"
>> oob_thread_pool.min_threads="1"
>> oob_thread_pool.max_threads="2"
>> oob_thread_pool.keep_alive_time="5000"
>> oob_thread_pool.queue_enabled="true"
>> oob_thread_pool.queue_max_size="100"
>> oob_thread_pool.rejection_policy="Run"/>
>>
>> <PING timeout="2000"
>> num_initial_members="3"/>
>> <MERGE2 max_interval="30000"
>> min_interval="10000"/>
>> <FD_SOCK/>
>> <FD_ALL timeout="16000" interval="5000" msg_counts_as_heartbeat="true"/>
>> <VERIFY_SUSPECT timeout="1500" />
>> <BARRIER />
>> <pbcast.NAKACK use_stats_for_retransmission="false"
>> exponential_backoff="0"
>> log_discard_msgs="true"
>> log_not_found_msgs="false"
>> use_mcast_xmit="false" gc_lag="0"
>> retransmit_timeout="300,600,1200"
>> discard_delivered_msgs="true"/>
>> <UNICAST timeout="300,600,1200"/>
>> <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
>> max_bytes="1M"/>
>> <pbcast.GMS print_local_addr="true" join_timeout="3000"
>> print_physical_addrs="true"
>> view_bundling="true"/>
>> <FC max_credits="500K"
>> min_threshold="0.20"/>
>> <FRAG2 frag_size="60K" />
>> <!--pbcast.STREAMING_STATE_TRANSFER /-->
>> <pbcast.STATE_TRANSFER />
>> <!-- pbcast.FLUSH /-->
>> </config>
>> /
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Lotusphere 2011
>> Register now for Lotusphere 2011 and learn how
>> to connect the dots, take your collaborative environment
>> to the next level, and enter the era of Social Business.
>> http://p.sf.net/sfu/lotusphere-d2d
>>
>>
>>
>> _______________________________________________
>> Javagroups-development mailing list
>>
>>
>
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Javagroups-development mailing list
Screenshot-1.png
(image/png, 39 KB) - not displayed