# Data Gap Recovery issues **URL:** \ **Category:** GPA Products\ **Created:** [February 15, 2019, 3:30am UTC](http://discussions.gridprotectionalliance.org/t/data-gap-recovery-issues/459 "2019-02-15T03:30:36Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![jeffhill](http://discussions.gridprotectionalliance.org/letter_avatar_proxy/v4/letter/j/ebca7d/32.png) [@jeffhill](http://discussions.gridprotectionalliance.org/u/jeffhill)\ **Post date:** [February 15, 2019, 3:30am UTC](http://discussions.gridprotectionalliance.org/t/data-gap-recovery-issues/459/1 "2019-02-15T03:30:36Z")
I have managed to get the Data Gap Recovery working between 2 SIEGate’s using Authorized subscription. As per the demonstration video on YouTube, if I pull the network cable on one of the boxes to simulate a loss of connection, this feature works fine. However, if I pull the cable for 5 minutes simulating a lengthier network dropout, I get this … it happens every time, and no data is recovered. ``` [2/15/2019 1:12:10 PM] [151.142.SG] [DataGapRecoverer] Starting data gap recovery for period "2019-02-15 03:10:38.462" - "2019-02-15 03:11:40.534"... [2/15/2019 1:12:10 PM] [151.142.SG] [DataGapRecoverer] Success code received in response to server command "Subscribe": Client subscribed as compact unsynchronized with a temporal constraint. [2/15/2019 1:12:14 PM] [151.142.SG] [DataGapRecoverer] TSSC algorithm reset before sequence number: 1249 [2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:73 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration. [2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:74 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration. [2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:75 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration. [2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:76 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration. [2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:77 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration. [2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:78 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration. [2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:79 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration. [2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:80 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration. [2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:81 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration. [2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:82 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration. [2/15/2019 1:12:19 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:83 @2019-02-15 03:10:40.7330000. Data received out of order will not be archived, per configuration. [2/15/2019 1:12:20 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:71 @2019-02-15 03:10:40.7660000. Data received out of order will not be archived, per configuration. [2/15/2019 1:12:20 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:70 @2019-02-15 03:10:41.0000000. Data received out of order will not be archived, per configuration. [2/15/2019 1:12:20 PM] [PPA] WARNING: Received 8100 points of out-of-sequence data for ppa:72 @2019-02-15 03:10:41.0000000. Data received out of order will not be archived, per configuration. ``` Any thoughts on how to correct this? ---
**Author:** ![ritchiecarroll](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/ritchiecarroll/32/2_2.png) [@ritchiecarroll](http://discussions.gridprotectionalliance.org/u/ritchiecarroll)\ **Post date:** [February 15, 2019, 2:47pm UTC](http://discussions.gridprotectionalliance.org/t/data-gap-recovery-issues/459/2 "2019-02-15T14:47:48Z")
My suggestion would be to use the openHistorian 2.0 instead of the 1.0 local historian - is this a possiblity for your deployment? ---
**Author:** ![jeffhill](http://discussions.gridprotectionalliance.org/letter_avatar_proxy/v4/letter/j/ebca7d/32.png) [@jeffhill](http://discussions.gridprotectionalliance.org/u/jeffhill)\ **Post date:** [February 17, 2019, 11:04pm UTC](http://discussions.gridprotectionalliance.org/t/data-gap-recovery-issues/459/3 "2019-02-17T23:04:01Z")
> [@jeffhill](#): > > a What method would I use to be able to use the OpenHistorian 2.0 whilst still retaining SIEGate? I tried a local subscription of a local OpenHistorian to a local SIEGate using Data Gap Recovery, but I guess that won’t work since the SIEGate it’s subscribing to is not the source of the unrecovered data. I have also tried OpenHistorian to OpenHistorian over the network using TLS but I can’t get that to work without giving errors (See previous post). ---
**Author:** ![ritchiecarroll](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/ritchiecarroll/32/2_2.png) [@ritchiecarroll](http://discussions.gridprotectionalliance.org/u/ritchiecarroll)\ **Post date:** [February 18, 2019, 4:46pm UTC](http://discussions.gridprotectionalliance.org/t/data-gap-recovery-issues/459/4 "2019-02-18T16:46:13Z")
Actually, I would expect either method would work. The simple case, for example, is simply that a locally installed openHistorian would subsribe to SIEGate for its data. SIEGate would be in control of data gap recovery - however, like you say, this would not account for cases where the openHistorian might be down - just gaps as detected by SIEGate. In the case of openHistorian to openHistorian (bypassing SIEGate), this is also possible, just more tricky to get going… ---
**Author:** ![jeffhill](http://discussions.gridprotectionalliance.org/letter_avatar_proxy/v4/letter/j/ebca7d/32.png) [@jeffhill](http://discussions.gridprotectionalliance.org/u/jeffhill)\ **Post date:** [February 18, 2019, 10:25pm UTC](http://discussions.gridprotectionalliance.org/t/data-gap-recovery-issues/459/5 "2019-02-18T22:25:16Z")
Hi Ritchie I got it working by following this post I found that you had made [https://github.com/GridProtectionAlliance/openHistorian/wiki/Migrating-to-openHistorian-2.0-in-other-GPA-Products](https://github.com/GridProtectionAlliance/openHistorian/wiki/Migrating-to-openHistorian-2.0-in-other-GPA-Products) and it works great, I simulated a 15 min downtime between the 2 SIEGate over the network and all was recovered, and successfully passed on to the OpenHistorian then on to Grafana. Only caveat is that SIEGate doesnt support the OpenHistorian 2 input type, so I can’t modify the custom input for PPAReader. All that means is I can’t view History in SIEGate? which probably won’t be an issue since the data is getting passed to OpenHistorian anyway. ---
**Author:** ![ritchiecarroll](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/ritchiecarroll/32/2_2.png) [@ritchiecarroll](http://discussions.gridprotectionalliance.org/u/ritchiecarroll)\ **Post date:** [February 19, 2019, 4:30pm UTC](http://discussions.gridprotectionalliance.org/t/data-gap-recovery-issues/459/6 "2019-02-19T16:30:36Z")
Right - in this mode SIEGate is just being used as pass-through to openHistorian