Problem with replication sending

[Mobus]

I have a strange behaviour with replication tasks most of the time they work just fine but then once in a while they kind of seem stuck? So I have the following process output:
95862 - I 0:01.31 zfs: sending Storage/xxxx@auto-20170329.0900-5m (100%: 29184312/19970368) (zfs)
couple of minutes later:
97306 - I 0:01.31 zfs: sending Storage/xxxx@auto-20170329.0900-5m (100%: 29186736/19970368) (zfs)
I also get an alert via Mail saying:
Replication Storage/xxxx -> 192.168.0.15:Storage failed: Failed: Storage/xxxx (auto-20170328.1800-5m->auto-20170329.0900-5m)

The way I fixed it the last time was a manual:
zfs send -i Storage/xxxx@auto-20170314.1800-5m Storage/xxxx@auto-20170315.0900-5m | ssh -i /data/ssh/replication 192.168.0.15 zfs recv -vF Storage/xxxx

I first thought the data volume is too much to replicate in time but it wasn't the case as it is a 1Gbit internal Network and the manual copy was done in under a minute. So what is happening here? I have 4 replication tasks in total, the other three work fine, although the last time two tasks failed.

Can someone help me analyse this problem? Thanks in advance!

 

[dlavigne]

Which build versions (from System -> Information) are running on the receiving ends?

 

[Mobus]

Sending and receiving are on Version: FreeNAS-9.10.1-U2 (f045a8b).

 

[dlavigne]

Does checking the box to "delete stale snapshots on remote system" in the replication task unstick it?

 

[Mobus]

Yes it does, thanks dlavigne! How come? I would have guessed that it actually is a fail safe to start fresh if something goes wrong and not cause issues ;)

And what does happen now when there are stale snapshots? :) And why do the other two snapshots sync just fine with that option selected?

 

[dlavigne]

TBH, I'm not sure about the technical details on how things get stuck but that option usually unsticks it. Someone else might have a better technical explanation.