Subscription Transfer with KEP Server EX | OPC UA SDK for Java | Forum | Prosys ForumProsys Forum

Please consider registering
guest

Forum
OPC UA SDK for Java
Subscription Transfer with KEP Server EX

Topic RSS

Subscription Transfer with KEP Server EX

April 13, 2026
15:42, EEST

rocket science

Member

Members

Forum Posts: 123

Member Since:
March 16, 2017

Offline

Hi,

I had an issue where KEPServerEX crashed and after restart of KEP Server EX it seemed that only 1 out of 6 subscription did work.

Before the KEPServer crash I got onAlive for all 6 subscriptions and also onStatusChange messages:

2026-04-10 01:17:18,234 Subscription onAlive(): Subscription id=40 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:17:18,234 Subscription onAlive(): Subscription id=42 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:17:27,236 Subscription onAlive(): Subscription id=45 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:17:28,236 Subscription onAlive(): Subscription id=44 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:17:29,238 Subscription onAlive(): Subscription id=38 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:17:33,242 Subscription onAlive(): Subscription id=36 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0

2026-04-10 01:17:35,346 onStatusChange: status=ServerStatusDataType [StartTime=”04/08/26 10:34:23.0326081 GMT”, CurrentTime=”04/10/26 08:17:35.3377350 GMT”, State=”Running”, BuildInfo=”BuildInfo [ProductUri=”urn:XXX:Kepware.KEPServerEX.V6:UA%20Server”, ManufacturerName=”Kepware”, ProductName=”KEPServerEX”, SoftwareVersion=”6.17″, BuildNumber=”269″, BuildDate=”03/11/25 11:39:45.0000000 GMT”]”, SecondsTillShutdown=”0″, ShutdownReason=””] statusCode=GOOD (0x00000000) “The operation succeeded.”
2026-04-10 01:17:36,347 onStatusChange: status=ServerStatusDataType [StartTime=”04/08/26 10:34:23.0326081 GMT”, CurrentTime=”04/10/26 08:17:36.3388048 GMT”, State=”Running”, BuildInfo=”BuildInfo [ProductUri=”urn:XXX:Kepware.KEPServerEX.V6:UA%20Server”, ManufacturerName=”Kepware”, ProductName=”KEPServerEX”, SoftwareVersion=”6.17″, BuildNumber=”269″, BuildDate=”03/11/25 11:39:45.0000000 GMT”]”, SecondsTillShutdown=”0″, ShutdownReason=””] statusCode=GOOD (0x00000000) “The operation succeeded.”

Then the KEP Server crashed:

2026-04-10 01:17:48,349 onStatusChange: status=null statusCode=Bad_Timeout (0x800A0000) “The operation timed out.”

For the 6 subscriptions I’m seeing also the onTimeOut and onLifetimeTimeOut

2026-04-10 01:17:48,449 Subscription onTimeout(): Subscription id=40 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:17:48,449 Subscription onTimeout(): Subscription id=42 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:19:38,671 Subscription onTimeout(): Subscription id=36 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:19:38,671 Subscription onTimeout(): Subscription id=38 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:19:38,671 Subscription onTimeout(): Subscription id=44 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:19:38,671 Subscription onTimeout(): Subscription id=45 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0

2026-04-10 01:19:38,671 Subscription onLifetimeTimeout(): Subscription id=36 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:19:38,671 Subscription onLifetimeTimeout(): Subscription id=38 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:19:38,671 Subscription onLifetimeTimeout(): Subscription id=40 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:19:38,671 Subscription onLifetimeTimeout(): Subscription id=42 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:19:38,671 Subscription onLifetimeTimeout(): Subscription id=44 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:19:38,671 Subscription onLifetimeTimeout(): Subscription id=45 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0

When the server was back online (restarted); i can see that a subscription transfer happens:

In the log it shows the TransferSubscriptionsResponse with disconnectSubscriptions for 5 subscriptions GOOD and for 1 Bad

2026-04-10 02:08:35,238|SecureChannelTcp|DEBUG|Response: TransferSubscriptionsResponse
2026-04-10 02:08:35,238|UaClient|DEBUG|disconnectSubscriptions:
[TransferResult [StatusCode=”GOOD (0x00000000) “The operation succeeded.””, AvailableSequenceNumbers=”[]”],
TransferResult [StatusCode=”GOOD (0x00000000) “The operation succeeded.””, AvailableSequenceNumbers=”[]”],
TransferResult [StatusCode=”GOOD (0x00000000) “The operation succeeded.””, AvailableSequenceNumbers=”[]”],
TransferResult [StatusCode=”GOOD (0x00000000) “The operation succeeded.””, AvailableSequenceNumbers=”[]”],
TransferResult [StatusCode=”GOOD (0x00000000) “The operation succeeded.””, AvailableSequenceNumbers=”[]”],
TransferResult [StatusCode=”Bad_SubscriptionIdInvalid (0x80280000) “The subscription id is not valid.””, AvailableSequenceNumbers=”[]”]]

I see an onAfterCreate only for 1 subscription

2026-04-10 02:08:35,241 onAfterCreate(): Subscription id=45 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0

2026-04-10 02:08:35,241|UaClient|INFO |reconnect: Reconnected to server (new session)

From that point on, I’m getting only onAlive() for this subscription but not of the other 5

2026-04-10 02:08:36,233 onAlive(): Subscription id=45 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0

I’m also not getting onDataChanges for the 5 subscription, but only the one for id=45

Instead I can see a lot of this loggings:

I’m also logging the subscription isConnected() and isAlive() periodically and it seems that both are true (even it seems that I do no more get onDataChanges)

02:12:52,359 Subscription id=36 isConnected(true), isAlive(true)
02:12:52,359 Subscription id=38 isConnected(true), isAlive(true)
02:12:52,359 Subscription id=40 isConnected(true), isAlive(true)
02:12:52,359 Subscription id=42 isConnected(true), isAlive(true)
02:12:52,359 Subscription id=44 isConnected(true), isAlive(true)
02:12:52,359 Subscription id=45 isConnected(true), isAlive(true)

Could it be possible that KEPServerEX has some problem here with subscription transfer?

Based on the logging during ‘transferSubscriptions’ for me it looked like that 5 subscription could be transferred and one of them could not. The one that could not gets recreated but unfortunatly this was the only one for which I’m getting onDataChanges. Somehow for the other 5 it seems that the server did somehow not handled the transfer correctly

What do you think about that?

April 13, 2026
17:04, EEST

Bjarne Boström

Moderator

Moderators

Forum Posts: 1092

Member Since:
April 3, 2012

Offline

Hi,

Most likely you would need to contact the server vendor. But to theoretize something…

Are you absolutely sure that the server did crash?

For the one Subscription that did fail the TransferSubscription, the id was 45. This is a server-given id. The “createSubscription: subscription=” lines show other numbers than 45. A failed TransferSubscription does reset the number in our client side i.e. it becomes 0; which is otherwise invalid id, this is seen in the createSubscription. However, then the CreateSubscrpitionResponse shows that the server created Subscription with id 45. Now depending how the server chooses them (they need to be unique for the server), it is possible by luck it was 45. Or if other clients (if any) also connected it might not have been the initial one. Or in theory might be some weird result of TransferSubscription using that id (it would have been e.g. the highest)??

Does more than one client connect to the server? Do you (+they) use Anonymous user access?
– Asking because most ids are +2, but 45 was 44+1, typically these are +1 for the previous one.

There are some oddities. If the server crashed, it would be extremely unlikely that it would have any knowledge of Subscriptions prior to the crash, though not impossible (but I’m not aware of such implementation; plus the UA Spec Durable Subscriptions would need to be enabled by the client, which we do not do). So, any TransferSubscriptions call should thus fail.

Now then, IF other clients would be connecting to the same server, then there are some scenarios where depending on the implementation and other stuff it might be possible to Transfersubscription another clients Subscription, which in this case would be something they just have made. Though this should only happen for Anonymous Sessions, if for any.

The timeout and lifetimeout do depend on delta to Subscription.getLastAlive() (vs. publishinterval and respective keepalive/lifetime), which is updated if anything is done, e.g. server sends keepalive or data for the Subscription (or if data is received that indicates an update was missed and is being RePublished).

Note that UaClient will keep sending PublishRequests as long as it has Subscription.isAlive() subscriptions and PublishRequests are not keyed to any subscription.

Does the “Server sent a previously acknowledged sequence number” numbers keep rising or stay 1? Though you showed one line that has also 2 for id 36.

Maybe the TransferSubscriptions somehow resulted in the server making some subscription objects that do nothing, but send keepalives. Or maybe they do send data, but they started as-if they were new ones, so the sequence number is wrong (and thus you see those logs for very long while until they catch up the number the server send prev to the crash).

April 13, 2026
22:22, EEST

rocket science

Member

Members

Forum Posts: 123

Member Since:
March 16, 2017

Offline

Bjarne Boström said
Are you absolutely sure that the server did crash?

Not 100% sure. I just assumed this from the logs because of:

2026-04-10 01:17:48,349 onStatusChange: status=null statusCode=Bad_Timeout (0x800A0000) “The operation timed out.”

and the fact that read operations did no more work beginning at this time.

So I assumed the server was restartet at ~ 02:08 when the client got connection again – but I have to re-check if this was the case or the server was basically still running somehow.

Bjarne Boström said
CreateSubscrpitionResponse shows that the server created Subscription with id 45. Now depending how the server chooses them (they need to be unique for the server), it is possible by luck it was 45.
Or if other clients (if any) also connected it might not have been the initial one. Or in theory might be some weird result of TransferSubscription using that id (it would have been e.g. the highest)??

Yeah, this is somehow strange.

Bjarne Boström said
Does more than one client connect to the server? Do you (+they) use Anonymous user access?
– Asking because most ids are +2, but 45 was 44+1, typically these are +1 for the previous one.

Yes, there are 2 clients connected to this server. The other client has also 6 subscription and had basically the same problem at the same time (but I have to check the logs for the other in detail)
Both clients use Anonymous access.

Bjarne Boström said
There are some oddities. If the server crashed, it would be extremely unlikely that it would have any knowledge of Subscriptions prior to the crash, though not impossible
(but I’m not aware of such implementation; plus the UA Spec Durable Subscriptions would need to be enabled by the client, which we do not do). So, any TransferSubscriptions call should thus fail.

Now then, IF other clients would be connecting to the same server, then there are some scenarios where depending on the implementation and other stuff it might be possible
to Transfersubscription another clients Subscription, which in this case would be something they just have made. Though this should only happen for Anonymous Sessions, if for any.

The timeout and lifetimeout do depend on delta to Subscription.getLastAlive() (vs. publishinterval and respective keepalive/lifetime), which is updated if anything is done, e.g.
server sends keepalive or data for the Subscription (or if data is received that indicates an update was missed and is being RePublished).

Note that UaClient will keep sending PublishRequests as long as it has Subscription.isAlive() subscriptions and PublishRequests are not keyed to any subscription.

You’re right, if the server would have crashed completly it would have started by SuscriptionId 1 (at least I would have expected this)

I will check tomorrow what happened to the other client at the same time, and take a look at the SubscriptionId’s there.

Bjarne Boström said
Does the “Server sent a previously acknowledged sequence number” numbers keep rising or stay 1? Though you showed one line that has also 2 for id 36.

Maybe the TransferSubscriptions somehow resulted in the server making some subscription objects that do nothing, but send keepalives. Or maybe they do send data,
but they started as-if they were new ones, so the sequence number is wrong (and thus you see those logs for very long while until they catch up the number the server send prev to the crash).

Yes, thats also somehow weird here, some numbers are increasing from time to time, but some stay on 2.
E.g. Subscription 36 stays on 2
and Subscription 38 stays on 97 some time but increases later to 98 followed to increase to 99

Here are some logs a few hours later:

April 14, 2026
11:18, EEST

Bjarne Boström

Moderator

Moderators

Forum Posts: 1092

Member Since:
April 3, 2012

Offline

Just as a guess, maybe instead there was some network problem and then the TransferSubscriptions caused the Subscriptions to somehow incorrectly reset their sequence numbers. Though, given PublishInterval of 1000 and LifetimeCount of 60 (even revised values, based on the createSubscription prev log), the server should have long ago already deleted the Subscription (basically after a minute of inactivity by the client not being there sending PublishRequests to be used for KeepAlives to reset the lifetime timer). So, this wouldn’t make sense either.

Since you see the sequence numbers sometimes growing, it would indicate the server is trying to send data, which is then ignored by the SDK since the sequence numbers are wrong (and are not in the “flip range”, i.e. past halfway point to UInt32 max). Though, I think the only way to see the data would be via Wireshark or some overriding tricks for the client-side Subscriptions. If the server would be just sending KeepAlives (i.e. no datachanges), it would reuse the same sequence number until there is data (basically it is the one that would be used the next time there is data).

In the past it was typical that the SubscriptionIds started from 1. Though nowadays the spec https://reference.opcfoundatio…..ocs/5.14.2 does say (at the SubscriptionId return) “After Server start-up the generation of subscriptionIds should start from a random IntegerId or continue from the point before the restart.”. Current versions of our server side SDK does by default use a starting value that is based on current time.

If there is just one other client with also 6 subs, it wouldn’t give ids in 40s, if it starts from 1. Though hard to say without knowing the server logic.

I think that is as much as I can guess about this.

April 14, 2026
11:59, EEST

rocket science

Member

Members

Forum Posts: 123

Member Since:
March 16, 2017

Offline

Thank you for your detailed informations so far.

I the meantime I check the other client. It had subscriptionId’s 28,29,30,31,32,33

2026-04-10 01:17:01,237 Subscription onAlive(): Subscription id=30 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:17:04,241 Subscription onAlive(): Subscription id=29 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:17:14,240 Subscription onAlive(): Subscription id=33 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:17:15,235 Subscription onAlive(): Subscription id=31 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:17:15,235 Subscription onAlive(): Subscription id=32 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0
2026-04-10 01:17:20,343 Subscription onAlive(): Subscription id=28 PublishingInterval=1000.0 isPublishingEnabled=true priority=0 lifetimeCount=60 maxKeepAliveCount=20 maxNotificationsPerPublish=0

I forgot that I have 3 clients, not 2 (the third is running on another server thats why I forgot about it) – that could explain why I had SubscriptionIds like 38, 40, 42, 44, 45 for the other client

April 14, 2026
17:27, EEST

rocket science

Member

Members

Forum Posts: 123

Member Since:
March 16, 2017

Offline

Btw. is there a way to deactivate the subscription transfer on reconnect? (so I can recreate the subscription newly after a reconnect?)

Why I’m asking this is, that it seems the KEPServerEX has several problems which the transfer.

On the KEP-Server page I found following fix for a newer version, but I’m not sure if it fixes that exactly problem. (I’ll have to see when I can update the KEPServer to a newer version)

https://support.ptc.com/help/k…..96_0.html#
>> Fixed an issue that could result in communication errors; including read and write timeouts, session and subscription timeouts, and disconnections when the system is under heavy communication load.

At least I have seen communication errors, read timeouts and subscription timeouts in my logs.

What I also observerd is that all my 3 clients got disconnected with

TcpConnection|INFO |XXXXXXX/YYY.YYY.YYY.YYY:ZZZZZ Closed (unexpected)

at the same time.

At client 1, the transfer subscription showed

UaClient|DEBUG|disconnectSubscriptions:
[TransferResult [StatusCode=”Bad_SubscriptionIdInvalid (0x80280000) “The subscription id is not valid.””, AvailableSequenceNumbers=”[]”],
TransferResult [StatusCode=”Bad_SubscriptionIdInvalid (0x80280000) “The subscription id is not valid.””, AvailableSequenceNumbers=”[]”],
TransferResult [StatusCode=”Bad_SubscriptionIdInvalid (0x80280000) “The subscription id is not valid.””, AvailableSequenceNumbers=”[]”],
TransferResult [StatusCode=”Bad_SubscriptionIdInvalid (0x80280000) “The subscription id is not valid.””, AvailableSequenceNumbers=”[]”],
TransferResult [StatusCode=”Bad_SubscriptionIdInvalid (0x80280000) “The subscription id is not valid.””, AvailableSequenceNumbers=”[]”],
TransferResult [StatusCode=”Bad_SubscriptionIdInvalid (0x80280000) “The subscription id is not valid.””, AvailableSequenceNumbers=”[]”]]

so all subscriptions got created newly and they got SubscriptionIds 1,2,3,4,5,6

At Client 2 and Client 3 the TransferResult was reported Good at least for 5 out of the 6 subscription, so only 1 got created newly which had a higher id like e.g. 46. – This was then the only one working at Client 2 and Client 3.

For the subscriptions where the KEPServer reported Good at Client 2 and 3 there are this logs:

Subscription|WARN |Server sent a previously acknowledged sequence number 2 for Subscription 40
Subscription|WARN |Server sent a previously acknowledged sequence number 2 for Subscription 42

That leads me to the assumption that the KEPServer has here some problem with the subscription transfer:

I also asked ChatGPT about known problems with KEPServer (Version 6) and subscription transfer after connection loss and the result matches also somehow my assumption:

ChatGPT answer:

1) TransferSubscriptions is “accepted” but not actually working
Typical pattern with Kepware:
Client reconnects ✅
TransferSubscriptions call returns success ✅
Subscription IDs still valid ✅
BUT no Publish notifications arrive ❌
👉 This is the exact “ghost subscription” problem.

KEPServerEX is known (in multiple versions) to:
not fully restore the publishing pipeline after transfer
especially after:
session timeout
network interruption
or internal cleanup

KEPServerEX 6 does not guarantee subscription transfer across sessions
Even when it “should” work, there are:
known bugs
edge cases
configuration pitfalls
The robust approach is always:
🔁 reconnect → recreate subscriptions → re-add monitored items

April 15, 2026
10:15, EEST

Bjarne Boström

Moderator

Moderators

Forum Posts: 1092

Member Since:
April 3, 2012

Offline

Complex situation.

There are no intended ways to disable the TransferSubscriptions. Technically it can only attempt the Subscriptions that are in the UaClient. So, a first idea might be to remove them from it when ServerStatusListener goes to non-Running state and then add them back in once it returns to Running. Though, that would lead to possibly other problematic situations. A reconnect can possibly manage to re-ActivateSession the old Session if the server does not restart and the connection break is small enough. So, the Subscriptions might still be alive there and effectively now you would have double Subscriptions and it is hard to remove the old ones and they wont get deleted automatically (they are in the same Session and PublishRequests are not keyed to any particual Subscription).

Instead maybe if you wait for the connection to come back, and only after that remove the Subscriptions and then immediately add them back in it should avoid the double Subscriptions case at least. This assumes the server will actually delete the “ghost subscriptions”.

April 15, 2026
10:40, EEST

rocket science

Member

Members

Forum Posts: 123

Member Since:
March 16, 2017

Offline

Thanks for your thoughts.

I will first update the KEPServer to a newer version and monitor the situation if this might have already a solution.

If not, I will think about the second suggestions to delete the subscriptions after a successful reconnect and re-add them newly.

All RSS

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 1919

Currently Online:

Guest(s) 58

Currently Browsing this Page:
1 Guest(s)