Re: [jgroups-dev] org.jgroups.protocols.UDP - failed sending message to null

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
>

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss

------------------------------------------------------------------------------
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