Hi Gabriel; thanks for all the hard work (and for including an export of
the user guide)!
I downloaded the source code (now called "project") from SF and started
a build:
1. This release includes too much stuff; the idea with me setting up the
profiles last week was so the GeoTools PMC would n
All fixed. They did get my email.
Chris Hodgson advises:
"Fixed.
Weird CLOSE_WAIT overflow issue, again...
Chris"
Ben Caradoc-Davies wrote:
> I have done so. Their (refractions.net) web servers (including postgis)
> are also down. Looks like a general outage, so I suspect that
> (1) the admins
I have done so. Their (refractions.net) web servers (including postgis)
are also down. Looks like a general outage, so I suspect that
(1) the admins will not be getting our email, and
(2) they are (or soon will be) addressing the problem.
Regards,
Ben.
Jody Garnett wrote:
> Can you guys email [E
Can you guys email [EMAIL PROTECTED] when this occurs; I was offline
all weekend and only just noticed.
The contact information for any of our development servers is on this page:
- http://docs.codehaus.org/display/GEOTOOLS/Development
Jody
Ben Caradoc-Davies wrote:
> Michael Bedward wrote:
>
Nothing went wrong that I know of; my impression was Jesse stalled
waiting for feedback. Do you want to try a read/write lock?
Jody
Andrea Aime wrote:
> Hi,
> I'm looking into a scalability problem in our current
> shapefile datastore implementation that prevents
> fully using the whole CPU(s) on
Michael Bedward wrote:
> Tried to svn update just now but can't connect. Is there some planned
> down-time happening ?
svn.geotools.org (svn.refractions.net) is down for me as well.
--
Ben Caradoc-Davies <[EMAIL PROTECTED]>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Re
Tried to svn update just now but can't connect. Is there some planned
down-time happening ?
Michael
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications wi
Hi,
I'm looking into a scalability problem in our current
shapefile datastore implementation that prevents
fully using the whole CPU(s) once the number of threads
hitting the shapefile is > 1.
I only had a cursory look, so I may have misunderstood,
but it seems the current locking mechanism tells
