#2628 Limit size of LinkedList of CIMEvents to be dispatched


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


  • 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:


  • Dave Blaschke

    Dave Blaschke - 2013-09-19
    • labels: --> Java Client (JSR48)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks