Re: Q: many broken pipes, app stops responding

>>>>> This means that the connection to the browser was severed, 
>>>>> probably by the user hitting "Stop" or closing the browser window.
>>>>>
>>>>
>>>> I know - I mean, I've seen this when developing and closing the 
>>>> browser window too early. But - how can this bring my application 
>>>> to stop responding?
>>>>
>>>
>>> No, this exception has nothing to do with your application refusing 
>>> to respond.  Most likely you have a deadlock in your application 
>>> somewhere.  Often, this is caused by unbalanced lock()/unlock() 
>>> calls to EOEditingContext... is that possible?
>>
>> I don't think so - I just read from the db with this app. I don't do 
>> any looking because of the autolocking feature of ERXEC.
>
> How long does the db read take?
>
> If it takes more than about 90 seconds (with the typical 
> configuration; see the WOAdaptorInfo page) then any request which 
> needs database access will block until until the read finishes, then 
> do its database access, then write its response ... except that the 
> adaptor timed it out some time ago and closed its end of the socket.
>
> Equally, even if you are not doing any explicit locking (perhaps of 
> the editing context), there have been known bugs in the EOF stack 
> where an exception is thrown sometime after an object is locked, 
> preventing the code with the matching unlock to not be executed -- if 
> I remember, this often involves DirectActions and WOSessionStore 
> checkin/checkout .

Uh, just to emphasize, I meant that a request hogs the database and 
gets timed out by the adaptor, but while it's hogging the database, any 
subsequent requests will block and are likely to be timed out as well.

-- Patrick