Hi all,
I tried to fix some remaining issues with GEOT-4467, in particular the
File.deleteOnExit() usage.
You find the alternative solution here:
https://github.com/mbarto/geotools/commit/c1733941f9cfaf3642e7ce33cf8844b4ae21b104
It's based on synchronization in the topic moments of resolving
Thanks, Mauro. That looks great!
I had two small stylistic observations:
(1) I do not think you need your static synchObject; you could achieve
the same effect synchronising on the class object with
synchronized(SchemaClass.class).
(2) If you make any minor changes, please remove the trailing
On Fri, May 24, 2013 at 4:04 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
I think your decision to have a timeout is excellent, as a thread could
otherwise block indefinitely, which would be very, very bad for a
service such as GeoServer.
Or would block indefinitely geotools
[back on list]
On 24/05/13 15:06, Mauro Bartolomeoli wrote:
2013/5/24 Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
mailto:ben.caradoc-dav...@csiro.au
Mauro, I do not like the exception swallowing in
SchemaCache.download(). You changed to original:
throw new RuntimeException(e);
On Thu, May 23, 2013 at 5:48 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
Mauro,
your improvements to SchemaCache have also introduced an unanticipated
problem triggered by download failure:
https://jira.codehaus.org/browse/GEOT-4467
You set a 10 second timeout on connections
On 23/05/13 14:26, Andrea Aime wrote:
On Thu, May 23, 2013 at 5:48 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au wrote:
http://www.w3.org/2001/xml.xsd
Ah, this one is a nightmare, it's always super-slow to download (I guess
because
anything XML
2013/5/23 Andrea Aime andrea.a...@geo-solutions.it
On Thu, May 23, 2013 at 5:48 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
Mauro,
your improvements to SchemaCache have also introduced an unanticipated
problem triggered by download failure:
2013/5/23 Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
On 23/05/13 14:26, Andrea Aime wrote:
On Thu, May 23, 2013 at 5:48 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au
mailto:Ben.Caradoc-Davies@**csiro.auben.caradoc-dav...@csiro.au
wrote:
http://www.w3.org/2001/xml.xsd
Ah,
On 23/05/13 15:20, Mauro Bartolomeoli wrote:
2013/5/23 Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
mailto:ben.caradoc-dav...@csiro.au
On Thu, May 23, 2013 at 5:48 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au
mailto:Ben.Caradoc-Davies@__csiro.au
Hi Ben,
(2) Please look at the logic in SchemaCache.startDownload(). Why is it
necessary to create an empty file? How should SchemaCache recover when a
download fails? Please have a look and recommend a solution. I know you
gave this some thought and I do not want to introduce a deadlock or
Mauro,
30 seconds sounds like a generous default. Maybe even 60 seconds for the
paranoid?
I think your decision to have a timeout is excellent, as a thread could
otherwise block indefinitely, which would be very, very bad for a
service such as GeoServer.
Kind regards,
Ben.
On 23/05/13
Mauro, I do not like the exception swallowing in SchemaCache.download().
You changed to original:
throw new RuntimeException(e);
to
return null;
in the catch block. While this will result in a failed download and an
exception higher up that includes a URL report, precise network or DNS
Mauro,
your improvements to SchemaCache have also introduced an unanticipated
problem triggered by download failure:
https://jira.codehaus.org/browse/GEOT-4467
You set a 10 second timeout on connections and reads. It turns out that
some application schemas, including that used in the GeoServer
13 matches
Mail list logo
