Re: serving multiple shape files with Linklayer

Hi,
Well, I got some hands-on experience with how much the shape server
can handle.

In brief, I am running an applet that gets three shape layers and
at least one but possibly many layers representing gps data tracings from
a server. The shape layers are implemented using a vanilla version of
ShapeServer from (I think) openmap3.6, (I still haven't finished the
migration). The client side (the applet) has a bit of custom hacking
to the LinkLayer. This may not be needed in 4.0+, but I found I
had to add code such as this to get the properties to load:

....

    private void propLoad(String propertiesURL){
        //This following code won't work with an applet.
        //an applet needs to look only at the same host.
        //possible workarounds:
        //(1) parse the propertiesFile URL for host, uri. replace host
        // with call to JApplet.getCodeBase().getHost()
        //(2) assume user knows this is an applet, and has supplied
        // a relative URI instead of an absolute one. Prepend
        // with call to JApplet.getCodeBase().getHost()
        URL propertiesFile = null;
        String protoU = null;
        int portU = 0;
        String fileU = null;
        try{
            propertiesFile = new URL(propertiesURL);
            //intercept inappropriate host for applet.
            if( Environment.isApplet () ) {
                //host was set above, still valid
                protoU = propertiesFile.getProtocol();
                portU = propertiesFile.getPort();
                if( portU == -1 )
                    portU = ((JApplet)(Environment.getApplet()))
                        .getCodeBase ().getPort();
                fileU = propertiesFile.getFile();
                if( portU == -1 )
                    propertiesFile = new URL(protoU, host, fileU );
                else
                    propertiesFile = new URL(protoU, host, portU, fileU );
                    }
            args.load(propertiesFile.openStream());
        } catch (java.net.MalformedURLException mue){
    System.err.println("LinkLayerApplet: Properties URL isn't valid: " +
                               propertiesURL);
            System.err.println(mue);
        } catch (IOException ioe){
    System.err.println("LinkLayerApplet: IOException reading properties file:"
                               + protoU + host + portU + fileU );
            System.err.println(ioe);
        }
    }

....

As I mentioned in an earlier email, my gps layer is served up using
an XML-RPC server (the java implementation, again with a couple of
custom hacks to obey the applet permissions). the gps client layer
is complicated and rather lame at the moment, but it shows tracings.

The user test was a Sophomore engineering lab. The class is an intro
to Civil Eng. here at UCI, and the Transportation prof. wanted to
use the GPS/Openmap applet. There were approximately 30 to 40 students
at computers in the lab, and they all loaded up my openmap applet.
The server is a Sun (purchased in the last 6 months) with about 200 Meg of
ram and swap.

what happened was interesting. the shape servers (3) started out fine,
but then one after the other they went down. I restarted them in a
telnet session in the lab, and watched as they fielded requests, started
spitting out java out of memory errors, then null pointer exceptions and
crashing again.

Obviously our server was underpowered for the assault. But it was also
interesting that the shapeservers went down, but not my XML-RPC
server, and that the ShapeServers died after working for a while.
My GPS server sends out the data once, and all the info is
stored in the client layer (on the web browser). In contrast,
the ShapeServers do their thing with every projection change. I thought
Java didn't have any memory leak problems, but in this case, it seems
that the garbage collection is not happening fast enough, or else
objects are not being disposed of or reused efficiently from projection
change to projection change.

Again, I am using 3.6 era shape servers. But when I get some time
to finish off my upgrade, I will look through the shapeserver code and
see if anything obvious can be tightened up. But I am more of a
jack-of-all-trades programmer than a Java specialist, so I thought I'd
share my experience with the list and let wiser heads take a look at
the source.

cheers,
james marca

>From Don Dietrick, received Wed, May 16, 2001 at 03:13:48PM -0400:
> Hi,
>
> When the client breaks contact (signs off), an IOException is thrown and
> caught by the server thread, which ends the life of that thread. The

Yep, I saw that happen as well. Kind of interesting, in that it showed
exactly when students got bored, killed the applet and started checking
email or looking at other web sites. (The prof can't see what the students
are doing on the computers, but the request fielded messages and the
IOExceptions don't lie!)

> resources used by that thread are eventually gc'd, although I've noticed
> that usually happens when the next thread dies. I suspect there's a
> small memory leak there that's preventing a more timely cleanup, but the
> cleanup does happen. (I am trying to track this down)
>
> - Don
>
> Mark Bucciarelli wrote:
>
> > Openmap handles multiple clients just fine; each applet client get's it's
> > own socket and thread.
> >
> > The only potential drawback is that once a client thread is started, I
> > don't think it ever stops. As I read the code, the shape server blocks
> > in the link, waiting for the next request from the client. So I think
> > you theoretically could run into a situation where all the sockets
> > (62,000??) could be exhausted on the shape file port.
> >
> > I would expect that when the applet closes, the link layer client should
> > let the shape server know it's ok to close that socket. Based on my
> > previous experience with OpenMap code, this is probably happening; I
> > just not looking in the right place!

--
[To unsubscribe to this list send an email to "majdart@bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]