Hexagon Geospatial
MENU

GMSC Q&A

GeoMedia Smart Client provides tools for building and delivering highly-constrained, map-based workflows for the office or the field.
Showing results for 
Search instead for 
Do you mean 

TileService recovery scenarios

by Technical Evangelist on ‎01-14-2019 04:02 AM - edited on ‎05-28-2019 09:08 AM by sclow (296 Views)

Question

What happens when there appears a database or connectivity outage during TileService publishing job? Will it recover?

Answer

The TileService behavior has improved since GeoMedia SmartClient 2018 Update 4 and later releases. The service will now appropriately handle following scenarios.

TileService shutdown

Event example - regular service shut down of the TileService via services.msc

Publish Order, Publish Jobs

  • Queued publish orders which are already assigned to the shutting down TileService (see table RPI_PUBLISHORDERQUEUE), will be released after the corresponding TileService restart.
  • Running publish orders will be stopped and the publish state will be changed to ERROR.

WMTS Publish Order

  • Queued & Running WMTS publish order will be stopped and their publish state will be changed to ERROR.

Database outage

Event example - database is shut down or TileService lost connectivity

Publish Order, Publish Jobs

  • Running & queued publish orders which are already assigned to a TileService are tried to work off. If the database can't be reached while a tile will be processed, then this tile will be skipped but the order is still running. Queued orders will be started if the database is back.

WMTS Publish Order

  • Queued order cannot be retrieved from the database and therefore they will be started if the database is available again.
  • Running orders which are already assigned to a TileService are tried to work off. In both cases endless retries are implemented which means that the TileService always retry to publish the same tile as long as it gets a database error.

Please note that the difference between a common publish order and a WMTS publish order is work as designed. A WMTS publish order can take several days or weeks and that's the reason why we want to ensure that a database outage doesn't need a restart of the complete WMTS publish order.

TileService outage caused by a hardware failure or power failure

Event example - an unexpected stop of the TileService e.g. by "killing" the process or server powered off unexpectedly 

Publish Order, Publish Jobs

  • Running or queued publish order which was already assigned to the failed TileService (see table RPI_PUBLISHORDERQUEUE), will be released after the corresponding TileService restart. The difference to a regular shutdown is, that the publish state of a running job will be set to ERROR after the restart.

WMTS Publish Order

  • Running and queued order keeps their status which must be solved manually by deleting the order from the database.
Comments
by
on ‎01-15-2019 01:36 PM

In regard to "Running & queued publish orders which are already assigned to a TileService are tried to work off. If the database can't be reached while a tile will be processed, then this tile will be skipped but the order is still running. Queued orders will be started if the database is back."

Does that mean that in production environment there will be missing contentfor the skipped tile(s)? Will the tiles be marked as failed so we can detect and generate those missed tiles?

by Technical Evangelist
on ‎01-16-2019 04:43 AM

Hi Shaun,

the tile states (RPI_FEATURETILE) will be updated as soon as the layer of a publish order has been completed.

 

Therefore the following scenarios could happen:

  • TileService wasn't able to publish some tiles and can't complete the layer because of a database outage
    Result:
    • The complete PublishOrder will be finished with FinishedWithErrors.
    • TileService is not able to update/change the table RPI_FEATURETILE.
  • TileService wasn't able to publish some tiles because of a database outage but it is able to complete the layer.
    Result:
    • TileService is able to update/change the table RPI_FEATURETILE and the state of the skipped tiles will be ERROR.
    • The complete PublishOrder will be finished with FinishedWithErrors.
  • TileService completes a PublishOrder but can't update the PublishOrder state because of a database outage
    Result:
    •  RPI_PUBLISHORDERQUEUE table will be cleand up and the PublishOrder state will be set to ERROR if the database is online again.

 

Best Regards,

Steve

by
on ‎01-16-2019 11:08 AM

"RPI_FEATURETILE and the state of the skipped tiles will be ERROR"

So that means that the skipped tiles will be in error state and therefore won't display in GMSC or public maps? Therefore end user won't see all the data - even worse surrounding data (tiles) will be in place so it will look to the end user like there is actually no data when there should be. Sounds very dangerous - in particular for 24x7 call centre.

Contributors