View Issue Details

IDProjectCategoryView StatusLast Update
000182610000-007: Profilespublic2012-03-13 17:19
ReporterLiam Power Assigned ToPaul Hunkar  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.00 
Fixed in Version1.02 
Summary0001826: Resolution to Mantis issue 960 causes significant increase in RAM requirements for Embedded Datachange Subscription Server Facet
Description

The resolution to mantis issue 960 has resulted in the minimum notification queue size for the "Embedded Datachange Subscription Server Facet" increasing from 1 to 4, or by 400%.
This may increase BOM cost for embedded servers and/or cause significant schedule problems for vendors currently undertaking product development.

It is proposed that the "Embedded Datachange Subscription Server Facet" is exempted from queuing notifications (queue size of 1).

TagsNo tags attached.
Commit Version
Fix Due Date

Relationships

related to 0000960 closedMatthias Damm 10000-004: Services Publish and reconnect problem 

Activities

Liam Power

2012-01-17 18:55

reporter   ~0003211

Correction. This queue size should really be zero (as discussed in the Boca F2F) as a queue size of 1 is completely pointless. This means that for Embedded DataChange Republish will never return any queued notifications.

Paul Hunkar

2012-01-23 08:01

developer   ~0003223

I'm not sure what is expect on this mantis issue

Republish has to do with messages sent to the server, not what is in the queue for items to be sent - the "Embedded Datachange Subscription Server Facet" sets the queue size to 1, 960 does nto affect this.

The conformance unit for "Subscription Publish Min 02" set the minimum number of publish requests that can be queue to the server (2). It also sets the number of unconfirmed notifications (i.e. sent messages not acknowledged by the client as being recieved) that are to be buffered to 2.

mantis 960 changed how minimum notifications to buffer is calculated, it was being calculated by the keepalive interval (no conformance units listed this - so existing conformance units were in error for all publish related conformance units) The new requirement is to keep a minimum of 2x time the number of publish requests that can be queued as buffered notifications. This will require changes to all of subscription related profiles (no mantis issue listed for it as of yet - could fix under this mantis issue). The specification also allows a profile to overwrite the limit.

So what action should be taken - I propose the following
1) no changed to the "Subscription Publish Min 02" conformance unit (still leave it at 2).

pick one of these:
2a) Updated the "Subscription Publish Min 05" and "Subscription Publish Min 10" to increase the notification buffer limit to 10 and 20 respectively - but these are release profiles - so actually can not make the change with out a lot of other changes at the profile level

alternate 2b) create a new conformance units (listed as optional in released profiles) that deals with notification buffer sizes (messages to buffer).

Alternate 2c) Create new conformance unit and new profile that is titled "Support Subscription Robust Recovery" or something like it and add conformnace unit that describes the buffering as required. Could also include other items related to robust communication recovery.

Alternate 2d) do nothing - since spec allows profile to overwrite this limit.

Liam Power

2012-01-24 16:29

reporter   ~0003229

This issue arose because of memory constraints for the released "Embedded Datachange Subscription Server Facet".

Part 4 has been modified to say that notification message queue size (while nominally twice the publish request queue size) can be overriden by profiles.

In my opinion we should add a conformance unit to the Embedded Datachange Facet to specify that the minimum notification message queue size is zero for this case.

As Paul states there is no need to change "Subscription Publish Minimum 02".
Contrary to what Paul says above this CU makes no direction regarding the notification retransmission queue size and this CU has not at any time been in error.

Paul Hunkar

2012-03-13 16:42

developer   ~0003371

Updated text as discussed in meeting

Jim Luth

2012-03-13 17:19

administrator   ~0003378

Reviewed and agreed to changes in telecon.

Issue History

Date Modified Username Field Change
2012-01-06 20:09 Liam Power New Issue
2012-01-08 14:34 Paul Hunkar Relationship added related to 0000960
2012-01-08 14:34 Paul Hunkar Status new => assigned
2012-01-08 14:34 Paul Hunkar Assigned To => Paul Hunkar
2012-01-17 18:55 Liam Power Note Added: 0003211
2012-01-23 08:01 Paul Hunkar Note Added: 0003223
2012-01-23 08:01 Paul Hunkar Status assigned => feedback
2012-01-24 16:29 Liam Power Note Added: 0003229
2012-03-02 17:34 Paul Hunkar Status feedback => assigned
2012-03-13 16:42 Paul Hunkar Status assigned => resolved
2012-03-13 16:42 Paul Hunkar Resolution open => fixed
2012-03-13 16:42 Paul Hunkar Note Added: 0003371
2012-03-13 17:19 Jim Luth Status resolved => closed
2012-03-13 17:19 Jim Luth Note Added: 0003378
2012-03-13 17:19 Jim Luth Fixed in Version => 1.02