# Wrapper Log: Subscription transfer failed **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [March 22, 2023, 6:46pm UTC](https://forum.inductiveautomation.com/t/wrapper-log-subscription-transfer-failed/71456 "2023-03-22T18:46:57Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![peter](https://avatars.discourse-cdn.com/v4/letter/p/278dde/32.png) [@peter](https://forum.inductiveautomation.com/u/peter)\ **Post date:** [March 22, 2023, 6:46pm UTC](https://forum.inductiveautomation.com/t/wrapper-log-subscription-transfer-failed/71456/1 "2023-03-22T18:46:57Z")
This is for Ignition 8.1.2 I am seeing a lot of entries in my wrapper log file of > INFO | jvm 1 | 2023/03/18 00:47:00 | I [c.i.i.g.o.c.c.OpcUaConnection] [04:46:59]: Subscription transfer failed, id=2426678631, status=StatusCode{name=Bad\_UserAccessDenied, value=0x801F0000, quality=bad} connection-name=ASC06LS As well as things like > INFO | jvm 1 | 2023/03/18 00:47:00 | I [c.i.i.g.o.c.c.OpcUaSubscriptionModel] [04:47:00]: ResendData for subscriptionId=2 failed: StatusCode{name=Bad\_MethodInvalid, value=0x80750000, quality=bad} connection-name=ASC33LS What do these sorts of entries imply? I tried searching for an explanation but I seemed to have failed at that. I suspect that something bad is happening, but I'd to narrow down where I should be looking. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [March 22, 2023, 8:25pm UTC](https://forum.inductiveautomation.com/t/wrapper-log-subscription-transfer-failed/71456/2 "2023-03-22T20:25:37Z")
These are separate failures. The first is happening after a reconnect when we try to transfer the old subscriptions to the new session. The server is rejecting the request with `Bad_UserAccessDenied`... not uncommon if you are connected anonymously, and if you _have_ configured credentials then it's up to the server if it's allowed. This is ultimately fine because we just create a new subscription if the transfer fails. It's not uncommon for this to fail as many servers don't support it or can't complete the transfer because the connection was lost while it was restarted or something. The other message means at some point the server delivered notifications with a gap in the sequence number, we tried to recover them using the Republish mechanism, that failed, we then called the ResendData method to get current values for all MonitoredItems, and that also failed, because it looks like this server may not support it. ---
**Author:** ![peter](https://avatars.discourse-cdn.com/v4/letter/p/278dde/32.png) [@peter](https://forum.inductiveautomation.com/u/peter)\ **Post date:** [March 22, 2023, 9:39pm UTC](https://forum.inductiveautomation.com/t/wrapper-log-subscription-transfer-failed/71456/3 "2023-03-22T21:39:35Z")
OK .. all of these connections are to Rx3i PLCs with no credentials and implicit trust of the out of date certificates installed on them 🙄 In both cases would it be fair to say that one possible reason could be network issues? I'm not sure if this entry also plays into that, or if it is another issue altogether: > INFO | jvm 1 | 2023/03/18 04:04:34 | E [o.e.m.o.s.c.t.u.UascClientMessageHandler] [08:04:34]: [remote=/172.25.9.20:4840] Exception caught: An existing connection was forcibly closed by the remote host > INFO | jvm 1 | 2023/03/18 04:04:34 | java.io.IOException: An existing connection was forcibly closed by the remote host ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [March 22, 2023, 9:40pm UTC](https://forum.inductiveautomation.com/t/wrapper-log-subscription-transfer-failed/71456/4 "2023-03-22T21:40:47Z")
Could be a network issue, could be that someone did a program or configuration change or "download" to the PLC and that causes the server to restart. ---
**Author:** ![peter](https://avatars.discourse-cdn.com/v4/letter/p/278dde/32.png) [@peter](https://forum.inductiveautomation.com/u/peter)\ **Post date:** [March 22, 2023, 9:43pm UTC](https://forum.inductiveautomation.com/t/wrapper-log-subscription-transfer-failed/71456/5 "2023-03-22T21:43:09Z")
That is also entirely possible. As I shouldn't see continual downloads, so I'm going to have to do some log analysis to see if I can figure out a pattern. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [March 22, 2023, 9:43pm UTC](https://forum.inductiveautomation.com/t/wrapper-log-subscription-transfer-failed/71456/6 "2023-03-22T21:43:45Z")
If the connections are unsecured, or can be modified to be unsecured, then a long running Wireshark capture to go along with the logs may help. ---
**Author:** ![peter](https://avatars.discourse-cdn.com/v4/letter/p/278dde/32.png) [@peter](https://forum.inductiveautomation.com/u/peter)\ **Post date:** [March 22, 2023, 9:45pm UTC](https://forum.inductiveautomation.com/t/wrapper-log-subscription-transfer-failed/71456/7 "2023-03-22T21:45:37Z")
Yeah, but my Wireshark cable won't stretch to China 🤣 But that is something to keep in mind for when a FE is on site.