This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Harry Edmon <address@hidden> >Organization: UCAR/Unidata >Keywords: 200202071958.g17Jwtx15748 >I am having an internal problem sending products between two machines. For so > me >reason the RPC call on the sending machine is timing out. This causes the >process to die and a new feed process to start. However, it appears that the >new process does not take over exactly where the old one left off - the produc > t >being sent at the time is not resent - and it appears that a few products just >after that product may be missing. Any ideas? > > >-- >Dr. Harry Edmon E-MAIL: address@hidden >206-543-0547 address@hidden >Dept of Atmospheric Sciences FAX: 206-543-0308 >University of Washington, Box 351640, Seattle, WA 98195-1640 > Harry, Anne may have some ideas on why the RPC is timing out. You can increase the timeout with the -t flag to rpc.ldmd....but it sounds bad that two local machines are having a timeout. Are the missing products "CONDUIT" products, or another feed? If the missing prods are CONDUIT, then the point of discontinuity might result from the order which the products were received from the split requests. When the LDM reconnects, it would request "from" the timestamp of the latest product received of that feedtype - which may be more recent for one part of the split request than another. If not CONDUIT, then I don't have a quick guess, unless it was fore something like the craft feed where products might be injected at different hosts in the same feed- again creating a time continuity between the same feedtype products with different sequencing. Steve Chiswell