> I hadn't, but have now. I have not changed
> URLDirectoryScanner but attempted
> to roll its functionality into the core URLDeploymentScanner using
> collection URLs to discriminate - does this work for you?
This would be great, thanks for taking the time.
> It seems the root cause of your bug is the lack of response to the GET
> request used by getLastModified(). This is basically Jetty
> not responding to
> a simple GET request which seems a bit more fundamental.
I traced it as far as the connection being accepted on the netboot
side and then being closed before the response was being sent.
According to snoop there was no data returned in the response.
I have previously encountered problems with WebSphere on Solaris
where the socket accept started throwning exceptions which were not
expected nor handled. It was tied down to a change in the Solaris
IP stack. I don't know whether this is relevant.
In any case I thought that the client side should be in a position
to handle transient network errors, hence the fix I suggested. It
was a real pain for us to have the resources undeploying and
redeploying for no apparent reason.
> The old netboot helper mapped the host server's configuration
> to a /files
> URL by adding a dedicated context handler. The new helper
> does not use the
> host server's configurations but instead stores the config in
> a war - so,
> the GET for last-modified is handled directly by the
> container and if this
> is broken, GET for any resource is broken :-(
>
> Did you ever find out why Jetty is closing the socket without
> responding, or
> log a bug for it?
I haven't I'm afraid, I did enough to get the rest of my team
working and left it at that :-(. I suspect it may be similar
to the WebSphere problem that I had to work around.
I'll have a quick look at it again and see if I can get any
further, although we have just upgraded Solaris and it may
no longer happen :-).
Thanks again,
Kev
Kevin Conner
This is a personal e-mail. Any views or opinions presented are
solely those of the author and do not necessarily represent those
of Orchard Information Systems Ltd.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
