Ok, this one has me stumped. I have a functioning installation of
GeoServer 2.1rc5 that I am trying to migrate over to a newer, much
beefier server. Both servers are 64-bit Linux servers; the old one
running SuSE 9.4 and new one version 11.1. Other than the OS and the
better hardware, however, the two environments are prety much
identical: same Tomcat version (5.5.33), same JVM version (1.6.0_26
64-bit).
To minimize problems while testing the new server is running with an
exact copy of the geoserver webapp and data directory (the two servers
use identical file system layouts.) It *should* behave identically.
Except, it doesn't.
The problem I've run into is with my BlueMarble 500m layer. It's
configured in GS as six GeoTIFFs, and a custom geowebcache.xml that
publishes them as a single cached layer through GWC:
<wmsLayer>
<name>bluemarble-500m</name>
<mimeFormats>
<string>image/jpeg</string>
</mimeFormats>
<wmsUrl>
<string>http://localhost:8080/geoserver/wms</string>
</wmsUrl>
<wmsLayers>public:BlueMarble500mA1,public:BlueMarble500mA2,public:BlueMarble500mB1,public:BlueMarble500mB2,public:BlueMarble500mC1,public:BlueMarble500mC2,public:BlueMarble500mD1,public:BlueMarble500mD2</wmsLayers>
<tiled>false</tiled>
<transparent>false</transparent>
</wmsLayer>
On the old server this works fine, and I end up with a nice tiled &
cached world map for my clients. On the new server however, GWC seems
to be duplicating the same tiles over and over, and I end up with
this:
http://llmap.org/gwc-tiling-error.png
What really confuses me is that s similarly configured GWC layer using
vector data sources works just fine, and the same GeoTIFF layers
published as an uncached layer group in geoserver also renders
fine...unless I try to view the layer group through GWC, at which
point I end up with the same mangled map.
I get the same results if I update the new server to GeoServer 2.1 or
2.1.1. Since I'm not seeing anything in Google about GWC generating
incorrect tiles I'm hoping I just did something silly here that I'm
not seeing. Any clues?
On Wed, Jul 6, 2011 at 3:28 PM, Joshua M. Thompson
<joshua.thompson@anonymised.com> wrote:
On the old server this works fine, and I end up with a nice tiled &
cached world map for my clients. On the new server however, GWC seems
to be duplicating the same tiles over and over, and I end up with
this:
http://llmap.org/gwc-tiling-error.png
I hate to reply to my own message already, but I finally figured this
out. The new server had native JAI, but not JAI-ImageIO installed.
Installing the JAI-ImageIO extensions solved the issue.
I hate to reply to my own message already, but I finally figured this
out. The new server had native JAI, but not JAI-ImageIO installed.
Installing the JAI-ImageIO extensions solved the issue.
sorry I didn't see the question before. That's just what I was going
to ask. Glad you figured it out.
Am I right that after installing Jai-ImageIO you needed to truncate
the cache in order for the tiles to be correctly generated?
Cheers,
Gabriel
On Wed, Jul 6, 2011 at 10:21 PM, Gabriel Roldan <groldan@anonymised.com> wrote:
I hate to reply to my own message already, but I finally figured this
out. The new server had native JAI, but not JAI-ImageIO installed.
Installing the JAI-ImageIO extensions solved the issue.
sorry I didn't see the question before. That's just what I was going
to ask. Glad you figured it out.
Am I right that after installing Jai-ImageIO you needed to truncate
the cache in order for the tiles to be correctly generated?
Yes, I was wiping the cache every time I arn another test. The tiles
were definitely generated incorrectly; I could tell by the file sizes
on many tiles being identical.
So is that (JAI but no JAI-ImageIO) an invalid configuration? If so
geoserver should probably complain loudly when it sees that, because
there was nothing in the logs to indicate anything was amiss. I only
noticed it by comparing the server status screens.
On Thu, Jul 7, 2011 at 5:14 AM, Joshua M. Thompson <joshua.thompson@anonymised.com> wrote:
On Wed, Jul 6, 2011 at 10:21 PM, Gabriel Roldan <groldan@anonymised.com> wrote:
I hate to reply to my own message already, but I finally figured this
out. The new server had native JAI, but not JAI-ImageIO installed.
Installing the JAI-ImageIO extensions solved the issue.
sorry I didn’t see the question before. That’s just what I was going
to ask. Glad you figured it out.
Am I right that after installing Jai-ImageIO you needed to truncate
the cache in order for the tiles to be correctly generated?
Yes, I was wiping the cache every time I arn another test. The tiles
were definitely generated incorrectly; I could tell by the file sizes
on many tiles being identical.
So is that (JAI but no JAI-ImageIO) an invalid configuration? If so
geoserver should probably complain loudly when it sees that, because
there was nothing in the logs to indicate anything was amiss. I only
noticed it by comparing the server status screens.
Sounds more like just a bug to me. Normally devs have one particular
dev setup (e.g., particular jdk and all jai libraries installed)
and might not see the issue if it happens only with a different config
Cheers
Andrea
–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
after the gwc improvements backport (post 2.1.1), 2.1.x use the same
rendering routine than GeoServer itself to create the tiles out of the
metatile RenderedImage. It actually calls
RenderedImageMapResponse.write(...). So there should be no difference,
if GeoServer's WMS can render it, then GWC can. AT LEAST there's some
misbehavior depending on whether RenderedImageMapResponse.write(...)
receives a RenderedImage or a BufferedImage (gwc gives it a
RenderedImage product of a JAI crop operation. But I doubt that'd be
the case, as there are all kinds on clever tricks inside the
RenderedImageMapResponse to account for that kind of things?
Cheers,
Gabriel
On Thu, Jul 7, 2011 at 4:52 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
On Thu, Jul 7, 2011 at 5:14 AM, Joshua M. Thompson
<joshua.thompson@anonymised.com> wrote:
On Wed, Jul 6, 2011 at 10:21 PM, Gabriel Roldan <groldan@anonymised.com>
wrote:
>>
>> I hate to reply to my own message already, but I finally figured this
>> out. The new server had native JAI, but not JAI-ImageIO installed.
>> Installing the JAI-ImageIO extensions solved the issue.
> sorry I didn't see the question before. That's just what I was going
> to ask. Glad you figured it out.
>
> Am I right that after installing Jai-ImageIO you needed to truncate
> the cache in order for the tiles to be correctly generated?
Yes, I was wiping the cache every time I arn another test. The tiles
were definitely generated incorrectly; I could tell by the file sizes
on many tiles being identical.
So is that (JAI but no JAI-ImageIO) an invalid configuration? If so
geoserver should probably complain loudly when it sees that, because
there was nothing in the logs to indicate anything was amiss. I only
noticed it by comparing the server status screens.
Sounds more like just a bug to me. Normally devs have one particular
dev setup (e.g., particular jdk and all jai libraries installed)
and might not see the issue if it happens only with a different config
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On Wed, Jul 13, 2011 at 10:25 PM, Gabriel Roldan <groldan@anonymised.com> wrote:
after the gwc improvements backport (post 2.1.1), 2.1.x use the same
rendering routine than GeoServer itself to create the tiles out of the
metatile RenderedImage. It actually calls
RenderedImageMapResponse.write(...). So there should be no difference,
if GeoServer's WMS can render it, then GWC can. AT LEAST there's some
misbehavior depending on whether RenderedImageMapResponse.write(...)
receives a RenderedImage or a BufferedImage (gwc gives it a
RenderedImage product of a JAI crop operation. But I doubt that'd be
the case, as there are all kinds on clever tricks inside the
RenderedImageMapResponse to account for that kind of things?
Gabriel, I've definitely seen that error too, just not sure if it's still there.
The JPEG writer is never happy about tiled images with origin != 0,
if you are meta-tiling and slicing you have to care for that or you'll
get errors.
The ImageWorker class has a write jpeg method that takes care of that,
but I guess GWC code is not depending on geotools coverage module,
and thus cannot use that method?
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
On Wed, Jul 13, 2011 at 5:38 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
On Wed, Jul 13, 2011 at 10:25 PM, Gabriel Roldan <groldan@anonymised.com> wrote:
after the gwc improvements backport (post 2.1.1), 2.1.x use the same
rendering routine than GeoServer itself to create the tiles out of the
metatile RenderedImage. It actually calls
RenderedImageMapResponse.write(...). So there should be no difference,
if GeoServer's WMS can render it, then GWC can. AT LEAST there's some
misbehavior depending on whether RenderedImageMapResponse.write(...)
receives a RenderedImage or a BufferedImage (gwc gives it a
RenderedImage product of a JAI crop operation. But I doubt that'd be
the case, as there are all kinds on clever tricks inside the
RenderedImageMapResponse to account for that kind of things?
Gabriel, I've definitely seen that error too, just not sure if it's still there.
The JPEG writer is never happy about tiled images with origin != 0,
if you are meta-tiling and slicing you have to care for that or you'll
get errors.
The ImageWorker class has a write jpeg method that takes care of that,
but I guess GWC code is not depending on geotools coverage module,
and thus cannot use that method?
I guess that holds true for vanilla gwc, but as mentioned above,
embedded geoserver layers do use the same rendering path than
geoserver's WMS, which in turn calls ImageWorker if I'm not mistaken,
and the specific subclass of RenderedImageMapResponse will take care
of calling the appropriate ImageWorker method as well of any extra
image preparation, right?
Gabriel
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On Thu, Jul 14, 2011 at 4:33 AM, Gabriel Roldan <groldan@anonymised.com> wrote:
I guess that holds true for vanilla gwc, but as mentioned above,
embedded geoserver layers do use the same rendering path than
geoserver's WMS, which in turn calls ImageWorker if I'm not mistaken,
and the specific subclass of RenderedImageMapResponse will take care
of calling the appropriate ImageWorker method as well of any extra
image preparation, right?
Nope, this is not about image preparation, it's image encoding.
If you do meta-tiling I expect you to get the image rendered by the WMS,
clip it into 9-16 parts and encode in jpeg. That part is the one that breaks,
because all tiles but the one in the upper/right corner will have an origin
other than 0,0
That's where you need to use image worker, when encoding the image
in jpeg
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
On Thu, Jul 14, 2011 at 4:50 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
On Thu, Jul 14, 2011 at 4:33 AM, Gabriel Roldan <groldan@anonymised.com> wrote:
I guess that holds true for vanilla gwc, but as mentioned above,
embedded geoserver layers do use the same rendering path than
geoserver's WMS, which in turn calls ImageWorker if I'm not mistaken,
and the specific subclass of RenderedImageMapResponse will take care
of calling the appropriate ImageWorker method as well of any extra
image preparation, right?
Nope, this is not about image preparation, it's image encoding.
If you do meta-tiling I expect you to get the image rendered by the WMS,
clip it into 9-16 parts and encode in jpeg. That part is the one that breaks,
because all tiles but the one in the upper/right corner will have an origin
other than 0,0
That's where you need to use image worker, when encoding the image
in jpeg
And that's what I mean. Though reading back in my previous email I
should have sayd embedded layers use the same encoding than geoserver,
not the same rendering. Though that also holds true, it was not the
point.
At the time of saving the tiles out from the metatile, the following
line of code gets a org.geoserver.wms.map.JPEGMapResponse:
<https://github.com/groldan/geoserver_trunk/blob/master/gwc/src/main/java/org/geoserver/gwc/layer/GeoServerMetaTile.java#L63>
which in turn calls ImageWorker, which in turn takes care of the origin issue.
Cheers,
Gabriel
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
