Good question. The ERP procedure specifies a timeout of 300 seconds, but aggregates all returned status codes > 0. I assumed it was a timeout since two pipes timed out in 10 minutes (2 * 300 seconds = 10 minutes). In order to verify the return code, I would have to use a homemade ping procedure, which is rather trivial, but right now we do not have any issues. =) The next time we see this, I will check out the pipe_size as you indicated. Thanks, On Tue, Oct 7, 2008 at 3:28 PM, Bradd Piontek <piontekdd@xxxxxxxxx> wrote: > Charles, > Are you positive it is a timeout? there are only a few statuses that come > back from the send message. (0,1,2,3, I believe). It could be that the pipe > is full (select ownerid,name,type,pipe_size from v$db_pipes) > > Bradd Piontek > "Next to doing a good job yourself, > the greatest joy is in having someone > else do a first-class job under your > direction." > -- William Feather > > > > On Tue, Oct 7, 2008 at 2:39 PM, Charles Schultz <sacrophyte@xxxxxxxxx>wrote: > >> Good day, list, >> >> What would cause a call to dbms_pipe.send_message to timeout? >> >> We have an ERP-delivered procedure that "pings" a few public ERP pipes in >> Oracle 10.2.0.3 running on Solaris 8. I tried tracing (event 10046) but >> did not find much, and trying to drill down via OEM was difficult at best. >> Could be me. =) I am trying to understand what would cause a timeout, >> whether it be a database problem, and if so, where. Not much documentation >> about pipe-specific problems out there in the wild. >> >> -- >> Charles Schultz >> > > -- Charles Schultz