Prosys Forum - Forum: OPC UA SDK for Java

rocket science on Subscription Transfer with KEP Server EX

Wed, 15 Apr 2026 13:40:10 +0300

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.

Bjarne Boström on Subscription Transfer with KEP Server EX

Wed, 15 Apr 2026 13:15:12 +0300

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".

rocket science on Subscription Transfer with KEP Server EX

Tue, 14 Apr 2026 20:27:59 +0300

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

rocket science on Subscription Transfer with KEP Server EX

Tue, 14 Apr 2026 14:59:27 +0300

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

Bjarne Boström on Subscription Transfer with KEP Server EX

Tue, 14 Apr 2026 14:18:26 +0300

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.

rocket science on Subscription Transfer with KEP Server EX

Tue, 14 Apr 2026 01:22:05 +0300

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:

Bjarne Boström on Bad_DecodingError (0x80070000) "Decoding halted because of invalid data in the stream."

Mon, 13 Apr 2026 20:38:02 +0300

First a note that this topic is somewhat complicated. Also, this answer is based on the 5.x. Though, it is mostly the same in 4.x.

When dealing with Structures for which you do not know the exact type in code, it is best to treat them as the raw 'Structure' interface. It does have methods for getting and setting fields in a generic way, see https://documentation.prosysop.....cture.html. Alternatively for known types for which you do have an information model NodeSet XML file, you could use the included Codegen tool to create java classes that represent the Structures.

The SDK has special metadata classes StructureSpecification and FieldSpecification that model the Structure types that they can be handled in a generic way. Nowadays, you could mostly think them as "better versions" of StructureDefinition and FieldDefinition from the DataTypeDefinition Attribute, though StructureSpecification and FieldSpecification do pre-date them. Basically they were first used with what we now call legacy DataTypeDictionaries (the server has a node that has a big XML document). Now depending what the server supports we either use the DataTypeDefinition Attribute or the legacy dictionaries (or both), but the "SDK user API" is still the same with StructureSpecification and FieldSpecification regardless of which one was used.

See
https://documentation.prosysop.....ation.html
https://documentation.prosysop.....ation.html
you can use com.prosysopc.ua.stack.builtintypes.Structure.specification() to get the StructureSpecification and then getFields on that to get FieldSpecification, one per each field, these tell e.g. the field name and datatype which helps when using e.g. com.prosysopc.ua.stack.builtintypes.Structure.set(String, Object).

If you do not have any Structure instance to .specification(), you can use com.prosysopc.ua.client.UaClient.getEncoderContext()+ com.prosysopc.ua.stack.encoding.EncoderContext.getStructureSpecification(UaNodeId) to get the StructureSpecification of that type, then com.prosysopc.ua.typedictionary.StructureSpecification.toInstanceBuilder() will give a Structure.Builder that can be used to build the Structure instances of that type.

In 5.x the concept was generalized in a way all datatypes, in 4.x it is mostly just Structures and Enumerations (https://downloads.prosysopc.co.....sion-5-0-0)

We should probably improve the documentation at some point, maybe the best existing example is in the SampleConsoleServer example com.prosysopc.ua.samples.server.MyNodeManager.createCustomStructure(), https://documentation.prosysop.....l#line.415. Though start around https://documentation.prosysop.....l#line.467 as the start of the method is creating the type itself.

Bjarne Boström on Subscription Transfer with KEP Server EX

Mon, 13 Apr 2026 20:04:18 +0300

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).

devaskim on Bad_DecodingError (0x80070000) "Decoding halted because of invalid data in the stream."

Mon, 13 Apr 2026 19:48:57 +0300

Many thanks, Bjarne!
After fixing definition the issue is gone and data is deserialized to DynamicStructure object.
Last question: is there any example how to deal with such objects in Java?

Bjarne Boström on Bad_DecodingError (0x80070000) "Decoding halted because of invalid data in the stream."

Mon, 13 Apr 2026 19:20:20 +0300

That does explain. The ValueRanks are incorrect, they should be -1, not 0. See https://reference.opcfoundatio...../docs/8.51 "ValueRank Int32 The value rank for the field. It shall be Scalar (-1) or a fixed rank Array (>=1).". In OPC UA the ValueRank is a bit ... compliacted, but it is the number of dimensions when 1+, but 0 and some negative numbers have special meaning, see Variable NodeClass as an Attribute, see https://reference.opcfoundatio.....5/docs/5.6. However, Structures need fixed number of things (so scalar or fixed known dimension), at least so far.

So, basically our parser will ignore this DataType as the definition is incorrect, thus later decodings will also fail. If you can correct this on the server or ask the maintainers of it to correct it should start to work. Possibly UaExpert has done the check in a way that incorrectly allows 0 to work (such as scalar).

devaskim on Bad_DecodingError (0x80070000) "Decoding halted because of invalid data in the stream."

Mon, 13 Apr 2026 18:49:07 +0300

Here is output of our DataType using Prosys OPC UA Browser

DataTypeDefinition StructureDefinition [DefaultEncodingId="ns=1;i=1004", BaseDataType="i=22", StructureType="Structure", Fields="[
StructureField [Name="Max", Description="", DataType="i=5", ValueRank="0", ArrayDimensions="[]", MaxStringLength="0", IsOptional="false"],
StructureField [Name="Min", Description="", DataType="i=5", ValueRank="0", ArrayDimensions="[]", MaxStringLength="0", IsOptional="false"],
StructureField [Name="Status", Description="", DataType="i=5", ValueRank="0", ArrayDimensions="[]", MaxStringLength="0", IsOptional="false"]]"]

Bad_AttributeIdInvalid error are only in RolePermissions, UserRolePermissions and AccessRestrictions attributes.

rocket science on Connect to server with security mode NONE and user/password

Mon, 13 Apr 2026 18:44:27 +0300

I understand. Thank you for that detailed explanation!

rocket science on Subscription Transfer with KEP Server EX

Mon, 13 Apr 2026 18:42:37 +0300

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?