On Tuesday, September 2, 2003, at 03:00 PM,
> --> Tuesday, September 2, 2003, 2:33:30 PM, matt@... wrote:
>> Dietmar Schwertberger wrote:
>>> I can see
>>> StreamOut Error: (10053, 'Software caused connection abort")
>>> in the console window.
>> I don't have a solution for you, but I can say that we've seen this as
>> well; we saw it a long time ago, when accidentally serving large
>> files with a servlet. We worked around it by piping those files
>> As far as I know, this problem hasn't been fixed.
> I almost replied to Dietmar earlier, but figured I could not be
> Matt, your problem sounds like a simple timeout limitation. Which
> means it
> should be possible to fix via a configuration value or similar.
> I assume Webware allows this in a global configuration, but it is also
> to be useful to allow a very granular configuration of this to set in
> pages via the API. If these things are not possible, perhaps they
> should be.
Webware doesn't time anything out (maybe to its detriment -- though I
don't know if there's any good way to do a timeout in a threaded
environment anyway). I don't know if there's any way to put a timeout
on a particular socket. If there is, Webware doesn't do it (or leaves
it at the default timeout).
In this case Apache is probably timing out.
> A third thing to consider is allowing configuration of the timeout on
> the URL.
> For example : mypage.psp?_WWTimeout=120000. However, this is the THIRD
> to consider, so don't get hungup on it. I understand people might not
> like it.
> Then again, I was once flamed by Webware advocates for explaining PHP's
> helpful handling of form variables, such as naming them with 
> postfixed to
> put multiple into an array. Next thing you know I am checking out
> and see very nearly the same abstract concept in form variable actions
> prefixed with _. So you never know, and that is why I mentioned the
Actions are done with the _action_X form variable, but confirmed with
the servlet's actions() method. So the client never invokes something
that wasn't explicitly permitted by the developer. In this case the
configuration (if it existed) would best be put directly in the
servlet, as per-request configuration (as opposed to per-servlet) seems