probs with CR.getAddressedIn()

Hi,

I noticed that I was having a problem with a particular CR when I call the .getAddressedIn() method on it.

On closer inspection, it turned out to be due to the label that it was addressed in now being deleted.

I did a bit more digging, and noticed that the CR offers a member .getAddressedInView(), and I notice that this it a time-based view-configuration, so I've assumed it's from the time-period when that label hadn't been deleted.

I noticed that I was able to get a successful call to .getAddressedIn() if I refreshed the labels of this time-based view, eg:

View v = CR.getAddressedInView();
if (v.isRefreshLabelsRequired())
  v.refreshLabels();
CR.getAddressedIn();

So that seems to work, but one gotchya is that it generates some network traffic each time .refreshLabels() is called:

Start: (rev 100) PROJ_CMD_LABEL_GET_INFO_EX Time: 726 millis; Sent: 70 bytes; Got: 6534 bytes
Start: (rev 100) PROJ_CMD_CATALOG_LOADSET Time: 87 millis; Sent: 314 bytes; Got: 4986 bytes

Is there any way to avoid this extra network traffic and still get the correct result returned in .getAddressedIn()?

I had a look at the netmonitor output of the CPC and noticed there was absolutely no network traffic when I click on the CRs tab, so it seems like the CPC had all the details cached beforehand (and it displays the deleted label in the 'Addressed In' field correctly).

Regards,
Gurce

  • what version of the sdk are you using?

    If 14.0, can you use this one?

    ftp://stsdkcust:LpeEFPwNMJ@emeaftp.microfocus.com/st-sdk-14.0-readme.htm

    if 13.0, can you use this one?

    ftp://stsdkcust:LpeEFPwNMJ@emeaftp.microfocus.com/st-sdk-13.0-readme.htm

    I seem to vaguely recall this being reported to me, and I needed to ensure some optimizations.

    If you are on the latest version, i'll have to run some tests and see if I can reproduce the traffic and suggest an optimization.

    I may need to come back to you for specific test scenario details.

  • actually, i missed something you'd asked specifically...

    >>one gotchya is that it generates some network traffic each time .refreshLabels() is called:

    that's because (I'm guessing) mpx is not enabled on your application.

    If you enable mpx on server connection, then only the first call to v.refreshLabels() will generate network traffic. all subsequent calls should no-op.

    if you cannot enable mpx (as for instance, if your server does not support mpx), then you would need to track the views on which you have called refreshLabels() in your code, and skip the call in subsequent passes. I think i recall you and I discussing mpx once before.

    mpx comes free with all releases of starteam, so there's really no good reason for it not to be enabled on your server & in your network.

    here's a wiki link to a treatise on the subject

    community.microfocus.com/.../24182.mpx-enabled-sdk-applications.aspx