[Geoserver-devel] Multiple simultaneous requests

Hi,

am playing with a branch (complex_sco) from geoserver and suspect I have discovered an issue that might be a wider one. I am seeking info on whether anyone else has experienced this, its been fixed or even if it has been properly tested ever before I go deeper into creating a test case to prove it.

i have a client that hits geoserver with two simultaenous requests on the same feature type, with different filters. The result for each filter is different (4 vs 40 features) when hit separately (and correct) but it always returns the same result (arbitrarily one or the other) when I hit it with simultaneous requests. When I use another (identically configured) geoserver instance on another tomcat for one of the layers the results are always correct.

Does this sound familiar to anyone and are there any suggestions for an easy way to test this in the unit testing framework?

Rob Atkinson

silly, do you have a way of testing if the problem occurs in trunk, or at
least with another datastore?
hopefully its only a complex_sco branch problem, in which case I would not
worry about fixing it, since the branch is going to die?

I'd never experienced such a behavior, though never tested explicitly.
My inclination is to think on a specific datastore problem, since I can't
imagine a reason why geoserver would not be thread safe.

Gabriel.

On Thursday 15 September 2005 22:59, Rob Atkinson wrote:

Hi,

am playing with a branch (complex_sco) from geoserver and suspect I have
discovered an issue that might be a wider one. I am seeking info on
whether anyone else has experienced this, its been fixed or even if it
has been properly tested ever before I go deeper into creating a test
case to prove it.

i have a client that hits geoserver with two simultaenous requests on
the same feature type, with different filters. The result for each
filter is different (4 vs 40 features) when hit separately (and correct)
but it always returns the same result (arbitrarily one or the other)
when I hit it with simultaneous requests. When I use another
(identically configured) geoserver instance on another tomcat for one of
the layers the results are always correct.

Does this sound familiar to anyone and are there any suggestions for an
easy way to test this in the unit testing framework?

Rob Atkinson

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Gabriel Roldán wrote:

silly, do you have a way of testing if the problem occurs in trunk, or at least with another datastore?

I'll try to test it against the trunk if no-one has any experience that will help.

hopefully its only a complex_sco branch problem, in which case I would not worry about fixing it, since the branch is going to die?

Its unlikely to be in the branch, since neither the dispatcher or data store has been changed for this branch. But you're right - if it is in the branch then I'm not going to fix it, so if someone has tested this behaviour I will relax and worry about something more useful.

I'd never experienced such a behavior, though never tested explicitly.

This is the first point of call - has anyone tested this? If not, the best way forward is probably to create unit tests and then run them against the trunk. Anyone looked at an easy way to do simultaneous queries in the unit testing framework?

My inclination is to think on a specific datastore problem, since I can't imagine a reason why geoserver would not be thread safe.

It might be a JDBC (or specific derived subset) data store issue - possibly the database connection pooling stuff isnt properly used. It may even be an issue within the specific JDBC driver, but that seems unlikely.

Gabriel.

On Thursday 15 September 2005 22:59, Rob Atkinson wrote:

Hi,

am playing with a branch (complex_sco) from geoserver and suspect I have
discovered an issue that might be a wider one. I am seeking info on
whether anyone else has experienced this, its been fixed or even if it
has been properly tested ever before I go deeper into creating a test
case to prove it.

i have a client that hits geoserver with two simultaenous requests on
the same feature type, with different filters. The result for each
filter is different (4 vs 40 features) when hit separately (and correct)
but it always returns the same result (arbitrarily one or the other)
when I hit it with simultaneous requests. When I use another
(identically configured) geoserver instance on another tomcat for one of
the layers the results are always correct.

Does this sound familiar to anyone and are there any suggestions for an
easy way to test this in the unit testing framework?

Rob Atkinson

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
   
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

This is the first point of call - has anyone tested this? If not, the

best way forward is probably to create unit tests and then run them
against the trunk. Anyone looked at an easy way to do simultaneous
queries in the unit testing framework?

TestGen4J can be used to automatically create JUnit tests, and then
Jester can be used to slightly change those JUnit tests. I haven't used
any of these tools, but someone might like to try them out to make sure
everything stays ok.

__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

On Fri, 16 Sep 2005, Rob Atkinson wrote:

Gabriel Roldán wrote:

>silly, do you have a way of testing if the problem occurs in trunk, or at
>least with another datastore?
>
>
I'll try to test it against the trunk if no-one has any experience that
will help.

>hopefully its only a complex_sco branch problem, in which case I would not
>worry about fixing it, since the branch is going to die?
>
>
>
Its unlikely to be in the branch, since neither the dispatcher or data
store has been changed for this branch. But you're right - if it is in
the branch then I'm not going to fix it, so if someone has tested this
behaviour I will relax and worry about something more useful.

I've never explicitly tested it. Did some scalability stuff, but wasn't
so much checking the results to confirm they were exactly correct -
mostlyjust doing getcaps stuff. There is some code that david z wrote to
send a bunch of simultaneous requests - in
test/org/vfny/geoserver/ThreadedBatchTester.java It was sending stuff
serially before, but I think I fixed it.

>I'd never experienced such a behavior, though never tested explicitly.
>
>
This is the first point of call - has anyone tested this? If not, the
best way forward is probably to create unit tests and then run them
against the trunk. Anyone looked at an easy way to do simultaneous
queries in the unit testing framework?

Not off the top of my head. This would be good to figure out though.
Maybe cactus? The excuse we have is that cite tests everything really
well, so we never developed a framework for more than basic unit tests.
Though perhaps it can be isolaed down to the datastore level?

>My inclination is to think on a specific datastore problem, since I can't
>imagine a reason why geoserver would not be thread safe.
>
>
>
It might be a JDBC (or specific derived subset) data store issue -
possibly the database connection pooling stuff isnt properly used. It
may even be an issue within the specific JDBC driver, but that seems
unlikely.

Yeah, testing against different dbs is the first place I would start...

Chris

>Gabriel.
>
>On Thursday 15 September 2005 22:59, Rob Atkinson wrote:
>
>
>>Hi,
>>
>>am playing with a branch (complex_sco) from geoserver and suspect I have
>>discovered an issue that might be a wider one. I am seeking info on
>>whether anyone else has experienced this, its been fixed or even if it
>>has been properly tested ever before I go deeper into creating a test
>>case to prove it.
>>
>>i have a client that hits geoserver with two simultaenous requests on
>>the same feature type, with different filters. The result for each
>>filter is different (4 vs 40 features) when hit separately (and correct)
>>but it always returns the same result (arbitrarily one or the other)
>>when I hit it with simultaneous requests. When I use another
>>(identically configured) geoserver instance on another tomcat for one of
>>the layers the results are always correct.
>>
>>Does this sound familiar to anyone and are there any suggestions for an
>>easy way to test this in the unit testing framework?
>>
>>Rob Atkinson
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by:
>>Tame your development challenges with Apache's Geronimo App Server.
>>Download it for free - -and be entered to win a 42" plasma tv or your very
>>own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
>>_______________________________________________
>>Geoserver-devel mailing list
>>Geoserver-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server.
>Download it for free - -and be entered to win a 42" plasma tv or your very
>own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
>_______________________________________________
>Geoserver-devel mailing list
>Geoserver-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--