#2628 Limit size of LinkedList of CIMEvents to be dispatched

New_Feature
closed-fixed
Dave Blaschke
jsr48-client
5
2014-08-09
2013-03-25
Evgeny
No

Provide configuration option to limit size of LinkedList of org.sblim.cimclient.internal.wbem.indications.CIMEvent instances in org.sblim.cimclient.internal.wbem.indications.CIMEventDispatcher . When LinkedList size limit is reached, drop the oldest CIMEvents instances from the list in order to free space for the new ones.
Suggested default value for the limit --- 30K.

1 Attachments

Discussion

  • Dave Blaschke
    Dave Blaschke
    2013-03-25

    • status: open --> open-accepted
    • assigned_to: Dave Blaschke
    • component: none --> jsr48-client
    • milestone: Usability --> New_Feature
     
  • Dave Blaschke
    Dave Blaschke
    2013-03-25

    Shorten summary just a bit (-;

     
  • Dave Blaschke
    Dave Blaschke
    2013-03-25

    • summary: Provide configuration option to limit size of LinkedList of CIMEvent instances in CIMEventDispatcher --> Limit size of LinkedList of CIMEvents to be dispatched
     
  • Dave Blaschke
    Dave Blaschke
    2013-03-26

    The following new property has been created:

    # The maximum number of queued events (the fixed capacity of the
    # LinkedList of indications awaiting delivery to the listener). When
    # the maximum is reached, the oldest indications are discarded to make
    # room for the newest ones. A value of 0 is interpreted as infinity.
    # Type: Integer
    # Unit: Count
    # Recognition: On next creation of a WBEMListener
    # Range: 0 .. Integer.MAX_VALUE
    # Default: 0
    # sblim.wbem.listenerMaxQueuedEvents=0

    In order to maintain compatibility with older apps that assume there is no limit, the default value is 0 (infinity) as opposed to the 30000 suggested above. Apologies for the inconvenience, but I don't want folks out there upgrading to 2.2.3 and then seeing lots of "Deleted CIMEvent from the queue (maximum size reached)" messages in their trace logs along with the corresponding missing indications.

     
  • Dave Blaschke
    Dave Blaschke
    2013-03-26

    Patch sent for community review. During a 2 week period any exploiter may comment on the patch, request changes or turn it down completely (with good reason). For the time being the patch is part of the "Experimental" branch in CVS.

     
  • Dave Blaschke
    Dave Blaschke
    2013-03-26

    • status: open-accepted --> open-fixed
     
  • Dave Blaschke
    Dave Blaschke
    2013-03-27

    This patch can be applied to 2.1.x in an official maintenance release, if one is needed

     
  • Evgeny
    Evgeny
    2013-03-27

    Thanks for fast attention to this issue.

     
  • Dave Blaschke
    Dave Blaschke
    2013-05-08

    • status: open-fixed --> pending-fixed
     
  • Dave Blaschke
    Dave Blaschke
    2013-05-08

    The community review is completed and we received no substantial criticism. Therefore the patch has been approved and merged into the "HEAD" branch. The next release will pick it up.

     
  • Evgeny
    Evgeny
    2013-05-17

    When this fix will be available and in which version?

     
  • Dave Blaschke
    Dave Blaschke
    2013-05-20

    The fix will be in the next release (2.2.3) to be published on May 31

     
  • Dave Blaschke
    Dave Blaschke
    2013-05-31

    The patch was picked up by release 2.2.3 and will be closed.

     
  • Dave Blaschke
    Dave Blaschke
    2013-05-31

    • status: pending-fixed --> closed-fixed
     
  • Evgeny
    Evgeny
    2013-06-03

    We upgraded to v2.2.3 (our previous version was v.2.1.7). We saw change in CIMObjectPath constructor which broke several places in our application.
    With the new SBLIM jar, there is no CIMObjectPath with two string constructor:
    CIMObjectPath(String pObjectName, String pNamespace).
    But in our code we are using the above mentioned old constructor in many places to created CIMObjectPath instance.

    Can you give recommendation how to handle this change?
    Is CIMObjectPath(null, null, null, pNamespace, pObjectName, null) the right choice to update our code to work with v2.2.3?

     
  • Dave Blaschke
    Dave Blaschke
    2013-06-04

    The 2.2.x code stream is based on the finalized JSR48 1.0.0 spec, which had quite a few destructive changes in it from the preliminary version of the spec (2.0.x, 2.1.x code streams). In order to pass the TCK, the Java CIM Client had to conform with the finalized spec.

    Details of the changes are mentioned in the history doc file under the 2.2.0 section, the direct link is:

    http://sblim.sourceforge.net/cim-client2-v22-doc/org/sblim/cimclient/doc-files/history.html#220

     
  • Dave Blaschke
    Dave Blaschke
    2013-09-19

    • labels: --> Java Client (JSR48)