Re: [milo-dev] deleteSubscriptions() at onSubscriptionTransferFailed()

[Shigeru Ishida <ishida_shigeru@xxxxxxxxxxx>]

I do not add extra processing to onSubscriptionTransferFailed(),
and I am running this server continuously with only Apache Felix
removed.

As a result, the time interval during which Full GC ran, has
changed as follows. OOME has not yet appeared.

[1] about 8 hours
[2] about 16 hours
[3] about 22 hours
[4] about 2 hours
[5] about 30 minutes

>From [5] onwards, the occurrence of Full GC continues at approximately
30 minutes intervals. When operating on Felix, OOME occurred at the
timing of the first [5].

By the way, the version of Felix I am using is 4.6.1 in March 2015.
Looking at MANIFEST.MF, it was built with Java8.

Because of this circumstance, there is no need to run this server
on OSGi, so if OOME does not occur as it is, I think whether
this configuration is OK. (Although it is not an essential solution)

However, on the client side, OSGi is considered as an execution
environment of application bundles such as OPC-UA and BLE.

<kevinherron@xxxxxxxxx> wrote, Wed, 27 Dec 2017 08:25:05 -0800

> Sounds like you're on the right track...
> 
> > These clients handle the above but Bad_Timeout was thrown at
> createMonitoredItems().
> > In this case, I think that the server succeeded 1), probably also
> succeeded 2).
> > (Response only timed out)
> 
> I'd look into this part. It sounds like you're in control of both client
> and server in this case.
> 
> Creating monitored items shouldn't take long unless your implementation on
> the server is doing something blocking in every call to
> onDataItemsCreated() or, more likely, is throwing some kind of error and
> the response is never sent.
> 
> 
> 
> On Wed, Dec 27, 2017 at 2:20 AM, Shigeru Ishida <ishida_shigeru@xxxxxxxxxxx>
> wrote:
> 
> > I will attach a part of the analysis result of HeapDump of OOME
> > which occurred in about 65 hours. According to this, MonitoredItemData
> > seems to occupy most of Heap.
> >
> > In these clients, onSubscriptionTransferFailed(), when receiving
> > Bad_SubscriptionIdInvalid,
> >
> > 1) createSubscription()
> > 2) createMonitoredItems()
> >
> > These clients handle the above but Bad_Timeout was thrown at
> > createMonitoredItems().
> > In this case, I think that the server succeeded 1), probably also
> > succeeded 2).
> > (Response only timed out)
> >
> > After that, onSubscriptionTransferFailed() continues to be received
> > in a short time, similar processing runs and similarly receives
> > Bad_Timeout.
> > The SubscriptionId when receiving is different. Also, the times when these
> > clients
> > received Bad_SubscriptionIdInvalid were nearly the same.
> >
> > So, I guessed, as a result, I thought that OOME would occur as
> > MonitoredItemData
> > gathered a lot in the server.
> >
> > Anyways, I do not know the reason why the clients receive
> > Bad_SubscriptionIdInvalid
> > from the server.
> >
> > I am going to continue investigating problem areas.
> >
> > <kevinherron@xxxxxxxxx> wrote, Tue, 26 Dec 2017 08:05:29 -0800
> >
> > > I don't see anything that says delete should be called. For any
> > > subscription-related operation you received Bad_SubscriptionIdInvalid
> > for,
> > > I can't imagine why DeleteSubscriptions service would return anything but
> > > the same error.
> > >
> > > On Sun, Dec 24, 2017 at 10:18 PM, Shigeru Ishida <
> > ishida_shigeru@xxxxxxxxxxx
> > > > wrote:
> > >
> > > > Hi Kevin,
> > > >
> > > > I have a question about the processing of
> > onSubscriptionTransferFailed().
> > > >
> > > > According to Part 4 - 6.5 Re-establishing connections, should
> > > > BadSubscriptionIdInvalid
> > > > be received, should the client call deleteSubscriptions(the previous
> > > > SubscriptionId)
> > > > before createSubscription() ?
> > > >
> > > > Regards,
> > > >
> > > > --Shigeru
> > > > _______________________________________________
> > > > milo-dev mailing list
> > > > milo-dev@xxxxxxxxxxx
> > > > To change your delivery options, retrieve your password, or unsubscribe
> > > > from this list, visit
> > > > https://dev.eclipse.org/mailman/listinfo/milo-dev
> >
> > _______________________________________________
> > milo-dev mailing list
> > milo-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe
> > from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/milo-dev