Uploaded image for project: 'GeoServer'
  1. GEOS-5151

DataAccess full type name listing called multiple times in OGC request against SQL views

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Medium
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.10.4, 2.11.1
    • Component/s: WFS
    • Labels:
      None

      Description

      I'm making a wfs request against a geoserver sql view (not a database view) and to generate the response multiple calls are made to retrieve the list of tables from the database. The datastore is oracle in my case, and getting the list of tables is prohibitively slow. Calling it multiple times only exacerbates the issue.

      I've traced through the request, and 3 calls are made during the course of serving up the wfs request. I was using the 2.5 suite version of geoserver. Here's a rough outline of what's happening.

      All the getTables calls are made from the geotools JDBCDataStore::createTypeNames call. But, they all follow a slightly different path to get there. All 3 start from ResourcePool::getFeatureSource. First a check is made to see if the dataStore is a JDBC store and there is a virtual table. If so, then the virtual table is added. This is how the first getTables call gets triggered.
      https://github.com/opengeo/geoserver/blob/ec5e24578288c9eaf673fd72e766fa58c61fbb03/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L840 - https://github.com/opengeo/geoserver/blob/ec5e24578288c9eaf673fd72e766fa58c61fbb03/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L840

      Then further down, ResourcePool::getFeatureType is called. Note that false is passed for the second parameter, the handleProjectionPolicy.
      https://github.com/opengeo/geoserver/blob/ec5e24578288c9eaf673fd72e766fa58c61fbb03/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L849 - https://github.com/opengeo/geoserver/blob/ec5e24578288c9eaf673fd72e766fa58c61fbb03/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L849

      This method in turn is responsible for the next two calls. The implementation first checks if it is cacheable, which in this case it is not because false is passed in for handleProjectionPolicy. The code then leads to a call to generate the list of type names to find a unique virtual table name. This results in the 2nd getTables call.
      https://github.com/opengeo/geoserver/blob/ec5e24578288c9eaf673fd72e766fa58c61fbb03/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L626 - https://github.com/opengeo/geoserver/blob/ec5e24578288c9eaf673fd72e766fa58c61fbb03/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L626

      And finally, the virtual table is added right after, which leads to the 3rd getTables call.
      https://github.com/opengeo/geoserver/blob/ec5e24578288c9eaf673fd72e766fa58c61fbb03/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L632 - https://github.com/opengeo/geoserver/blob/ec5e24578288c9eaf673fd72e766fa58c61fbb03/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L632

      I would prefer if getTables wouldn't be called at all to generate the response. Can the type names be cached? I understand that means as a consequence geoserver will need to be restarted if a new table or view is added to the database, but maybe this could be handled as a configurable policy. And even if it was being cached, perhaps we could provide a way to invalidate it in a live geoserver environment. I'm certainly open to any ideas here.

      In case it helps, here are the relevant bits of the stack traces for the 3 cases.

      1.
      JDBCDataStore.createTypeNames() line: 842
      JDBCDataStore(ContentDataStore).entry(Name) line: 554
      JDBCDataStore(ContentDataStore).ensureEntry(Name) line: 585
      JDBCDataStore(ContentDataStore).getFeatureSource(Name, Transaction) line: 383
      JDBCDataStore(ContentDataStore).getFeatureSource(String) line: 350
      JDBCDataStore(ContentDataStore).getSchema(String) line: 335
      JDBCDataStore.addVirtualTable(VirtualTable) line: 284
      ResourcePool.getFeatureSource(FeatureTypeInfo, Hints) line: 840

      2.
      JDBCDataStore.createTypeNames() line: 842
      JDBCDataStore(ContentDataStore).getTypeNames() line: 299
      ResourcePool.getFeatureType(FeatureTypeInfo, boolean) line: 626
      ResourcePool.getFeatureSource(FeatureTypeInfo, Hints) line: 849

      3.
      JDBCDataStore.createTypeNames() line: 842
      JDBCDataStore(ContentDataStore).entry(Name) line: 554
      JDBCDataStore(ContentDataStore).ensureEntry(Name) line: 585
      JDBCDataStore(ContentDataStore).getFeatureSource(Name, Transaction) line: 383
      JDBCDataStore(ContentDataStore).getFeatureSource(String) line: 350
      JDBCDataStore(ContentDataStore).getSchema(String) line: 335
      JDBCDataStore.addVirtualTable(VirtualTable) line: 284
      ResourcePool.getFeatureType(FeatureTypeInfo, boolean) line: 632
      ResourcePool.getFeatureSource(FeatureTypeInfo, Hints) line: 849

        Attachments

          Activity

            People

            • Assignee:
              aaime Andrea Aime
              Reporter:
              harrison.grundy codehaus (Inactive)
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Stride room