I have geoserver 1.7.4 setup with geowebcache… I’m noticing that it doesn’t appear to be working. I seed the layer with images (in this case I’m using the tiger_roads demo), but when I go to view the demo, the tiles are generated fresh all over again (I can see the renderer doing this in the command window). Is there a setting I need to tinker with to make gwc pull cached tiles rather than re-render each time?
Aaron
Aaron_Gundel@anonymised.com wrote:
I have geoserver 1.7.4 setup with geowebcache.... I'm noticing that it doesn't appear to be working. I seed the layer with images (in this case I'm using the tiger_roads demo), but when I go to view the demo, the tiles are generated fresh all over again (I can see the renderer doing this in the command window). Is there a setting I need to tinker with to make gwc pull cached tiles rather than re-render each time?
Aaron
Note sure. I took the release artifact, seeded layers 11 through 15 (EPSG:4326, default bounds, image/png), waited a few minutes, cleared browser cache and then looked at the layer using the EPSG:4326 Open Layers client.
Looking at the timestamps of the tiles, they are all from when I did the seeding, none were updated to the time when I was viewing them. This layer is pretty small and fast, but it also felt like the results were cached.
So I wonder,
1) How did you determine it was re-seeding?
2) Any error messages in the logs?
-Arne
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
Arne Kepp ha scritto:
So I wonder,
1) How did you determine it was re-seeding?
2) Any error messages in the logs?
I'm wondering about that "but when I go to view the demo, the tiles are generated fresh all over again".
Which demo?
If you're using the GeoServer one, well, that is
not using GWC tiles by design. You should look
in the GWC demos, that are setup to effectively
use the GWC tile structure.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Arne,
The messages are different now then when I last looked at them, but it looks like I’m getting a warning now – blob was expected to have size x but was y.
Not sure if it’s relevant, before I begin viewing the layers, there’s a message… ERROR [layer.TileLayerDispatcher] - Unable to determine configuration directory.
It does appear that the examples are working fine now – the tiger map of new york, for example. But my layers are simply not coming out right. I’m not sure if there’s something wrong with them that’s causing them to regenerate, or if they’re supposed to be naturally slow loading, or what. In firefox, the more intensive tiles (with more in them) take significantly longer to load than the blank tiles. (multiple seconds, 3-8… all of this after seeding).
I don’t know what I’m doing wrong here – If you could point me in the right direction, I’d very much appreciate it.
Aaron
Arne Kepp ak@anonymised.com
05/06/2009 06:00 PM
To
Aaron_Gundel@anonymised.com
cc
geoserver-users geoserver-users@lists.sourceforge.net
Subject
Re: [Geoserver-users] gwc re generation
Aaron_Gundel@anonymised.com wrote:
> I have geoserver 1.7.4 setup with geowebcache.... I'm noticing that it
> doesn't appear to be working. I seed the layer with images (in this case
> I'm using the tiger_roads demo), but when I go to view the demo, the tiles
> are generated fresh all over again (I can see the renderer doing this in
> the command window). Is there a setting I need to tinker with to make gwc
> pull cached tiles rather than re-render each time?
>
> Aaron
Note sure. I took the release artifact, seeded layers 11 through 15
(EPSG:4326, default bounds, image/png), waited a few minutes, cleared
browser cache and then looked at the layer using the EPSG:4326 Open
Layers client.
Looking at the timestamps of the tiles, they are all from when I did the
seeding, none were updated to the time when I was viewing them. This
layer is pretty small and fast, but it also felt like the results were
cached.
So I wonder,
1) How did you determine it was re-seeding?
2) Any error messages in the logs?
-Arne
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
You can ignore "ERROR [layer.TileLayerDispatcher] - Unable to determine configuration directory. ". In the next version the same message has been replaced with "Found no configuration file in ... If you are running GWC in GeoServer this is probably not a problem.". It's only an issue if you are trying to configure GWC manually.
I have gotten reports about "blob was expected to have size x but was y" during beta testing, but I have never been able to reproduce it and this is the first I have seen in a while. What it means is that GWC fetched a metatile, cut it into individual tiles, recorded the size of a tile into the H2 database and then wrote the tile to disk. Now it is reading the tile from disk again, but it's no longer the size it was when it was saved.
Can you give me some of the actual numbers for x and y, as well as what operating system, filesystem and output of java -version ?
In the past I suggested that the users who reported this try stopping GeoServer, wipe the entire gwc folder in your data directory. I'm not sure that solves it.
I will look into whether there is a way to handle this more gracefully.
-Arne
Aaron_Gundel@anonymised.com wrote:
Arne,
The messages are different now then when I last looked at them, but it looks like I'm getting a warning now -- blob was expected to have size x but was y.
Not sure if it's relevant, before I begin viewing the layers, there's a message.... ERROR [layer.TileLayerDispatcher] - Unable to determine configuration directory.
It does appear that the examples are working fine now -- the tiger map of new york, for example. But my layers are simply not coming out right. I'm not sure if there's something wrong with them that's causing them to regenerate, or if they're supposed to be naturally slow loading, or what. In firefox, the more intensive tiles (with more in them) take significantly longer to load than the blank tiles. (multiple seconds, 3-8.... all of this after seeding).
I don't know what I'm doing wrong here -- If you could point me in the right direction, I'd very much appreciate it.
Aaron
Arne Kepp <ak@anonymised.com> 05/06/2009 06:00 PM
To
Aaron_Gundel@anonymised.com
cc
geoserver-users <geoserver-users@lists.sourceforge.net>
Subject
Re: [Geoserver-users] gwc re generationAaron_Gundel@anonymised.com wrote:
I have geoserver 1.7.4 setup with geowebcache.... I'm noticing that it doesn't appear to be working. I seed the layer with images (in this
case
I'm using the tiger_roads demo), but when I go to view the demo, the
tiles
are generated fresh all over again (I can see the renderer doing this in
the command window). Is there a setting I need to tinker with to make
gwc
pull cached tiles rather than re-render each time?
Aaron
Note sure. I took the release artifact, seeded layers 11 through 15 (EPSG:4326, default bounds, image/png), waited a few minutes, cleared browser cache and then looked at the layer using the EPSG:4326 Open Layers client.Looking at the timestamps of the tiles, they are all from when I did the seeding, none were updated to the time when I was viewing them. This layer is pretty small and fast, but it also felt like the results were cached.
So I wonder,
1) How did you determine it was re-seeding?
2) Any error messages in the logs?-Arne
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
On Sat, May 9, 2009 at 11:32 PM, Arne Kepp <ak@anonymised.com> wrote:
I have gotten reports about "blob was expected to have size x but was
y" during beta testing, but I have never been able to reproduce it and
this is the first I have seen in a while. What it means is that GWC
fetched a metatile, cut it into individual tiles, recorded the size of a
tile into the H2 database and then wrote the tile to disk. Now it is
reading the tile from disk again, but it's no longer the size it was
when it was saved.
I've had this a number of times; it seems to be fairly easy to trigger
if someone tries to request a tile that was only very recently seeded.
Try this. This is how I managed to accidentally trigger it a few days
ago:
1. Start seeding a layer
2. Immediately after you start, go back to the demo page and try to
view it in the SRS you're seeding
3. The tiles you viewed should now be permanently "broken"; they will
always be requested from the server again, constantly being rewritten
to the cache because the file size doesn't match the H2 database.
Blowing out the entire cache does fix it, but it kinda sucks when
you've just spent two or three days seeding a bunch of layers and then
have to start all over because the last one got messed up. Would it be
difficult to add a db repair mode that would go through and rebuild a
new database by scanning for existing tile files and creating the H2
database entries? Actually this is how I first expected Seed mode to
behave (if that's how it is supposed to behave, it didn't seem to work
last time I tried it.)
--
This message brought to you by Speed of Light Beer
When you're approaching infinite mass
It's Speed of Light time!
Joshua M. Thompson wrote:
On Sat, May 9, 2009 at 11:32 PM, Arne Kepp <ak@anonymised.com> wrote:
I have gotten reports about "blob was expected to have size x but was
y" during beta testing, but I have never been able to reproduce it and
this is the first I have seen in a while. What it means is that GWC
fetched a metatile, cut it into individual tiles, recorded the size of a
tile into the H2 database and then wrote the tile to disk. Now it is
reading the tile from disk again, but it's no longer the size it was
when it was saved.
I've had this a number of times; it seems to be fairly easy to trigger
if someone tries to request a tile that was only very recently seeded.
Try this. This is how I managed to accidentally trigger it a few days
ago:1. Start seeding a layer
2. Immediately after you start, go back to the demo page and try to
view it in the SRS you're seeding
3. The tiles you viewed should now be permanently "broken"; they will
always be requested from the server again, constantly being rewritten
to the cache because the file size doesn't match the H2 database.Blowing out the entire cache does fix it, but it kinda sucks when
you've just spent two or three days seeding a bunch of layers and then
have to start all over because the last one got messed up. Would it be
difficult to add a db repair mode that would go through and rebuild a
new database by scanning for existing tile files and creating the H2
database entries? Actually this is how I first expected Seed mode to
behave (if that's how it is supposed to behave, it didn't seem to work
last time I tried it.
Resync is on the wishlist, but I don't have time allocated for it. Under normal circumstances gaps should be filled automatically (so it's not really an issue if they are out of sync), but this contradiction is a special case. It's still beyond me how the steps you suggest would trigger the bug, even if there is a synchronization loophole the tiles should be the same size.
The seeder was written on short notice and well before the H2 database came into play. That said, I would be surprised if checking for gaps in the database is significantly faster than checking tiles sequentially.
I strongly encourage you to file bugs when you see stuff like this, it's really invaluable feedback and I will try to reproduce using your tips later today.
Thanks,
-Arne
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
Arne Kepp wrote:
Joshua M. Thompson wrote:
On Sat, May 9, 2009 at 11:32 PM, Arne Kepp <ak@anonymised.com> wrote:
I have gotten reports about "blob was expected to have size x but was
y" during beta testing, but I have never been able to reproduce it and
this is the first I have seen in a while. What it means is that GWC
fetched a metatile, cut it into individual tiles, recorded the size of a
tile into the H2 database and then wrote the tile to disk. Now it is
reading the tile from disk again, but it's no longer the size it was
when it was saved.
I've had this a number of times; it seems to be fairly easy to trigger
if someone tries to request a tile that was only very recently seeded.
Try this. This is how I managed to accidentally trigger it a few days
ago:1. Start seeding a layer
2. Immediately after you start, go back to the demo page and try to
view it in the SRS you're seeding
3. The tiles you viewed should now be permanently "broken"; they will
always be requested from the server again, constantly being rewritten
to the cache because the file size doesn't match the H2 database.Blowing out the entire cache does fix it, but it kinda sucks when
you've just spent two or three days seeding a bunch of layers and then
have to start all over because the last one got messed up. Would it be
difficult to add a db repair mode that would go through and rebuild a
new database by scanning for existing tile files and creating the H2
database entries? Actually this is how I first expected Seed mode to
behave (if that's how it is supposed to behave, it didn't seem to work
last time I tried it.
Resync is on the wishlist, but I don't have time allocated for it. Under normal circumstances gaps should be filled automatically (so it's not really an issue if they are out of sync), but this contradiction is a special case. It's still beyond me how the steps you suggest would trigger the bug, even if there is a synchronization loophole the tiles should be the same size.
The seeder was written on short notice and well before the H2 database came into play. That said, I would be surprised if checking for gaps in the database is significantly faster than checking tiles sequentially.
I strongly encourage you to file bugs when you see stuff like this, it's really invaluable feedback and I will try to reproduce using your tips later today.
Thanks,
-Arne
I think I caught it. It was not seeding per se, but the machine had to be busy and querying a slow layer to reproduce this. Basically there is an optimistic execution path that circumvents locking for performance reasons, called tryFetch() This used to be safe because of file locking by the operating system, but a race condition was indeed introduced when I added the H2 datastore.
I have not been able to reproduce the size mismatch. It confuses me because the writing thread should have a write lock on the file, preventing the tryFetch() thread from getting a partial hit. Regardless, I think there is a good chance both issues have been fixed, I will create a snapshot of both the plugin and the standalone tomorrow, hopefully you will be able to confirm that the problem is gone.
-Arne
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
I’m running a win xp box with an ntfs file system and jdk 6 update 13.
As for exact x y values, that’ll be hard. There’s a long list of various values. Here are a few.
2009-05-08 11:58:23,400 WARN [conveyor.ConveyorTile] - Blob was expected to have size 902 but was 907
2009-05-08 11:58:23,400 WARN [conveyor.ConveyorTile] - Blob was expected to have size 902 but was 907
2009-05-08 11:58:23,400 WARN [conveyor.ConveyorTile] - Blob was expected to have size 930 but was 910
2009-05-08 11:58:24,791 WARN [conveyor.ConveyorTile] - Blob was expected to have size 930 but was 910
2009-05-08 11:58:36,463 WARN [conveyor.ConveyorTile] - Blob was expected to have size 2604 but was 2560
2009-05-08 11:58:36,463 WARN [conveyor.ConveyorTile] - Blob was expected to have size 2604 but was 2560
2009-05-08 11:58:36,463 WARN [conveyor.ConveyorTile] - Blob was expected to have size 6572 but was 6394
2009-05-08 11:58:36,478 WARN [conveyor.ConveyorTile] - Blob was expected to have size 5924 but was 5780
2009-05-08 11:58:36,478 WARN [conveyor.ConveyorTile] - Blob was expected to have size 2974 but was 2912
2009-05-08 11:58:36,478 WARN [conveyor.ConveyorTile] - Blob was expected to have size 2974 but was 2912
2009-05-08 11:58:37,088 WARN [conveyor.ConveyorTile] - Blob was expected to have size 1135 but was 1149
2009-05-08 11:58:37,103 WARN [conveyor.ConveyorTile] - Blob was expected to have size 1135 but was 1149
2009-05-08 11:58:37,650 WARN [conveyor.ConveyorTile] - Blob was expected to have size 1115 but was 1087
2009-05-08 11:58:37,650 WARN [conveyor.ConveyorTile] - Blob was expected to have size 1115 but was 1087
I will delete the directory and try again and see if it goes away…
Arne Kepp ak@anonymised.com
05/09/2009 08:33 PM
To
Aaron_Gundel@anonymised.com
cc
geoserver-users@lists.sourceforge.net
Subject
Re: [Geoserver-users] gwc re generation
You can ignore "ERROR [layer.TileLayerDispatcher] - Unable to determine
configuration directory. ". In the next version the same message has
been replaced with "Found no configuration file in ... If you are
running GWC in GeoServer this is probably not a problem.". It's only an
issue if you are trying to configure GWC manually.
I have gotten reports about "blob was expected to have size x but was
y" during beta testing, but I have never been able to reproduce it and
this is the first I have seen in a while. What it means is that GWC
fetched a metatile, cut it into individual tiles, recorded the size of a
tile into the H2 database and then wrote the tile to disk. Now it is
reading the tile from disk again, but it's no longer the size it was
when it was saved.
Can you give me some of the actual numbers for x and y, as well as what
operating system, filesystem and output of java -version ?
In the past I suggested that the users who reported this try stopping
GeoServer, wipe the entire gwc folder in your data directory. I'm not
sure that solves it.
I will look into whether there is a way to handle this more gracefully.
-Arne
Aaron_Gundel@anonymised.com wrote:
> Arne,
>
> The messages are different now then when I last looked at them, but it
> looks like I'm getting a warning now -- blob was expected to have size x
> but was y.
>
> Not sure if it's relevant, before I begin viewing the layers, there's a
> message.... ERROR [layer.TileLayerDispatcher] - Unable to determine
> configuration directory.
>
> It does appear that the examples are working fine now -- the tiger map of
> new york, for example. But my layers are simply not coming out right. I'm
> not sure if there's something wrong with them that's causing them to
> regenerate, or if they're supposed to be naturally slow loading, or what.
> In firefox, the more intensive tiles (with more in them) take
> significantly longer to load than the blank tiles. (multiple seconds,
> 3-8.... all of this after seeding).
>
> I don't know what I'm doing wrong here -- If you could point me in the
> right direction, I'd very much appreciate it.
>
> Aaron
>
>
>
>
> Arne Kepp <ak@anonymised.com>
> 05/06/2009 06:00 PM
>
> To
> Aaron_Gundel@anonymised.com
> cc
> geoserver-users <geoserver-users@lists.sourceforge.net>
> Subject
> Re: [Geoserver-users] gwc re generation
>
>
>
>
>
>
> Aaron_Gundel@anonymised.com wrote:
>
>> I have geoserver 1.7.4 setup with geowebcache.... I'm noticing that it
>> doesn't appear to be working. I seed the layer with images (in this
>>
> case
>
>> I'm using the tiger_roads demo), but when I go to view the demo, the
>>
> tiles
>
>> are generated fresh all over again (I can see the renderer doing this in
>>
>
>
>> the command window). Is there a setting I need to tinker with to make
>>
> gwc
>
>> pull cached tiles rather than re-render each time?
>>
>> Aaron
>>
>
> Note sure. I took the release artifact, seeded layers 11 through 15
> (EPSG:4326, default bounds, image/png), waited a few minutes, cleared
> browser cache and then looked at the layer using the EPSG:4326 Open
> Layers client.
>
> Looking at the timestamps of the tiles, they are all from when I did the
> seeding, none were updated to the time when I was viewing them. This
> layer is pretty small and fast, but it also felt like the results were
> cached.
>
> So I wonder,
> 1) How did you determine it was re-seeding?
> 2) Any error messages in the logs?
>
> -Arne
>
>
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
Blowing out the gwc directory seems to have solved the issue. In further consideration, this issue is likely due to me partially blowing out the gwc directory to refresh the tiles (a specific directory) and not blowing out the h2 database also. I did this because I couldn’t get the reseed functionality to work after I modified the sld in geoserver (I made my tiles transparent when I changed them, wheras before I couldn’t see through them). So I blew out the directory containing the images and reseeded. Then I started seeing this error, along with the significantly degraded performance. Is there a cleaner way for me to reseed the tiles after modifying the sld?
Aaron
Arne Kepp ak@anonymised.com
05/09/2009 08:33 PM
To
Aaron_Gundel@anonymised.com
cc
geoserver-users@lists.sourceforge.net
Subject
Re: [Geoserver-users] gwc re generation
You can ignore "ERROR [layer.TileLayerDispatcher] - Unable to determine
configuration directory. ". In the next version the same message has
been replaced with "Found no configuration file in ... If you are
running GWC in GeoServer this is probably not a problem.". It's only an
issue if you are trying to configure GWC manually.
I have gotten reports about "blob was expected to have size x but was
y" during beta testing, but I have never been able to reproduce it and
this is the first I have seen in a while. What it means is that GWC
fetched a metatile, cut it into individual tiles, recorded the size of a
tile into the H2 database and then wrote the tile to disk. Now it is
reading the tile from disk again, but it's no longer the size it was
when it was saved.
Can you give me some of the actual numbers for x and y, as well as what
operating system, filesystem and output of java -version ?
In the past I suggested that the users who reported this try stopping
GeoServer, wipe the entire gwc folder in your data directory. I'm not
sure that solves it.
I will look into whether there is a way to handle this more gracefully.
-Arne
Aaron_Gundel@anonymised.com wrote:
> Arne,
>
> The messages are different now then when I last looked at them, but it
> looks like I'm getting a warning now -- blob was expected to have size x
> but was y.
>
> Not sure if it's relevant, before I begin viewing the layers, there's a
> message.... ERROR [layer.TileLayerDispatcher] - Unable to determine
> configuration directory.
>
> It does appear that the examples are working fine now -- the tiger map of
> new york, for example. But my layers are simply not coming out right. I'm
> not sure if there's something wrong with them that's causing them to
> regenerate, or if they're supposed to be naturally slow loading, or what.
> In firefox, the more intensive tiles (with more in them) take
> significantly longer to load than the blank tiles. (multiple seconds,
> 3-8.... all of this after seeding).
>
> I don't know what I'm doing wrong here -- If you could point me in the
> right direction, I'd very much appreciate it.
>
> Aaron
>
>
>
>
> Arne Kepp <ak@anonymised.com>
> 05/06/2009 06:00 PM
>
> To
> Aaron_Gundel@anonymised.com
> cc
> geoserver-users <geoserver-users@lists.sourceforge.net>
> Subject
> Re: [Geoserver-users] gwc re generation
>
>
>
>
>
>
> Aaron_Gundel@anonymised.com wrote:
>
>> I have geoserver 1.7.4 setup with geowebcache.... I'm noticing that it
>> doesn't appear to be working. I seed the layer with images (in this
>>
> case
>
>> I'm using the tiger_roads demo), but when I go to view the demo, the
>>
> tiles
>
>> are generated fresh all over again (I can see the renderer doing this in
>>
>
>
>> the command window). Is there a setting I need to tinker with to make
>>
> gwc
>
>> pull cached tiles rather than re-render each time?
>>
>> Aaron
>>
>
> Note sure. I took the release artifact, seeded layers 11 through 15
> (EPSG:4326, default bounds, image/png), waited a few minutes, cleared
> browser cache and then looked at the layer using the EPSG:4326 Open
> Layers client.
>
> Looking at the timestamps of the tiles, they are all from when I did the
> seeding, none were updated to the time when I was viewing them. This
> layer is pretty small and fast, but it also felt like the results were
> cached.
>
> So I wonder,
> 1) How did you determine it was re-seeding?
> 2) Any error messages in the logs?
>
> -Arne
>
>
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
Arne Kepp wrote:
Joshua M. Thompson wrote:
On Sat, May 9, 2009 at 11:32 PM, Arne Kepp <ak@anonymised.com> wrote:
I have gotten reports about "blob was expected to have size x but was
y" during beta testing, but I have never been able to reproduce it and
this is the first I have seen in a while. What it means is that GWC
fetched a metatile, cut it into individual tiles, recorded the size of a
tile into the H2 database and then wrote the tile to disk. Now it is
reading the tile from disk again, but it's no longer the size it was
when it was saved.
I've had this a number of times; it seems to be fairly easy to trigger
if someone tries to request a tile that was only very recently seeded.
Try this. This is how I managed to accidentally trigger it a few days
ago:1. Start seeding a layer
2. Immediately after you start, go back to the demo page and try to
view it in the SRS you're seeding
3. The tiles you viewed should now be permanently "broken"; they will
always be requested from the server again, constantly being rewritten
to the cache because the file size doesn't match the H2 database.Blowing out the entire cache does fix it, but it kinda sucks when
you've just spent two or three days seeding a bunch of layers and then
have to start all over because the last one got messed up. Would it be
difficult to add a db repair mode that would go through and rebuild a
new database by scanning for existing tile files and creating the H2
database entries? Actually this is how I first expected Seed mode to
behave (if that's how it is supposed to behave, it didn't seem to work
last time I tried it.
Hi Thomas,
if you have a chance, could you please try replacing geowebcache*.jar in WEB-INF/lib with this one ? (Be sure to move the old copy out of lib)
http://repo.opengeo.org/org/opengeo/geowebcache/1.1-SNAPSHOT/geowebcache-1.1-20090512.120147-8.jar
Note that it does perform an upgrade on the H2 database, so if the tiles are valuable then please move them temporarily and start with an empty tree.
Let me know if you have a chance to test it, your help would be greatly appreciated.
-Arne
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers
On Wed, May 13, 2009 at 6:18 AM, Arne Kepp <ak@anonymised.com> wrote:
if you have a chance, could you please try replacing geowebcache*.jar in
WEB-INF/lib with this one ? (Be sure to move the old copy out of lib)http://repo.opengeo.org/org/opengeo/geowebcache/1.1-SNAPSHOT/geowebcache-1.1-20090512.120147-8.jar
Note that it does perform an upgrade on the H2 database, so if the tiles are
valuable then please move them temporarily and start with an empty tree.Let me know if you have a chance to test it, your help would be greatly
appreciated.
I just installed this here and tried it by starting a seed on a
somewhat complex layer and then trying to view it from the demo page.
Previously this would trigger the bug almost immediately, but despite
my best attempts at tripping it up I can't make it fail anymore. I
think you nailed the bug!
--
This message brought to you by Speed of Light Beer
When you're approaching infinite mass
It's Speed of Light time!
Joshua M. Thompson wrote:
On Wed, May 13, 2009 at 6:18 AM, Arne Kepp <ak@anonymised.com> wrote:
if you have a chance, could you please try replacing geowebcache*.jar in
WEB-INF/lib with this one ? (Be sure to move the old copy out of lib)http://repo.opengeo.org/org/opengeo/geowebcache/1.1-SNAPSHOT/geowebcache-1.1-20090512.120147-8.jar
Note that it does perform an upgrade on the H2 database, so if the tiles are
valuable then please move them temporarily and start with an empty tree.Let me know if you have a chance to test it, your help would be greatly
appreciated.
I just installed this here and tried it by starting a seed on a
somewhat complex layer and then trying to view it from the demo page.
Previously this would trigger the bug almost immediately, but despite
my best attempts at tripping it up I can't make it fail anymore. I
think you nailed the bug!
Great, thanks for the procedure to reproduce it, I think the layers I was testing with earlier were too fast or too slow (from WMS) to trigger it.
Will wrap up 1.1.1 and a "new" plugin.
-Arne
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers