It's all about the answers!

Ask a question

How to get around working with a PA history too big for the Eclipse client max heap size (-Xmx) allowed by OS ?


long TRUONG (3654123147) | asked Jun 05 '15, 3:19 a.m.
 We are on RTC/RRC 5.0.2 in Windows.

We are looking at using the Eclipse client to compare the Process specs at two different points in time through history of a Project Area.

Our history is so dense that we run out of heap space on the Eclipse client. We tried to increase -Xmx for more heap space, but found out that there is a limit imposed by OS. On our windows Win 7 (64 bit) we can only increase up to -Xmx1664m, otherwise the JVM cannot be created.

Is there any way to get around this? (We can always get the Process specs from the PA history on the webUI, but it does not have a compare function)

Also we wonder if our history (of process changes) is abnormally large with more than 10 changes per day, for the days we have looked at. We suspect that these changes are on addition of single (or few) custom attribute(s) to WItypes

2 answers



permanent link
long TRUONG (3654123147) | answered Jun 08 '15, 2:09 p.m.
 Found the solution but still no cigar. It looks like there is no limit (or pretty high we have yet to reach) for the 64-bit version of the Eclipse client (at least for 5.0.2 the one we tested): we tried up to -Xmx6G and still get a JVM created.

However our PA history (crazy there is at least 1 day with more than 48 changes during the day, if it is a 12 hrs working day it is still 4 changes an hour !!!)  so dense at -Xmx5G we still did not have enough heap space, and 5G on a 8GB  laptop does slow down the whole system significantly. We tried -Xmx6G but the 8GB laptop would not get anywhere.

permanent link
Donald Nong (14.5k614) | answered Jun 08 '15, 10:34 p.m.
Not sure why the compare viewer can take up so much memory, but you can play around with the settings under Windows > Preferences > General > Compare/Patch > Text Compare, particularly "disable capping when comparing large documents", to see if any setting(s) will affect the memory consumption.
You can also consider using an external compare tool to do the job. Just save the two versions of process configuration source to the disk and compare them. You may even get a better (or smarter) compare result comparing to Eclipse.
Just curious, what is the size of the file if you save the process configuration source to the disk?

Comments
long TRUONG commented Jun 09 '15, 1:52 p.m.

 Thx Don,


Sorry was not clear on statement; It is not the compare function which take up memory, it is the loading of full PA history which is never completed up to -Xmx5G to use the compare function, or anything else (supected, kept getting asked to exit the workbench). If there are ways to load parts of the history it would be fine.

That seem to be the case with the  webUi interface, can always cut and paste the process specs (only about 3MB) at any point in time to compare. webUI however lists other changes than those to the process specs, and with details, not short and sweet like via the Eclipse client.

Actually the first thing am trying to do is to cut and paste the full list of PA history entries, which is a lot shorter via the client.


Donald Nong commented Jun 10 '15, 2:33 a.m.

Ah, you mean there are too many revisions/versions of the process configuration source. In this case, it may get worse when time goes by, unless RTC Eclipse changes its behavior. I imagine that when RTC Eclipse client loads the history of the source, it also loads the actual content of each version (for performance purpose in terms of speed). Based on your description, I suspect that there are already 1000+ versions. So for a 3MB source, that will translate to 3GB+ memory at least. If RTC Eclipse does not "pre-load" the content, i.e. loads the label of each version only, I don't think you will face such a problem. That said, I don't have a better idea than what you have been doing.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.