[Geoserver-users] DescribeFeatureType timeout when trying to connect to WFS layer

GeoServer GeoServer User
,
1

I am trying to connect to my layer, created as PostGIS (2.1) view through Geoserver 2.3.5. The problem is, that every request ends with error:

Network request timed out. (in QGIS)

I tried to discover the cause using Google, but I wasnt succesful. Please let me know, if you need more information,

Miloš Kroulík

2

Hi Miloš,
Hmmm, I just tried this myself using the “demos” page on GeoServer. It took an inordinantely long time to get a response to the first request (well over a minute). But once a request had succeeded, following requests were almost instantaneous, even for information about other tables.

I can replicate it fairly easily (I’m using Oracle):

First request: 66 seconds! (though it can be as “low” as 9 seconds).
Following requests (any layer) - less than 0.5 seconds.

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

Clearing the resource cache resets it back to super-slow.

I’ll report it as a bug; at the very least there’s obvious scope for optimisation.

Miloš - Assuming you don’t restart your server, once the first one has been served following ones should hopefully be faster.

Regards,
Jonathan

On 23 September 2013 23:15, Miloš Kroulík <milos.kroulik@anonymised.com> wrote:

I am trying to connect to my layer, created as PostGIS (2.1) view through Geoserver 2.3.5. The problem is, that every request ends with error:

Network request timed out. (in QGIS)

I tried to discover the cause using Google, but I wasnt succesful. Please let me know, if you need more information,

Miloš Kroulík

October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

3

Hi Jonathan,

thanks you for your response. I thought, that it might be caused by restricted service (via service access rules), but then I restricted only GetCapabilities request and the error persisted. I managed to make it work only by restart - which is of course unacceptable in production environment. Can you, please, direct me to the bug you reported so I can watch the progress?

Regards,

···

Miloš

2013/9/24 Jonathan Moules <jonathanmoules@anonymised.com>

Hi Miloš,
Hmmm, I just tried this myself using the “demos” page on GeoServer. It took an inordinantely long time to get a response to the first request (well over a minute). But once a request had succeeded, following requests were almost instantaneous, even for information about other tables.

I can replicate it fairly easily (I’m using Oracle):

First request: 66 seconds! (though it can be as “low” as 9 seconds).
Following requests (any layer) - less than 0.5 seconds.

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

Clearing the resource cache resets it back to super-slow.

I’ll report it as a bug; at the very least there’s obvious scope for optimisation.

Miloš - Assuming you don’t restart your server, once the first one has been served following ones should hopefully be faster.

Regards,
Jonathan

On 23 September 2013 23:15, Miloš Kroulík <milos.kroulik@anonymised.com> wrote:

I am trying to connect to my layer, created as PostGIS (2.1) view through Geoserver 2.3.5. The problem is, that every request ends with error:

Network request timed out. (in QGIS)

I tried to discover the cause using Google, but I wasnt succesful. Please let me know, if you need more information,

Miloš Kroulík

October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

4

Hi Jonathan,

thanks for the link. My case seems to be rather different. I finally discovered, that timeout is hapenning directly after trying to save modified feature through WFS-T (which is not succesful and ends with with “empty response” message). I filed bug report at http://jira.codehaus.org/browse/GEOS-6059. Perhaps it’s problem with my PostgreSQL server. Thnaks once again for your help.

Regards,

···

Miloš

2013/9/26 Jonathan Moules <jonathanmoules@anonymised.com>

Hi Miloš,

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

My report is here - http://jira.codehaus.org/browse/GEOS-6048 - it may or may not be the same cause/issue as yours, but it seemed like it to me. Does yours get faster after the first query has suceeded? If not it may be something else.
Regards,
Jonathan

On 26 September 2013 13:18, Miloš Kroulík <milos.kroulik@anonymised.com> wrote:

Hi Jonathan,

thanks you for your response. I thought, that it might be caused by restricted service (via service access rules), but then I restricted only GetCapabilities request and the error persisted. I managed to make it work only by restart - which is of course unacceptable in production environment. Can you, please, direct me to the bug you reported so I can watch the progress?

Regards,

Miloš

2013/9/24 Jonathan Moules <jonathanmoules@anonymised.com>

Hi Miloš,
Hmmm, I just tried this myself using the “demos” page on GeoServer. It took an inordinantely long time to get a response to the first request (well over a minute). But once a request had succeeded, following requests were almost instantaneous, even for information about other tables.

I can replicate it fairly easily (I’m using Oracle):

First request: 66 seconds! (though it can be as “low” as 9 seconds).
Following requests (any layer) - less than 0.5 seconds.

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

Clearing the resource cache resets it back to super-slow.

I’ll report it as a bug; at the very least there’s obvious scope for optimisation.

Miloš - Assuming you don’t restart your server, once the first one has been served following ones should hopefully be faster.

Regards,
Jonathan

On 23 September 2013 23:15, Miloš Kroulík <milos.kroulik@anonymised.com> wrote:

I am trying to connect to my layer, created as PostGIS (2.1) view through Geoserver 2.3.5. The problem is, that every request ends with error:

Network request timed out. (in QGIS)

I tried to discover the cause using Google, but I wasnt succesful. Please let me know, if you need more information,

Miloš Kroulík

October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

5

Hi Miloš,
No problem. Just a thought, but if you think it’s PostgreSQL, how about trying to connect directly to it with QGIS during this timeout period and seeing if it responds? That’ll help determine where the issue lies.
Regards,
Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

On 1 October 2013 13:16, Miloš Kroulík <milos.kroulik@anonymised.com> wrote:

Hi Jonathan,

thanks for the link. My case seems to be rather different. I finally discovered, that timeout is hapenning directly after trying to save modified feature through WFS-T (which is not succesful and ends with with “empty response” message). I filed bug report at http://jira.codehaus.org/browse/GEOS-6059. Perhaps it’s problem with my PostgreSQL server. Thnaks once again for your help.

Regards,

Miloš

2013/9/26 Jonathan Moules <jonathanmoules@anonymised.com>

Hi Miloš,

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

My report is here - http://jira.codehaus.org/browse/GEOS-6048 - it may or may not be the same cause/issue as yours, but it seemed like it to me. Does yours get faster after the first query has suceeded? If not it may be something else.
Regards,
Jonathan

On 26 September 2013 13:18, Miloš Kroulík <milos.kroulik@anonymised.com> wrote:

Hi Jonathan,

thanks you for your response. I thought, that it might be caused by restricted service (via service access rules), but then I restricted only GetCapabilities request and the error persisted. I managed to make it work only by restart - which is of course unacceptable in production environment. Can you, please, direct me to the bug you reported so I can watch the progress?

Regards,

Miloš

2013/9/24 Jonathan Moules <jonathanmoules@anonymised.com>

Hi Miloš,
Hmmm, I just tried this myself using the “demos” page on GeoServer. It took an inordinantely long time to get a response to the first request (well over a minute). But once a request had succeeded, following requests were almost instantaneous, even for information about other tables.

I can replicate it fairly easily (I’m using Oracle):

First request: 66 seconds! (though it can be as “low” as 9 seconds).
Following requests (any layer) - less than 0.5 seconds.

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

Clearing the resource cache resets it back to super-slow.

I’ll report it as a bug; at the very least there’s obvious scope for optimisation.

Miloš - Assuming you don’t restart your server, once the first one has been served following ones should hopefully be faster.

Regards,
Jonathan

On 23 September 2013 23:15, Miloš Kroulík <milos.kroulik@anonymised.com> wrote:

I am trying to connect to my layer, created as PostGIS (2.1) view through Geoserver 2.3.5. The problem is, that every request ends with error:

Network request timed out. (in QGIS)

I tried to discover the cause using Google, but I wasnt succesful. Please let me know, if you need more information,

Miloš Kroulík

October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

6

Hi,

thanks for a suggestion, but I can’t try it, because WFS request freezes QGIS, until it times out. Instead, I tried to edit feature directly through PostGIS connection, which succeded. It seems to me, that the issue lies in permissions. Because all my layers are protected (both read & write), I set up my catalog mode to “challenge” in Geoserver. I just don’t know, if that may cause my problem.

···

Miloš

2013/10/1 Jonathan Moules <jonathanmoules@anonymised.com>

Hi Miloš,
No problem. Just a thought, but if you think it’s PostgreSQL, how about trying to connect directly to it with QGIS during this timeout period and seeing if it responds? That’ll help determine where the issue lies.
Regards,
Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

On 1 October 2013 13:16, Miloš Kroulík <milos.kroulik@anonymised.com> wrote:

Hi Jonathan,

thanks for the link. My case seems to be rather different. I finally discovered, that timeout is hapenning directly after trying to save modified feature through WFS-T (which is not succesful and ends with with “empty response” message). I filed bug report at http://jira.codehaus.org/browse/GEOS-6059. Perhaps it’s problem with my PostgreSQL server. Thnaks once again for your help.

Regards,

Miloš

2013/9/26 Jonathan Moules <jonathanmoules@anonymised.com>

Hi Miloš,

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

My report is here - http://jira.codehaus.org/browse/GEOS-6048 - it may or may not be the same cause/issue as yours, but it seemed like it to me. Does yours get faster after the first query has suceeded? If not it may be something else.
Regards,
Jonathan

On 26 September 2013 13:18, Miloš Kroulík <milos.kroulik@anonymised.com> wrote:

Hi Jonathan,

thanks you for your response. I thought, that it might be caused by restricted service (via service access rules), but then I restricted only GetCapabilities request and the error persisted. I managed to make it work only by restart - which is of course unacceptable in production environment. Can you, please, direct me to the bug you reported so I can watch the progress?

Regards,

Miloš

2013/9/24 Jonathan Moules <jonathanmoules@anonymised.com>

Hi Miloš,
Hmmm, I just tried this myself using the “demos” page on GeoServer. It took an inordinantely long time to get a response to the first request (well over a minute). But once a request had succeeded, following requests were almost instantaneous, even for information about other tables.

I can replicate it fairly easily (I’m using Oracle):

First request: 66 seconds! (though it can be as “low” as 9 seconds).
Following requests (any layer) - less than 0.5 seconds.

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

Clearing the resource cache resets it back to super-slow.

I’ll report it as a bug; at the very least there’s obvious scope for optimisation.

Miloš - Assuming you don’t restart your server, once the first one has been served following ones should hopefully be faster.

Regards,
Jonathan

On 23 September 2013 23:15, Miloš Kroulík <milos.kroulik@anonymised.com> wrote:

I am trying to connect to my layer, created as PostGIS (2.1) view through Geoserver 2.3.5. The problem is, that every request ends with error:

Network request timed out. (in QGIS)

I tried to discover the cause using Google, but I wasnt succesful. Please let me know, if you need more information,

Miloš Kroulík

October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

7

Hi Paul,

I checked my layer settings and SRS settings are set up. Thanks for a suggestion.

Regards,

···

Miloš

2013/10/1 Paulius Litvinas <paulius@anonymised.com…4984…>

As I remember if in GeoServer layer settings Native SRS is not defined or are not as Declared SRS – WFS editing does not work (you are able to connect, to add WFS layer to QGIS and Access its properties, but then try to commit changes – the error apears and (if i am not wrong) GeoServer should be restarted to try again.

Sincerely,

Paul

From: Miloš Kroulík [mailto:milos.kroulik@anonymised.com]
Sent: Tuesday, October 01, 2013 3:54 PM
To: Jonathan Moules
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] DescribeFeatureType timeout when trying to connect to WFS layer

Hi,

thanks for a suggestion, but I can’t try it, because WFS request freezes QGIS, until it times out. Instead, I tried to edit feature directly through PostGIS connection, which succeded. It seems to me, that the issue lies in permissions. Because all my layers are protected (both read & write), I set up my catalog mode to “challenge” in Geoserver. I just don’t know, if that may cause my problem.

Miloš

2013/10/1 Jonathan Moules <jonathanmoules@anonymised.com>

Hi Miloš,

No problem. Just a thought, but if you think it’s PostgreSQL, how about trying to connect directly to it with QGIS during this timeout period and seeing if it responds? That’ll help determine where the issue lies.

Regards,

Jonathan

On 1 October 2013 13:16, Miloš Kroulík <milos.kroulik@anonymised.com> wrote:

Hi Jonathan,

thanks for the link. My case seems to be rather different. I finally discovered, that timeout is hapenning directly after trying to save modified feature through WFS-T (which is not succesful and ends with with “empty response” message). I filed bug report at http://jira.codehaus.org/browse/GEOS-6059. Perhaps it’s problem with my PostgreSQL server. Thnaks once again for your help.

Regards,

Miloš

2013/9/26 Jonathan Moules <jonathanmoules@anonymised.com>

Hi Miloš,

My report is here - http://jira.codehaus.org/browse/GEOS-6048 - it may or may not be the same cause/issue as yours, but it seemed like it to me. Does yours get faster after the first query has suceeded? If not it may be something else.

Regards,

Jonathan

On 26 September 2013 13:18, Miloš Kroulík <milos.kroulik@anonymised.com> wrote:

Hi Jonathan,

thanks you for your response. I thought, that it might be caused by restricted service (via service access rules), but then I restricted only GetCapabilities request and the error persisted. I managed to make it work only by restart - which is of course unacceptable in production environment. Can you, please, direct me to the bug you reported so I can watch the progress?

Regards,

Miloš

2013/9/24 Jonathan Moules <jonathanmoules@anonymised.com>

Hi Miloš,

Hmmm, I just tried this myself using the “demos” page on GeoServer. It took an inordinantely long time to get a response to the first request (well over a minute). But once a request had succeeded, following requests were almost instantaneous, even for information about other tables.

I can replicate it fairly easily (I’m using Oracle):

First request: 66 seconds! (though it can be as “low” as 9 seconds).

Following requests (any layer) - less than 0.5 seconds.

Clearing the resource cache resets it back to super-slow.

I’ll report it as a bug; at the very least there’s obvious scope for optimisation.

Miloš - Assuming you don’t restart your server, once the first one has been served following ones should hopefully be faster.

Regards,

Jonathan

On 23 September 2013 23:15, Miloš Kroulík <milos.kroulik@anonymised.com> wrote:

I am trying to connect to my layer, created as PostGIS (2.1) view through Geoserver 2.3.5. The problem is, that every request ends with error:

Network request timed out. (in QGIS)

I tried to discover the cause using Google, but I wasnt succesful. Please let me know, if you need more information,

Miloš Kroulík

October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.