#2105 Failed to enable provider timing analysis with SfcbLocal

Performance
closed
sfcb (1090)
sfcb
5
2013-04-02
2010-11-02
No

Using the local interface connection in Sfcc, we could not enable the provider timing that is used with debug logging. In code inspection, we find that the check for sessionId is always failing since it is always 0 for local interface.

The attached patch file (for sfcb 1.3.9) provides the proposed resolution:

The proposal is to exclude the sessionId in the check whether to continue the timing process when requested. An added change is to remove the duplicate verification of the trace mask.

This is a performance fix to allow timing analysis with the SfcbLocal interface. The proposed solution has been tested to work in our environment. Please integrate a solution so that Sfcb can continue to work in our environment with future releases. Thanks.

Discussion

  • Chris Poblete

    Chris Poblete - 2010-11-02
    • priority: 5 --> 4
     
  • Narasimha Sharoff

    Verification of trace mask is not be required in TIMING_STOP if the uset that is set during TIMING_START is reset at the completion of TIMING_STOP. This check ensures TIMING_STOP must match a preceding TIMING_START.

    If uset is not reset, then TIMING_STOP may be called without a preceding TIMING_START and checking the trace mask becomes necessary.

     
  • Narasimha Sharoff

    reset uset in TIMING_STOP

     
  • Narasimha Sharoff

    Please verify if the patch posted works for you. It includes the sessionId change you have proposed as well.

     
  • Narasimha Sharoff

    • assigned_to: buccella --> nsharoff
     
  • Michael Chase-Salerno

    • Priority: 4 --> 5
     
  • Chris Buccella

    Chris Buccella - 2013-02-12
    • component: --> sfcb
     
  • Michael Chase-Salerno

    • status: open --> pending-fixed
     
  • Michael Chase-Salerno

    • Status: pending-fixed --> closed
     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks