GC not cleaning up in solaris

Hello,
I am running my application on jdk build 1.5.0_04-b05 and build 1.5.0_01-b08 on both solaris and windows XP.
I am performing a stress test on my application. In solaris,
1> With 64 bit opteron processor the application goes out of memory with 50 concurrent users and 150 hits per second. In this machine we have a dual processor with multi core support. (I tried this with both the 64 bit version and the 32 bit version). The GC verbose details are as follows :
2> In 64 bit sparc processor, the application goes out of memory a little later with the same number of users and hits as point 1.
3> The same test was done in windows and it works fine. The test has been running for more than 24 hours with the used up heap memory less than 30MB.
I used the same jvm parameters in all the 3 setup. They are as follows:
-Dsun.rmi.dgc.client.gcInterval=5000 -Dsun.rmi.dgc.server.gcInterval=5000 -Xms256m -Xmx256m -verbose:gc -Xloggc:/export/home/imm/sre/bep/gc.txt -XX:+PrintGCTimeStamps
When the virtual memory during startup is increased it comsumes all the given memory and then throws out of memeory exception.
The GC outout for case 1 with opteron is as follows:
0.000: [GC 5298K->1020K(258560K), 0.0406291 secs]
0.041: [Full GC 1020K->982K(258560K), 0.0316748 secs]
5.080: [GC 9303K->1486K(258560K), 0.0811895 secs]
5.161: [Full GC 1486K->1455K(258560K), 0.0459148 secs]
10.210: [GC 2554K->1535K(258560K), 0.0005359 secs]
10.211: [Full GC 1535K->1468K(258560K), 0.0433195 secs]
15.260: [GC 2126K->1492K(258560K), 0.0004989 secs]
15.261: [Full GC 1492K->1392K(258560K), 0.0543663 secs]
20.320: [GC 1832K->1392K(258560K), 0.0004772 secs]
20.321: [Full GC 1392K->1392K(258560K), 0.0429420 secs]
25.370: [GC 1832K->1392K(258560K), 0.0005152 secs]
25.371: [Full GC 1392K->1392K(258560K), 0.0510765 secs]
30.430: [GC 1832K->1392K(258560K), 0.0003944 secs]
30.431: [Full GC 1392K->1392K(258560K), 0.0429634 secs]
35.480: [GC 1832K->1392K(258560K), 0.0004860 secs]
35.481: [Full GC 1392K->1358K(258560K), 0.0496642 secs]
40.540: [GC 1798K->1358K(258560K), 0.0004453 secs]
40.541: [Full GC 1358K->1358K(258560K), 0.0429773 secs]
45.590: [GC 1798K->1358K(258560K), 0.0004753 secs]
45.591: [Full GC 1358K->1358K(258560K), 0.0472520 secs]
50.640: [GC 1798K->1358K(258560K), 0.0004749 secs]
50.641: [Full GC 1358K->1358K(258560K), 0.0473725 secs]
55.690: [GC 1798K->1358K(258560K), 0.0004053 secs]
55.691: [Full GC 1358K->1358K(258560K), 0.0429684 secs]
60.740: [GC 1798K->1358K(258560K), 0.0004899 secs]
60.741: [Full GC 1358K->1358K(258560K), 0.0473677 secs]
65.790: [GC 1798K->1358K(258560K), 0.0004762 secs]
65.791: [Full GC 1358K->1358K(258560K), 0.0429093 secs]
70.840: [GC 1798K->1358K(258560K), 0.0004293 secs]
70.841: [Full GC 1358K->1358K(258560K), 0.0428917 secs]
75.890: [GC 1798K->1358K(258560K), 0.0004723 secs]
75.891: [Full GC 1358K->1358K(258560K), 0.0473208 secs]
80.940: [GC 1798K->1358K(258560K), 0.0004768 secs]
80.941: [Full GC 1358K->1358K(258560K), 0.0472301 secs]
85.990: [GC 8411K->1687K(258560K), 0.0249314 secs]
86.015: [Full GC 1687K->1624K(258560K), 0.0560801 secs]
87.722: [GC 23576K->2328K(258560K), 0.0051641 secs]
88.751: [GC 24280K->2424K(258560K), 0.0080154 secs]
89.933: [GC 24376K->2536K(258560K), 0.1010941 secs]
90.775: [GC 24488K->2464K(258560K), 0.0389110 secs]
91.080: [GC 9281K->2200K(258560K), 0.0026209 secs]
91.083: [Full GC 2200K->2152K(258560K), 0.0770280 secs]
91.821: [GC 24104K->2792K(255680K), 0.0425849 secs]
92.689: [GC 24744K->2776K(257984K), 0.0055777 secs]
93.285: [GC 26456K->2776K(260864K), 0.0054491 secs]
94.070: [GC 29336K->2897K(260352K), 0.0372031 secs]
94.771: [GC 29457K->2856K(260800K), 0.0052392 secs]
95.434: [GC 29288K->2936K(260800K), 0.0056532 secs]
96.079: [GC 29368K->2880K(260800K), 0.0062496 secs]
96.170: [GC 6432K->2360K(260800K), 0.0014482 secs]
96.172: [Full GC 2360K->1988K(260800K), 0.0949127 secs]
96.887: [GC 28420K->2708K(260800K), 0.0053717 secs]
97.524: [GC 29140K->2644K(260160K), 0.0099417 secs]
98.221: [GC 29076K->2708K(260736K), 0.0052038 secs]
98.785: [GC 29140K->2676K(260736K), 0.0192233 secs]
99.348: [GC 29108K->2664K(260736K), 0.0050737 secs]
99.931: [GC 29224K->2700K(260800K), 0.0051073 secs]
100.479: [GC 29260K->2676K(260800K), 0.0054331 secs]
101.044: [GC 29364K->2816K(260864K), 0.0054478 secs]
101.279: [GC 14105K->2396K(260992K), 0.0023545 secs]
101.282: [Full GC 2396K->2344K(260992K), 0.0848894 secs]
101.932: [GC 29160K->3072K(260992K), 0.0052743 secs]
102.503: [GC 29888K->3068K(260992K), 0.0056237 secs]
103.164: [GC 29884K->3148K(260480K), 0.0051273 secs]
103.703: [GC 29836K->3140K(260608K), 0.0052521 secs]
104.204: [GC 29700K->3236K(260224K), 0.0053375 secs]
104.776: [GC 29668K->3200K(260224K), 0.0054409 secs]
105.256: [GC 29504K->3194K(260416K), 0.0053042 secs]
105.762: [GC 29498K->3338K(260992K), 0.0057884 secs]
106.307: [GC 30346K->3290K(261056K), 0.0052327 secs]
106.370: [GC 7437K->2846K(260992K), 0.0304355 secs]
106.401: [Full GC 2846K->2803K(260992K), 0.0955120 secs]
107.010: [GC 29747K->3531K(261056K), 0.0098562 secs]
107.530: [GC 30475K->3511K(260928K), 0.0054196 secs]
108.173: [GC 30455K->3767K(260992K), 0.0076216 secs]
108.584: [GC 30711K->6351K(259008K), 0.0115126 secs]
108.713: [GC 31246K->8559K(260032K), 0.0198573 secs]
108.860: [GC 33455K->10074K(258112K), 0.0157594 secs]
109.043: [GC 33050K->10967K(259072K), 0.0087569 secs]
109.207: [GC 33943K->12124K(258944K), 0.0102744 secs]
109.353: [GC 35100K->13440K(259008K), 0.0132230 secs]
109.489: [GC 36416K->14694K(258944K), 0.0213952 secs]
109.663: [GC 37542K->15983K(259008K), 0.0111713 secs]
109.806: [GC 38831K->17404K(258880K), 0.0348801 secs]
110.052: [GC 40124K->18494K(258944K), 0.0398586 secs]
110.297: [GC 41214K->20046K(258944K), 0.0133321 secs]
110.433: [GC 42830K->20894K(257600K), 0.0384046 secs]
110.604: [GC 43678K->21455K(259008K), 0.0199668 secs]
110.812: [GC 44431K->21900K(258880K), 0.0081364 secs]
111.029: [GC 44876K->23023K(259136K), 0.0149481 secs]
111.139: [GC 46319K->24388K(259072K), 0.0131117 secs]
111.314: [GC 47684K->25941K(259136K), 0.0579116 secs]
111.600: [GC 49301K->26855K(259264K), 0.0111728 secs]
111.763: [GC 50215K->27639K(258944K), 0.0078640 secs]
111.944: [GC 51063K->28527K(259136K), 0.0097125 secs]
112.120: [GC 51951K->28872K(259392K), 0.0081876 secs]
112.323: [GC 52680K->29028K(259456K), 0.0401437 secs]
112.491: [GC 52836K->30642K(259456K), 0.0085196 secs]
112.643: [GC 54514K->32406K(259392K), 0.0410580 secs]
112.872: [GC 56278K->33875K(259264K), 0.0305255 secs]
113.076: [GC 57363K->34566K(259328K), 0.0362425 secs]
113.222: [GC 58053K->36486K(259136K), 0.0183329 secs]
113.584: [GC 59846K->38525K(258688K), 0.0831191 secs]
113.814: [GC 61885K->39531K(259264K), 0.0115929 secs]
113.983: [GC 62827K->40210K(257984K), 0.0085451 secs]
114.129: [GC 63505K->41131K(259264K), 0.0094129 secs]
114.223: [GC 64555K->42989K(259136K), 0.0106563 secs]
114.382: [GC 66413K->44055K(259392K), 0.0296586 secs]
114.653: [GC 67735K->44739K(259392K), 0.0094424 secs]
114.809: [GC 68419K->45651K(259328K), 0.0131629 secs]
114.944: [GC 69395K->47103K(259392K), 0.0099406 secs]
115.093: [GC 70847K->48684K(259520K), 0.0193145 secs]
115.230: [GC 72620K->50061K(259520K), 0.0104775 secs]
115.339: [GC 73997K->51381K(259456K), 0.0916862 secs]
115.630: [GC 75381K->53063K(259520K), 0.0203287 secs]
115.895: [GC 77063K->53355K(259584K), 0.0475536 secs]
116.060: [GC 77355K->55168K(259456K), 0.0902021 secs]
116.314: [GC 79168K->56331K(259520K), 0.0124623 secs]
116.450: [GC 80139K->56801K(259456K), 0.0179823 secs]
116.574: [GC 80609K->57739K(259456K), 0.0821310 secs]
116.667: [GC 61058K->58041K(257344K), 0.0232911 secs]
116.691: [Full GC 58041K->32789K(257344K), 0.2853343 secs]
117.100: [GC 56661K->35422K(258880K), 0.0106802 secs]
117.267: [GC 58526K->36621K(259136K), 0.0744534 secs]
117.473: [GC 59725K->37724K(258880K), 0.0519006 secs]
117.660: [GC 60956K->38475K(259072K), 0.0087666 secs]
117.780: [GC 61707K->40039K(259264K), 0.0088044 secs]
117.920: [GC 63527K->41540K(259328K), 0.0101312 secs]
118.152: [GC 65028K->42751K(259200K), 0.0089847 secs]
118.280: [GC 66303K->43600K(259264K), 0.0086088 secs]
118.427: [GC 67152K->45014K(259456K), 0.0242123 secs]
118.570: [GC 68822K->46079K(259456K), 0.0093912 secs]
118.904: [GC 69887K->48470K(257920K), 0.0159965 secs]
119.090: [GC 70806K->48894K(258752K), 0.0092981 secs]
119.210: [GC 71230K->49747K(258624K), 0.0112231 secs]
119.360: [GC 72083K->50683K(258688K), 0.0096565 secs]
119.530: [GC 73019K->51873K(258688K), 0.0088949 secs]
119.660: [GC 74401K->53692K(258752K), 0.0110426 secs]
119.841: [GC 76220K->55114K(258816K), 0.0927330 secs]
120.070: [GC 77898K->56594K(258880K), 0.0107121 secs]
120.222: [GC 79378K->57631K(259008K), 0.0256038 secs]
120.370: [GC 80735K->58284K(259008K), 0.0106133 secs]
120.560: [GC 81381K->58761K(259200K), 0.0084454 secs]
120.644: [GC 82185K->60487K(259200K), 0.0094755 secs]
120.769: [GC 83911K->61701K(259200K), 0.0152661 secs]
120.984: [GC 85247K->63113K(259264K), 0.0234111 secs]
121.135: [GC 86665K->64089K(259456K), 0.0093904 secs]
121.244: [GC 87897K->65657K(259456K), 0.0110616 secs]
121.409: [GC 89465K->66411K(259392K), 0.0091815 secs]
121.563: [GC 90281K->66908K(259456K), 0.0091698 secs]
121.676: [GC 90780K->67696K(259456K), 0.0462961 secs]
121.944: [GC 91696K->69540K(259520K), 0.0178410 secs]
122.049: [GC 93540K->70925K(258752K), 0.0107090 secs]
122.161: [GC 94029K->72076K(259136K), 0.0107018 secs]
122.285: [GC 95180K->73483K(258944K), 0.0104197 secs]
122.424: [GC 96651K->74701K(259072K), 0.0105346 secs]
122.561: [GC 97869K->75751K(259072K), 0.0213580 secs]
122.621: [GC 81830K->76218K(259200K), 0.0396482 secs]
122.660: [Full GC 76218K->33732K(259200K), 0.3846923 secs]
123.165: [GC 57156K->35652K(259328K), 0.0072394 secs]
123.280: [GC 59076K->36744K(259264K), 0.0095283 secs]
123.400: [GC 60168K->37872K(259264K), 0.0092951 secs]
123.630: [GC 61360K->38410K(259264K), 0.0201495 secs]
123.755: [GC 61898K->40241K(259200K), 0.0265783 secs]
123.910: [GC 63729K->40919K(259328K), 0.0804006 secs]
124.283: [GC 64407K->43048K(259264K), 0.0139072 secs]
124.450: [GC 66536K->43582K(259328K), 0.0113958 secs]
124.553: [GC 67067K->44396K(259200K), 0.0582454 secs]
124.755: [GC 67884K->46634K(259136K), 0.0169854 secs]
124.910: [GC 70122K->47494K(259200K), 0.0104159 secs]
125.036: [GC 70726K->48909K(257920K), 0.0153570 secs]
125.310: [GC 72137K->49986K(259200K), 0.0284059 secs]
125.421: [GC 73282K->51544K(259136K), 0.0130127 secs]
125.570: [GC 74840K->52548K(259264K), 0.0203991 secs]
125.720: [GC 76036K->53743K(259200K), 0.0095618 secs]
125.870: [GC 77231K->54118K(259264K), 0.0123756 secs]
126.010: [GC 77734K->55477K(259328K), 0.0090780 secs]
126.093: [GC 79093K->57128K(259456K), 0.0171734 secs]
126.260: [GC 80936K->58961K(259456K), 0.0106528 secs]
126.400: [GC 82769K->60503K(259456K), 0.0101673 secs]
126.570: [GC 84247K->61086K(258368K), 0.0092675 secs]
126.731: [GC 84832K->61964K(259456K), 0.0083573 secs]
126.860: [GC 85772K->63026K(259392K), 0.0115571 secs]
127.110: [GC 86834K->64507K(259456K), 0.0105163 secs]
127.243: [GC 88379K->65208K(259520K), 0.0101151 secs]
127.420: [GC 89080K->66062K(259520K), 0.0083316 secs]
127.550: [GC 89998K->66682K(259520K), 0.0083127 secs]
127.628: [GC 90618K->68765K(259328K), 0.0233473 secs]
127.784: [GC 92509K->70312K(259456K), 0.0357637 secs]
127.992: [GC 94056K->71686K(259264K), 0.0199552 secs]
128.061: [GC 83421K->72501K(259392K), 0.0104887 secs]
128.072: [Full GC 72501K->54617K(259392K), 0.4235841 secs]
128.631: [GC 78425K->56545K(259456K), 0.0106043 secs]
128.756: [GC 80353K->57378K(259456K), 0.0110477 secs]
128.893: [GC 81186K->58638K(259456K), 0.0093738 secs]
129.004: [GC 82510K->59584K(259456K), 0.0160597 secs]
129.189: [GC 83456K->60479K(259456K), 0.0105004 secs]
129.355: [GC 84479K->62366K(259520K), 0.0268770 secs]
129.730: [GC 86366K->63296K(259584K), 0.0086322 secs]
129.840: [GC 87360K->64691K(259584K), 0.0105568 secs]
129.991: [GC 88755K->66088K(259520K), 0.0145921 secs]
130.160: [GC 90216K->66870K(259584K), 0.0090001 secs]
130.240: [GC 90998K->68315K(259584K), 0.0100335 secs]
130.399: [GC 92571K->69603K(259648K), 0.0101541 secs]
130.583: [GC 93859K->70802K(259648K), 0.0102904 secs]
130.720: [GC 95186K->71346K(259712K), 0.0089532 secs]
130.870: [GC 95730K->72095K(259776K), 0.0078861 secs]
130.990: [GC 96479K->72535K(259776K), 0.0072925 secs]
131.084: [GC 96919K->74240K(259648K), 0.0175759 secs]
131.250: [GC 98496K->75981K(259648K), 0.0109040 secs]
131.450: [GC 100237K->77376K(259648K), 0.0144169 secs]
131.580: [GC 101504K->78325K(259648K), 0.0093275 secs]
131.740: [GC 102453K->78781K(259648K), 0.0125445 secs]
131.880: [GC 102902K->79393K(259648K), 0.0081452 secs]
132.020: [GC 103521K->79641K(259648K), 0.0081326 secs]
132.150: [GC 103769K->80413K(258944K), 0.0085215 secs]
132.330: [GC 104541K->82444K(259328K), 0.0112491 secs]
132.450: [GC 106316K->83339K(259520K), 0.0108814 secs]
132.570: [GC 107211K->84605K(259328K), 0.0109781 secs]
132.690: [GC 108601K->85508K(259456K), 0.0093672 secs]
132.837: [GC 109508K->85932K(259712K), 0.0095909 secs]
132.940: [GC 110186K->86867K(259136K), 0.0085734 secs]
133.160: [GC 111123K->88541K(259520K), 0.0107741 secs]
133.300: [GC 112669K->89685K(259648K), 0.0173152 secs]
133.480: [GC 113813K->90623K(259520K), 0.0483837 secs]
133.637: [GC 114751K->91410K(259584K), 0.0095591 secs]
133.646: [Full GC 91410K->61447K(259584K), 0.4751292 secs]
134.190: [GC 85575K->63463K(259520K), 0.0081542 secs]
134.372: [GC 87527K->64458K(259584K), 0.0193067 secs]
134.527: [GC 88522K->65633K(259648K), 0.0097511 secs]
134.667: [GC 89825K->66705K(259648K), 0.0125232 secs]
134.791: [GC 90897K->68184K(259584K), 0.0093706 secs]
135.152: [GC 92376K->69011K(259648K), 0.0134800 secs]
135.320: [GC 93203K->70086K(259712K), 0.0090932 secs]
135.451: [GC 94406K->71011K(259712K), 0.0189843 secs]
135.612: [GC 95331K->72345K(259712K), 0.0113213 secs]
135.829: [GC 96729K->73288K(259712K), 0.0196332 secs]
135.974: [GC 97672K->73730K(259840K), 0.0085308 secs]
136.130: [GC 98238K->74426K(259840K), 0.0077318 secs]
136.220: [GC 98938K->75801K(259712K), 0.0081964 secs]
136.321: [GC 100185K->77246K(259456K), 0.0113181 secs]
136.530: [GC 101630K->77474K(259712K), 0.0101278 secs]
136.614: [GC 101730K->79253K(259328K), 0.0305163 secs]
136.840: [GC 103509K->79881K(259712K), 0.0102394 secs]
137.000: [GC 104073K->80217K(259648K), 0.0131113 secs]
137.131: [GC 104411K->81078K(259648K), 0.0074875 secs]
137.270: [GC 105334K->81532K(259648K), 0.0084748 secs]
137.400: [GC 105788K->82388K(259648K), 0.0082360 secs]
137.510: [GC 106772K->83827K(259712K), 0.0312219 secs]
137.687: [GC 108211K->85118K(259776K), 0.0158220 secs]
137.850: [GC 109502K->85960K(259776K), 0.0103268 secs]
137.990: [GC 110344K->87347K(259648K), 0.0082158 secs]
138.110: [GC 111603K->88340K(259712K), 0.0086140 secs]
138.200: [GC 112596K->90303K(259392K), 0.0204263 secs]
138.340: [GC 114303K->91417K(259584K), 0.0207676 secs]
138.605: [GC 115417K->92113K(259392K), 0.0111618 secs]
138.700: [GC 116177K->92953K(259520K), 0.0091674 secs]
138.820: [GC 117017K->94518K(259584K), 0.0102500 secs]
138.920: [GC 118774K->96125K(259648K), 0.0111086 secs]
139.042: [GC 120379K->97531K(259776K), 0.0150000 secs]
139.131: [GC 112333K->98043K(259776K), 0.0092666 secs]
139.140: [Full GC 98043K->72705K(259776K), 0.5438677 secs]
139.800: [GC 97089K->74273K(259648K), 0.0522370 secs]
140.030: [GC 98657K->75676K(259712K), 0.0149113 secs]
140.135: [GC 100060K->77115K(259648K), 0.0141050 secs]
140.420: [GC 101371K->78657K(259456K), 0.0102444 secs]
140.577: [GC 102913K->79868K(259712K), 0.0126200 secs]
140.740: [GC 104060K->80468K(259648K), 0.0084627 secs]
140.860: [GC 104658K->81244K(259648K), 0.0075765 secs]
141.000: [GC 105500K->82072K(259648K), 0.0083363 secs]
141.120: [GC 106328K->82591K(259712K), 0.0079298 secs]
141.320: [GC 106975K->84461K(259712K), 0.0242655 secs]
141.450: [GC 108845K->85690K(259712K), 0.0110511 secs]
141.570: [GC 109946K->86532K(259712K), 0.0087513 secs]
141.710: [GC 110788K->87733K(259712K), 0.0086036 secs]
141.820: [GC 111989K->89048K(259136K), 0.0214806 secs]
141.960: [GC 113304K->90227K(259712K), 0.0095798 secs]
142.110: [GC 114547K->90887K(259648K), 0.0088332 secs]
142.323: [GC 115207K->92241K(259776K), 0.0135098 secs]
142.430: [GC 116689K->93429K(259776K), 0.0088012 secs]
142.590: [GC 117877K->93538K(259712K), 0.0084773 secs]
142.710: [GC 117986K->94536K(259776K), 0.0079032 secs]
142.800: [GC 118984K->96428K(259648K), 0.0103228 secs]
142.950: [GC 120812K->97455K(259776K), 0.0092926 secs]
143.141: [GC 121839K->98862K(259776K), 0.0282773 secs]
143.330: [GC 123246K->99605K(259776K), 0.0094069 secs]
143.440: [GC 123989K->100505K(259648K), 0.0088103 secs]
143.570: [GC 124889K->101422K(259712K), 0.0096219 secs]
143.730: [GC 125806K->101953K(259840K), 0.0087444 secs]
143.851: [GC 126465K->102972K(259200K), 0.0087270 secs]
144.021: [GC 127484K->104851K(258624K), 0.0146194 secs]
144.162: [GC 128211K->106190K(259264K), 0.0156663 secs]
144.260: [GC 129550K->107730K(258944K), 0.0105363 secs]
144.390: [GC 131154K->108924K(259136K), 0.0098115 secs]
144.552: [GC 132348K->110558K(259392K), 0.0168478 secs]
144.690: [GC 134302K->111178K(259456K), 0.0098528 secs]
144.740: [GC 119919K->111564K(259328K), 0.0307955 secs]
144.771: [Full GC 111564K->69833K(259328K), 0.6830955 secs]
145.719: [GC 93449K->71473K(259392K), 0.0256363 secs]
145.834: [GC 95089K->72830K(259392K), 0.0105204 secs]
145.949: [GC 96510K->73476K(259392K), 0.0097199 secs]
146.061: [GC 97156K->74897K(259456K), 0.0152824 secs]
146.200: [GC 98641K->75782K(258496K), 0.0095795 secs]
146.348: [GC 99526K->76078K(259328K), 0.0436585 secs]
146.510: [GC 99822K->77914K(259328K), 0.0145255 secs]
146.640: [GC 101658K->79423K(259392K), 0.0118561 secs]
146.790: [GC 103167K->80200K(258432K), 0.0086358 secs]
146.887: [GC 103944K->81544K(259392K), 0.0210233 secs]
147.030: [GC 105352K->82638K(259392K), 0.0098094 secs]
147.140: [GC 106446K->83999K(259520K), 0.0103403 secs]
147.259: [GC 108063K->85351K(259520K), 0.0108954 secs]
147.489: [GC 109415K->86311K(259584K), 0.0090860 secs]
147.645: [GC 110567K->86939K(259648K), 0.0081960 secs]
147.727: [GC 111195K->88425K(259776K), 0.0087978 secs]
147.883: [GC 112809K->88973K(259776K), 0.0088369 secs]
148.029: [GC 113357K->89549K(259648K), 0.0080105 secs]
148.141: [GC 113933K->90341K(259712K), 0.0159352 secs]
148.320: [GC 114725K->92515K(258176K), 0.0107048 secs]
148.435: [GC 115363K->93825K(259008K), 0.0098493 secs]
148.559: [GC 116673K->94844K(258816K), 0.0085762 secs]
148.695: [GC 117756K->95447K(258944K), 0.0071696 secs]
148.825: [GC 118356K->96536K(258816K), 0.0087066 secs]
148.944: [GC 119704K->97820K(259008K), 0.0366399 secs]
149.129: [GC 120988K->99221K(259136K), 0.0093833 secs]
149.235: [GC 122773K->100061K(259264K), 0.0085292 secs]
149.345: [GC 123613K->101016K(259328K), 0.0083651 secs]
149.441: [GC 124760K->102249K(259392K), 0.0092667 secs]
149.590: [GC 125993K->102733K(259456K), 0.0090504 secs]
149.720: [GC 126669K->103684K(259456K), 0.0086995 secs]
149.801: [GC 127620K->105392K(259520K), 0.0190386 secs]
150.020: [GC 129456K->106459K(259584K), 0.0109400 secs]
150.130: [GC 130523K->107346K(259520K), 0.0097110 secs]
150.260: [GC 131538K->108409K(259584K), 0.0088495 secs]
150.390: [GC 132601K->109529K(259648K), 0.0091103 secs]
150.490: [GC 127539K->109800K(259712K), 0.0075316 secs]
150.498: [Full GC 109800K->93300K(259712K), 0.6854301 secs]
151.301: [GC 117748K->94949K(259840K), 0.0077410 secs]
151.400: [GC 119461K->96339K(259776K), 0.0091381 secs]
151.540: [GC 120851K->97814K(259648K), 0.0100263 secs]
151.670: [GC 122070K->99050K(259712K), 0.0092197 secs]
151.786: [GC 123306K->100709K(259648K), 0.0103253 secs]
151.939: [GC 124965K->101025K(259712K), 0.0089636 secs]
152.070: [GC 125281K->103061K(259456K), 0.0097542 secs]
152.242: [GC 127061K->104028K(259584K), 0.0125091 secs]
152.330: [GC 128028K->105545K(259456K), 0.0095835 secs]
152.460: [GC 129545K->106620K(259520K), 0.0204462 secs]
152.570: [GC 130620K->107813K(259520K), 0.0094771 secs]
152.750: [GC 132005K->108803K(259584K), 0.0112589 secs]
152.930: [GC 132995K->110219K(259776K), 0.0094223 secs]
153.070: [GC 134667K->110793K(259776K), 0.0100400 secs]
153.180: [GC 135241K->112113K(259840K), 0.0089014 secs]
153.250: [GC 136625K->113978K(259584K), 0.0113224 secs]
153.420: [GC 138490K->114620K(259840K), 0.0094741 secs]
153.540: [GC 139068K->115798K(259328K), 0.0105631 secs]
153.630: [GC 140246K->117006K(259712K), 0.0103702 secs]
153.860: [GC 141454K->118260K(259712K), 0.0114160 secs]
154.000: [GC 142706K->119282K(259840K), 0.0103568 secs]
154.162: [GC 143860K->119732K(259840K), 0.0079984 secs]
154.240: [GC 144308K->121465K(259904K), 0.0105605 secs]
154.360: [GC 146105K->122406K(259904K), 0.0106191 secs]
154.520: [GC 147050K->123610K(259904K), 0.0101873 secs]
154.702: [GC 148250K->125044K(259904K), 0.0190105 secs]
154.823: [GC 149684K->126254K(259904K), 0.0195343 secs]
154.980: [GC 150894K->127035K(259904K), 0.0092055 secs]
155.070: [GC 151675K->128722K(259648K), 0.0102487 secs]
155.230: [GC 153106K->129780K(259776K), 0.0127310 secs]
155.333: [GC 154164K->131254K(259712K), 0.0114344 secs]
155.560: [GC 155638K->132847K(259520K), 0.0190104 secs]
155.721: [GC 157231K->133805K(259776K), 0.0104782 secs]
155.830: [GC 158125K->134292K(259712K), 0.0089642 secs]
155.940: [GC 158612K->135414K(259712K), 0.0211790 secs]
156.257: [GC 152418K->136721K(259712K), 0.0103238 secs]
156.268: [Full GC 136721K->105858K(259712K), 0.8179786 secs]
157.241: [GC 130178K->107338K(259712K), 0.0081037 secs]
157.350: [GC 131722K->107989K(259712K), 0.0075875 secs]
157.480: [GC 132373K->108891K(259712K), 0.0081972 secs]
157.590: [GC 133403K->109970K(259776K), 0.0084959 secs]
157.672: [GC 134482K->111934K(259648K), 0.0110189 secs]
157.803: [GC 136318K->113273K(259776K), 0.0176278 secs]
158.000: [GC 137657K->114087K(259648K), 0.0111345 secs]
158.121: [GC 138471K->115169K(259712K), 0.0088466 secs]
158.242: [GC 139553K->116369K(259712K), 0.0107197 secs]
158.350: [GC 140881K->117874K(259776K), 0.0108543 secs]
158.510: [GC 142386K->118277K(259904K), 0.0084723 secs]
158.610: [GC 142917K->119849K(259648K), 0.0405254 secs]
158.800: [GC 144489K->121183K(259904K), 0.0101685 secs]
158.930: [GC 145759K->121974K(259840K), 0.0087501 secs]
159.000: [GC 146550K->123725K(259776K), 0.0103658 secs]
159.130: [GC 148237K->124952K(259840K), 0.0139574 secs]
159.290: [GC 149464K->125779K(259840K), 0.0091102 secs]
159.420: [GC 150352K->126803K(259840K), 0.0219942 secs]
159.560: [GC 151379K->128234K(259776K), 0.0096336 secs]
159.700: [GC 152810K->129288K(259840K), 0.0099403 secs]
159.840: [GC 153864K->130345K(259904K), 0.0091503 secs]
159.990: [GC 155049K->131404K(259904K), 0.0092111 secs]
160.130: [GC 156108K->131560K(259840K), 0.0210459 secs]
160.284: [GC 156264K->132189K(259904K), 0.0080220 secs]
160.427: [GC 156893K->133687K(259968K), 0.0089788 secs]
160.605: [GC 158455K->135233K(259904K), 0.0099683 secs]
160.754: [GC 160001K->135492K(259776K), 0.0084599 secs]
160.875: [GC 160004K->136171K(259840K), 0.0094417 secs]
160.999: [GC 160683K->137348K(259840K), 0.0096554 secs]
161.105: [GC 161924K->138402K(259840K), 0.0088675 secs]
161.265: [GC 162978K->140285K(258560K), 0.0249045 secs]
161.606: [GC 163645K->141408K(259264K), 0.0108132 secs]
161.699: [GC 164768K->142906K(258944K), 0.0108987 secs]
161.855: [GC 166330K->143775K(259136K), 0.0104339 secs]
161.986: [GC 167199K->144439K(259456K), 0.0091102 secs]
162.124: [GC 168181K->144786K(259456K), 0.0088190 secs]
162.239: [GC 168530K->146246K(259328K), 0.0083943 secs]
162.260: [GC 149127K->146374K(257152K), 0.0083164 secs]
162.268: [Full GC 146374K->116551K(257152K), 0.8826773 secs]
163.247: [GC 140295K->118351K(259392K), 0.0139780 secs]
163.401: [GC 141903K->119959K(259328K), 0.0105559 secs]
163.580: [GC 143511K->120898K(259200K), 0.0094614 secs]
163.700: [GC 144514K->121417K(259264K), 0.0076767 secs]
163.780: [GC 145033K->123515K(259328K), 0.0099957 secs]
163.907: [GC 147259K->125076K(259456K), 0.0105407 secs]
164.022: [GC 148820K->126462K(259328K), 0.0115959 secs]
164.230: [GC 150206K->127536K(259392K), 0.0102217 secs]
164.370: [GC 151280K->128668K(259392K), 0.0151311 secs]
164.480: [GC 152604K->129643K(259456K), 0.0083621 secs]
164.620: [GC 153579K->130220K(259648K), 0.0098366 secs]
164.740: [GC 154412K->131384K(259648K), 0.0084270 secs]
164.890: [GC 155576K->132357K(259648K), 0.0090689 secs]
165.010: [GC 156613K->133959K(259648K), 0.0110692 secs]
165.175: [GC 158215K->135158K(259648K), 0.0114957 secs]
165.295: [GC 159542K->136008K(259712K), 0.0087623 secs]
165.422: [GC 160392K->136620K(259712K), 0.0081072 secs]
165.520: [GC 161132K->137983K(259776K), 0.0086857 secs]
165.610: [GC 162495K->139668K(259776K), 0.0173994 secs]
165.760: [GC 164052K->140591K(258944K), 0.0097686 secs]
165.941: [GC 164975K->142216K(259648K), 0.0294050 secs]
166.100: [GC 166536K->142739K(259712K), 0.0093754 secs]
166.230: [GC 167059K->143279K(259776K), 0.0081788 secs]
166.350: [GC 167663K->143954K(258944K), 0.0077032 secs]
166.470: [GC 168338K->144633K(259776K), 0.0082701 secs]
166.590: [GC 169081K->146371K(259712K), 0.0098312 secs]
166.990: [GC 170808K->147432K(259776K), 0.0115340 secs]
167.101: [GC 171752K->148506K(259200K), 0.0105071 secs]
167.225: [GC 172826K->149601K(259648K), 0.0121567 secs]
167.321: [GC 173921K->151006K(259648K), 0.0110984 secs]
167.460: [GC 175326K->151869K(259712K), 0.0213564 secs]
167.581: [GC 176381K->153544K(259776K), 0.0149168 secs]
167.765: [GC 178056K->154657K(259840K), 0.0265350 secs]
167.880: [GC 179169K->155907K(259200K), 0.0102934 secs]
167.980: [GC 180419K->157445K(259712K), 0.0119606 secs]
168.120: [GC 181893K->158307K(259776K), 0.0115248 secs]
168.230: [GC 178701K->159363K(259776K), 0.0108225 secs]
168.241: [Full GC 159363K->119156K(259776K), 1.1111789 secs]
169.453: [GC 143668K->120756K(259840K), 0.0073420 secs]
169.590: [GC 145268K->121637K(259712K), 0.0214192 secs]
169.790: [GC 146213K->123138K(259776K), 0.0097100 secs]
169.910: [GC 147714K->124403K(259840K), 0.0097816 secs]
170.050: [GC 148915K->125126K(259264K), 0.0087220 secs]
170.150: [GC 149638K->126277K(259840K), 0.0092401 secs]
170.218: [GC 150853K->127800K(259776K), 0.0111775 secs]
170.370: [GC 152376K->128639K(259904K), 0.0099885 secs]
170.595: [GC 153279K->130258K(259776K), 0.0380111 secs]
170.712: [GC 154898K->131337K(259840K), 0.0120818 secs]
170.845: [GC 155785K->133105K(259776K), 0.0135968 secs]
170.980: [GC 157553K->134143K(259776K), 0.0111760 secs]
171.110: [GC 158527K->134955K(259776K), 0.0082068 secs]
171.210: [GC 159339K->136231K(259648K), 0.0093453 secs]
171.380: [GC 160615K->137665K(259712K), 0.0112009 secs]
171.522: [GC 162049K->139152K(259712K), 0.0108628 secs]
171.644: [GC 163728K->140384K(259776K), 0.0104637 secs]
171.800: [GC 164960K->140824K(259840K), 0.0085917 secs]
171.890: [GC 165464K->142642K(259904K), 0.0102357 secs]
172.083: [GC 167282K->143787K(259904K), 0.0097714 secs]
172.421: [GC 168427K->144931K(259328K), 0.0120501 secs]
172.521: [GC 169571K->146104K(259840K), 0.0102366 secs]
172.680: [GC 170744K->146810K(259840K), 0.0089064 secs]
172.790: [GC 171450K->147850K(259840K), 0.0094117 secs]
172.950: [GC 172618K->148525K(259904K), 0.0091588 secs]
173.050: [GC 173293K->149536K(260032K), 0.0419584 secs]
173.200: [GC 174432K->151017K(260032K), 0.0105584 secs]
173.360: [GC 175913K->151889K(259904K), 0.0101996 secs]
173.470: [GC 176657K->153281K(259968K), 0.0094218 secs]
173.581: [GC 178049K->154636K(259776K), 0.0104715 secs]
173.680: [GC 179273K->156219K(259840K), 0.0100761 secs]
173.815: [GC 180859K->157294K(259840K), 0.0268005 secs]
174.000: [GC 181806K->158229K(259136K), 0.0093121 secs]
174.150: [GC 182741K->158733K(259712K), 0.0082343 secs]
174.270: [GC 183180K->159329K(259776K), 0.0081847 secs]
174.370: [GC 183777K->160397K(259840K), 0.0086826 secs]
174.490: [GC 184909K->161515K(259840K), 0.0097579 secs]
174.510: [GC 164104K->161689K(259456K), 0.0088441 secs]
174.519: [Full GC 161689K->142083K(259456K), 1.0192045 secs]
175.640: [GC 166211K->144179K(259264K), 0.0308231 secs]
175.828: [GC 168307K->145034K(259584K), 0.0129342 secs]
175.955: [GC 169034K->145358K(258368K), 0.0092916 secs]
176.053: [GC 169358K->146508K(259520K), 0.0096998 secs]
176.169: [GC 170508K->148097K(259520K), 0.0131187 secs]
176.310: [GC 172097K->148854K(259648K), 0.0096410 secs]
176.490: [GC 172982K->149982K(258816K), 0.0096449 secs]
176.600: [GC 174110K->151213K(259648K), 0.0089362 secs]
176.731: [GC 175399K->152055K(259584K), 0.0089945 secs]
176.890: [GC 176247K->152725K(259648K), 0.0088543 secs]
177.020: [GC 177045K->153205K(259648K), 0.0076772 secs]
177.120: [GC 177525K->154088K(259776K), 0.0076902 secs]
177.190: [GC 178600K->155708K(259776K), 0.0102108 secs]
177.401: [GC 180220K->156942K(259840K), 0.0229307 secs]
177.730: [GC 181454K->158060K(259840K), 0.0096245 secs]
177.900: [GC 182572K->158504K(259840K), 0.0092189 secs]
177.973: [GC 183015K->160076K(259712K), 0.0097142 secs]
178.071: [GC 184588K->162013K(259584K), 0.0127248 secs]
178.227: [GC 186141K->162723K(259648K), 0.0160011 secs]
178.360: [GC 186851K->163389K(259648K), 0.0098074 secs]
178.520: [GC 187517K->164844K(259648K), 0.0105532 secs]
178.680: [GC 188972K->165610K(259520K), 0.0113258 secs]
178.760: [GC 189738K->166860K(259584K), 0.0095883 secs]
178.871: [GC 190988K->168068K(259584K), 0.0127405 secs]
178.985: [GC 192324K->169023K(259648K), 0.0116551 secs]
179.127: [GC 193279K->169990K(259712K), 0.0340165 secs]
179.350: [GC 194374K->171255K(259776K), 0.0116869 secs]
179.430: [GC 195639K->172756K(259776K), 0.0110752 secs]
179.520: [GC 197204K->174311K(259776K), 0.0127092 secs]
179.670: [GC 198759K->175409K(259712K), 0.0109643 secs]
179.820: [GC 199921K->175671K(259776K), 0.0113237 secs]
179.950: [GC 200183K->176479K(259840K), 0.0747956 secs]
180.140: [GC 200991K->177988K(259840K), 0.0106083 secs]
180.250: [GC 202500K->178975K(259712K), 0.0101589 secs]
180.360: [GC 203488K->180341K(259776K), 0.0109295 secs]
180.505:

Hello,
I am running my application on jdk build
ild 1.5.0_04-b05 and build
1.5.0_01-b08 on both solaris and windows XP.
I am performing a stress test on my application. In
solaris,
1> With 64 bit opteron processor the application goes
out of memory with 50 concurrent users and 150 hits
per second. In this machine we have a dual processor
with multi core support. (I tried this with both the
64 bit version and the 32 bit version). The GC
verbose details are as follows :
2> In 64 bit sparc processor, the application goes
out of memory a little later with the same number of
users and hits as point 1.
3> The same test was done in windows and it works
fine. The test has been running for more than 24
hours with the used up heap memory less than 30MB.
I used the same jvm parameters in all the 3 setup.
They are as follows:
-Dsun.rmi.dgc.client.gcInterval=5000 -Dsun.rmi.dgc.server.gcInterval=5000 -Xms256m
-Xmx256m -verbose:gc -Xloggc:/export/home/imm/sre/bep/gc.txt
-XX:+PrintGCTimeStamps
When the virtual memory during startup is increased
it comsumes all the given memory and then throws out
of memeory exception.
The GC outout for case 1 with opteron is as
follows:
...What is the exact OutOfMemoryError you are seeing? Usually there is a description
printed along with the OOM, e.g., java.lang.OutOfMemoryError: java heap space.
The 64-bit JVM will use somewhat more memory than a 32-bit JVM for the same
application because the size of a reference doubles, as do the sizes of internal
data types used by the JVM. However, the typical increase is 15-30%, not the huge
difference you are seeing.
Another difference is that on a dual processor solaris box you are likely getting
(a) the server compiler, and (b) the parallel garbage collector. On windows,
you will get the client compiler and serial garbage collector. To normalize
things, try rerunning with the following options on windows and solaris:
-client -XX:+UserSerialGC -Xms256m -Xmx256m -XX:+PrintGCDetails
If the app fails only on solaris, then please try again on solaris with the above
options plus:
-XX:+PrintClassHistogram
and monitor the output from GC. When the app is getting close to OutOfMemory,
send it a SIGQUIT (kill -QUIT <pid>) and save the output. It will give us some idea
of the types filling up the heap. Post the histogram and the last part of the GC log
(no need for the entire GC log).

Similar Messages

HTTP Server is not currently supported with Solaris 10

I am having a problem to start the HTTP Server on Solaris 10 (I am installing HTTP Server as part of HTMLDB installation on Solaris 10).
I had a problem to install it at first, however I've found on 'AskTom' that unsetting ORA_NLS33 helps and it did. Now I can't start the HTTP server and I've found on metalink that 'HTTP Server is not currently supported with Solaris 10, this is targeted for Q2CY05'.
Has this been fixed yet?
Thank you for your time.
DanielD

Hi james,
I have checked the log file but i am unable to find what to do next.
I am giving the small piece of content of the log file. The following messages are repeating again and again...
Log content:-
07/09/23 17:20:36 Start process
/dev011/oracle/product/10.1.3.1/OracleAS_1/Apache/Apache/bin/apachectl startssl: execing httpd
07/09/23 17:22:26 Start process
/dev011/oracle/product/10.1.3.1/OracleAS_1/Apache/Apache/bin/apachectl startssl: execing httpd
07/09/23 17:22:30 Start process
/dev011/oracle/product/10.1.3.1/OracleAS_1/Apache/Apache/bin/apachectl startssl: execing httpd
07/09/23 17:24:40 Start process
/dev011/oracle/product/10.1.3.1/OracleAS_1/Apache/Apache/bin/apachectl startssl: execing httpd
07/09/23 17:24:44 Start process
/dev011/oracle/product/10.1.3.1/OracleAS_1/Apache/Apache/bin/apachectl startssl: execing httpd
07/09/23 17:26:36 Start process
/dev011/oracle/product/10.1.3.1/OracleAS_1/Apache/Apache/bin/apachectl startssl: execing httpd
07/09/23 17:26:42 Start process
/dev011/oracle/product/10.1.3.1/OracleAS_1/Apache/Apache/bin/apachectl startssl: execing httpd
07/09/23 17:28:57 Start process
/dev011/oracle/product/10.1.3.1/OracleAS_1/Apache/Apache/bin/apachectl startssl: execing httpd
07/09/23 17:29:01 Start process
/dev011/oracle/product/10.1.3.1/OracleAS_1/Apache/Apache/bin/apachectl startssl: execing httpd

Select() function is not working properly in solaris 10.

Hi ,
We are facing an issue with select() in Solaris 10. we had written a sample program to this issue.
Program name :- sel.cpp
int main()
struct timeval sleeptime;
sleeptime.tv_sec = 60;
printf("1\n");
select(0,NULL,NULL,NULL,&sleeptime);
printf("2");
return 0;
When i run this program in Solaris 9, its printing 1 and after one minute its printing 2.
When i run this program on Solaris 10, its printing 1 and 2 without waiting for 60 seconds.
When i tried to print tv_usec, its printing as 0 in solaris 9 and some garbage values in solaris 10.
I think because of that the above select function is not working properly in solaris 10.
Why the tv_usec is not taking 0 as default values in Solaris 10?
We are using our legacy code for past 20 years. So, before going to do any changes we are trying to find why this happenig like this.
Thanks a lot.
Regards,
Srikanth.

haisrig wrote:
Hi ,
We are facing an issue with select() in Solaris 10. we had written a sample program to this issue.
Program name :- sel.cpp
int main()
struct timeval sleeptime;
sleeptime.tv_sec = 60;
printf("1\n");
select(0,NULL,NULL,NULL,&sleeptime);
printf("2");
return 0;
When i run this program in Solaris 9, its printing 1 and after one minute its printing 2.
When i run this program on Solaris 10, its printing 1 and 2 without waiting for 60 seconds.
When i tried to print tv_usec, its printing as 0 in solaris 9 and some garbage values in solaris 10.
I think because of that the above select function is not working properly in solaris 10.
Why the tv_usec is not taking 0 as default values in Solaris 10?
We are using our legacy code for past 20 years. So, before going to do any changes we are trying to find why this happenig like this.Hi
It sounds to me that you've been lucky for 20 years then.
Local POD variables on the stack that aren't explicitly initialized can contain any value. Here's what I see in your app with dbx
(dbx) run
Running: sel
stopped in main at line 9 in file "sel.cpp"
    9      sleeptime.tv_sec = 60;
(dbx) print sleeptime
sleeptime = {
    tv_sec = -4198732
    tv_usec = 0
}That's on a Solaris 10 SPARC machine. If I try it on a Solaris 10 x86 box then I get
(dbx) print sleeptime
sleeptime = {
tv_sec = -830490588
tv_usec = 134510556
and I see the behaviour that you describe.
Paul

Failover cluster not cleanly shutting down service

I've got a two node 2008 R2 failover cluster. I have a single service being managed by it that I configured just as a generic service. The failover works perfectly when the service is stopped, or when one of the machines goes down, and the immediate
failback I have configured works perfectly in both scenarios as well.
However, there's an issue when I take the networking down on the preferred owner of the service. As far as I can tell (this is the first time I've tried failover clustering, so I'm learning), when I take the networking down, the cluster service shuts
down, and in turn shuts down the service I've told it to manage. At this point, when the services aren't running, the service fails over to the secondary as intended. The problem shows up when I turn the networking back on. The service tries
and fails to start on the primary (as many times as I've configured it to try), and then eventually gives up and goes back to the secondary.
The reason for this, examining logs for the service, is that the required port is already in use. I checked some more, and sure enough, when I take the networking offline the service gets shut down, but the executable is still running. This is
repeatable every time. When I just stop the service, though, the executables go away. So it's something to do specifically with how the managed service gets shut down *when it's shut down due to the cluster service stopping*. For some reason
it's not cleaning up that associated executable.
Any ideas as to why this is happening and how to fix/work around it would be extremely welcome. Thank you!

Try to generate cluster log using closter log /g /copy:<path to a local folder>. You might need to bump up log verbosity using cluster /prop ClusterLogLevel=5 (you can check current level using cluster /prop).
You also can look at the SCM diagnostic channel in the event viewer. Start eventvwr. Wait for the clock icon on the Application and Services Logs to go away. Once the clock icon is gone select this entry and in the menu check Show Analytic and Debug Logs.
Now expand to the SCM provider located at
Application and Services Logs\Microsoft\Service Control Manager Performance Diagnostic Provider\Diagnostic.
or Microsoft-Windows-Services/Diagnostic
Enable the log, run repro, disable the log. After that you should see events from the SCM showing you your service state transitions.
The terminate parameters do not seems to be configurable. I can think of two ways fixing the issue
- Writing your own cluster resource DLL where you can implement your own policies. THis would be a place to start http://blogs.msdn.com/b/clustering/archive/2010/08/24/10053405.aspx.
- This option is assuming you cannot change the source code of the service to kill orphaned child processes on startup so you have to clenup using some other means. Create another service and make your service dependent on this new service. This new serice
must be much faster in responding do the SCM commands. On start of this service you using PSAPI enumirate all processes running on the machine and kill the orphaned child processes. You probably should be able to acheve something similar using GenScript resource
+ VB script that does the cleanup.
Regards, Vladimir Petter, Microsoft Corporation

Dynamic resizing in JDialog using setSize not working properly on solaris

can anyone help..
Dynamic resizing in JDialog using setSize is not working properly on solaris, its work fine on windows.
i have set Jdialog size to setSize(768,364),
when i dynamically resizing it to setSize(768,575); it doesn't get change but when i move dialog using mouse it gets refreshed.
this problem is only happening on solaris not on windows.

Hi,
It's only an approach but try a call of validate() or repaint() after re-setting the size of your dialog.
Cheers, Mathias

Configuration Manager Error: "Could not clean working directory"

I am currently attempting to install Adobe LiveCycle Reader Extensions ES on a Windows Server 2003 box with 2G of RAM. I am getting an error during the Configuration Manager phase of the installation. Screen capture available here: http://destructoray.com/albums/album01/Error.jpg The text of the error message is: Error [ACM-LCM-000-000] Failed on 'Executing merge scripts for ..\export\adobe-livecycle-native-jboss-x86_win32.ear' Could not clean working directory Here is the dump from the lcm.0.log: [2007-07-23 11:15:29,344], FINE , Thread-3, com.adobe.livecycle.lcm.feature.configureLC.MergeEars2, Cleaning working directory [2007-07-23 11:15:29,374], FINE , Thread-3, com.adobe.livecycle.lcm.feature.configureLC.MergeEars2, Deleting contents [323 files] from: ..\working\mergeTmp [2007-07-23 11:15:29,789], SEVERE , Thread-3, com.adobe.livecycle.lcm.feature.configureLC.MergeEars2, Could not clean working directory com.adobe.livecycle.lcm.core.LCMException[ALC-LCM-000-000]: Could not clean working directory at com.adobe.livecycle.lcm.feature.configureLC.MergeEars2.cleanDirectory(MergeEars2.java:442 ) at com.adobe.livecycle.lcm.feature.configureLC.MergeEars2.init(MergeEars2.java:304) at com.adobe.livecycle.lcm.feature.configureLC.MergeEars2.mergeEars(MergeEars2.java:217) at com.adobe.livecycle.lcm.feature.configureLC.MergeEars.mergeEars(MergeEars.java:227) at com.adobe.livecycle.lcm.feature.configureLC.MergeEars.mergeNativeEars(MergeEars.java:162) at com.adobe.livecycle.lcm.feature.configureLC.MergeEars.mergeAllEars(MergeEars.java:99) at com.adobe.livecycle.lcm.feature.expressTurnkey.ExpressTurnkeyTask$ActualTask.mergeEars(Ex pressTurnkeyTask.java:206) at com.adobe.livecycle.lcm.feature.expressTurnkey.ExpressTurnkeyTask$ActualTask.<init>(Expre ssTurnkeyTask.java:129) at com.adobe.livecycle.lcm.feature.expressTurnkey.ExpressTurnkeyTask$1.construct(ExpressTurn keyTask.java:103) at com.adobe.livecycle.lcm.core.tasks.SwingWorker$2.run(SwingWorker.java:114) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.IOException: Unable to delete file: ..\working\mergeTmp\base\xbean.jar at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1087) at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:811) at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:777) at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1079) at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:811) at com.adobe.livecycle.lcm.feature.configureLC.MergeEars2.cleanDirectory(MergeEars2.java:434 ) ... 10 more [2007-07-23 11:15:29,789], SEVERE , Thread-3, com.adobe.livecycle.lcm.feature.configureLC.MergeEars, Could not clean working directory com.adobe.livecycle.lcm.core.LCMException[ALC-LCM-000-000]: Could not clean working directory at com.adobe.livecycle.lcm.feature.configureLC.MergeEars2.cleanDirectory(MergeEars2.java:442 ) at com.adobe.livecycle.lcm.feature.configureLC.MergeEars2.init(MergeEars2.java:304) at com.adobe.livecycle.lcm.feature.configureLC.MergeEars2.mergeEars(MergeEars2.java:217) at com.adobe.livecycle.lcm.feature.configureLC.MergeEars.mergeEars(MergeEars.java:227) at com.adobe.livecycle.lcm.feature.configureLC.MergeEars.mergeNativeEars(MergeEars.java:162) at com.adobe.livecycle.lcm.feature.configureLC.MergeEars.mergeAllEars(MergeEars.java:99) at com.adobe.livecycle.lcm.feature.expressTurnkey.ExpressTurnkeyTask$ActualTask.mergeEars(Ex pressTurnkeyTask.java:206) at com.adobe.livecycle.lcm.feature.expressTurnkey.ExpressTurnkeyTask$ActualTask.<init>(Expre ssTurnkeyTask.java:129) at com.adobe.livecycle.lcm.feature.expressTurnkey.ExpressTurnkeyTask$1.construct(ExpressTurn keyTask.java:103) at com.adobe.livecycle.lcm.core.tasks.SwingWorker$2.run(SwingWorker.java:114) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.IOException: Unable to delete file: ..\working\mergeTmp\base\xbean.jar at org.apache.commons.io.FileUtils.for

The above error can occur if you have insufficient rights.
I faced the same error on Win 2k8 while running the installed using the Local System Admin account.
The Same was resolved by the following steps:
Solution:
Go to the AdobeLivecycleES3 root folder> ConfigurationManager>bin
Right click on teh configurationManager (BATCH File) and click on "Run as Administrator".

Something about "filesystems is NOT Clean"

I bought Thinkpad X1 recently. I install arch on it. Everything seems fine, except that "filesystems is NOT Clean" appears everytime when I start the laptop. I cannot find useful information from google. I just guess that it is a problem associated with unnormal shutdown procedure.
Any suggestions are welcome!
I use lvm2 to manage logical volumns.
$ sudo lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
home archgroup -wc-ao 255.12g
root archgroup -wc-ao 19.53g
swap archgroup -wc-ao 3.91g
var archgroup -wc-ao 19.53g
Here, "home" and "root" use the filesystem of "ext4" and "var" use "reisefs"。
The following is several informations from kernel.log which may be useful:
Aug 26 14:03:27 Igor-Home kernel: [ 100.249270] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Aug 26 14:03:38 Igor-Home kernel: [ 111.193303] wlan0: no IPv6 routers present
Aug 26 14:04:26 Igor-Home kernel: [ 158.867839] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 1
Aug 26 14:04:30 Igor-Home kernel: [ 162.530151] iwlagn 0000:03:00.0: iwlagn_tx_agg_start on ra = 84:c9:b2:49:55:9d tid = 0
Aug 26 14:04:48 Igor-Home kernel: [ 180.416263] iwlagn 0000:03:00.0: iwlagn_tx_agg_start on ra = 84:c9:b2:49:55:9d tid = 0
Aug 26 14:05:30 Igor-Home kernel: [ 222.693282] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 7
Aug 26 14:05:39 Igor-Home kernel: [ 231.802666] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 10
Aug 26 14:05:44 Igor-Home kernel: [ 236.781757] iwlagn 0000:03:00.0: iwlagn_tx_agg_start on ra = 84:c9:b2:49:55:9d tid = 0
Aug 26 14:06:10 Igor-Home kernel: [ 262.689224] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 4
Aug 26 14:07:04 Igor-Home kernel: [ 316.406812] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 1
Aug 26 14:07:56 Igor-Home kernel: [ 367.799895] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 14:08:41 Igor-Home kernel: [ 413.245620] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 14:10:59 Igor-Home kernel: [ 550.827063] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 14:16:37 Igor-Home kernel: [ 887.984073] iwlagn 0000:03:00.0: iwlagn_tx_agg_start on ra = 84:c9:b2:49:55:9d tid = 0
Aug 26 14:19:30 Igor-Home kernel: [ 1060.306074] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 14:22:48 Igor-Home kernel: [ 1257.936197] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 14:25:18 Igor-Home kernel: [ 1407.916947] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 14:31:48 Igor-Home kernel: [ 1796.713849] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 14:34:45 Igor-Home kernel: [ 1973.279503] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 14:35:53 Igor-Home kernel: [ 2041.481879] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 14:38:02 Igor-Home kernel: [ 2169.723218] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 1
Aug 26 14:45:54 Igor-Home kernel: [ 2641.575445] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 14:51:18 Igor-Home kernel: [ 2964.068080] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 2
Aug 26 15:05:37 Igor-Home kernel: [ 3820.925654] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 1
Aug 26 15:12:50 Igor-Home kernel: [ 4253.483857] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 15:15:57 Igor-Home kernel: [ 4440.025743] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 15:18:28 Igor-Home kernel: [ 4591.024983] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 15:23:11 Igor-Home kernel: [ 4873.182426] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 2
Aug 26 15:29:05 Igor-Home kernel: [ 5225.756546] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 15:31:49 Igor-Home kernel: [ 5390.096634] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 1
Aug 26 15:36:06 Igor-Home kernel: [ 5646.766321] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 2
Aug 26 15:37:17 Igor-Home kernel: [ 5717.409054] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 15:41:28 Igor-Home kernel: [ 5967.637480] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 15:44:11 Igor-Home kernel: [ 6130.459235] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Aug 26 15:47:00 Igor-Home kernel: [ 6298.522120] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
Last edited by igor1982 (2011-08-26 14:38:19)

I just guess that it is a problem associated with unnormal shutdown procedure.
Well... if my guess is correct, then there are other reasons you may see that message.
Most Linux filesystems have a maximum mount count and/or a maximum date interval configured inside them. When you exceed the maximum(s), they'll start complaining; trying to tell us humans that we should run fsck on the filesystem.
If you want to display the maximums on that ext4 filesystem, then run tune2fs -l /dev/sdXY with root authority, where "X" and "Y" match the filesystem in question. Look for Maximum mount count: and Check interval:. You can use that same tune2fs command to change those values, but read the man page first.
Since I've never run a reiser filesystem, I don't know how to display it's values, but if you look at the "-c" and "-m" parameters in the reiserfstune man page, it will show you how to change those maximums.
Now... since most filesystems don't like to be fsck'd while mounted (at least in read/write mode), I'd highly suggest that you become familiar with "The sixth field" portion of the fstab man page. If you set your fstab file correctly, it will "Do The Right Thing" when it comes time to scan your filesystems during a boot.
(Edited to add:)
Oh...forgot to mention... those kernel logs entries are from your Intel wireless adapter device driver, not your filesystems
Last edited by pigiron (2011-08-26 17:43:54)

Could not clean working directory during the Livecycle ES 8.2.1 installation

Hi,
while using Adobe Livecycle Configuration Manager, I am getting the following error. How could I get around this problem?
Failed on 'Executing merge scripts for adobe-livecycle-native-weblogic-x86_win32.ear'
Could not clean working directory
reg,
Raj

I'm posting my experiences with this error because it can hopefully help other people. I was getting the same error during the Configure LiveCycle ES (1 of 3) screen after clicking the Configure button. It would fail around 75% with a prompt saying error code ALC-LCM-000-000 and could not clean working directory. The progress log would indicate the failure at executing merge scripts for adobe-livecycle-native-weblogic-x86_win32.ear. I was installing LC ES 8.2.1 SP3 + QF 3.19 with the Forms and Output components on a Windows 2003 platform.
Rename working dir (LC support suggestion)
Rename c:\adobe\livecycle8.2\configurationManager\working to be like working.old. Re-run ConfigurationManager (CM). Didn't help since I saw the same error message.
Clicked Configure again on and it went 100% without any problems. The rest of the install went just fine.
Reinstall Adobe LC ES 8.2
I was getting the same type of error on another box, but clicking Configure wasn't getting past 75% again.
Reboot of the box didn't help on the next attempt.
Reinstall LC ES 8.2 worked
Used the Add/Remove programs to remove Adobe LC ES 8.2
Reinstalled the software with SP3 + QF 3.19.
Ran CM again and I was able to get past this error.

Boot up - Error Message: "File System not clean"

<blockquote>Locked by Moderator as a duplicate/re-post.
Please continue the discussion in this thread: [tiki-view_forum_thread.php?locale=en-US&comments_parentId=667528&forumId=1]
Thanks - c</blockquote>
== Issue
==
I have another kind of problem with Firefox
== Description
==
At start up displays error message: File System not Clean"
== start up computer
==
== Troubleshooting information
==
WebOfTrust, AdBlock Plus 1.2, Ubuntu Firefox Modifications 0.7, Firefox Universal Uploader (fireuploader) 0.4.1, Foxytunes 4.0.6
== Firefox version
==
3.0.19
== Operating system
==
Linux
== User Agent
==
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.19) Gecko/2010040116 Ubuntu/9.04 (jaunty) Firefox/3.0.19 GTB7.0
== Plugins installed
==
*-The default plugin handles plugin data for mimetypes and extensions that are not specified and facilitates downloading of new plugins.
*The demo print plugin for unix.
*Shockwave Flash 10.0 r45
*DivX Web Player version 1.4.0.233
*The Totem 2.26.1 plugin handles video and audio streams.

http://ubuntuforums.org/

I can not update because it says the net connection was not clean properly, How to do this to clean properly??

There was a notification to update Firefox. I did but later a notification says "The update was not successful because there is a net connection that was not clean properly and it happened as well everytime I closed Firefox. What do I have to do to clean this properly?
Thank you

Please help!!!! everytime I update I got this notification always,
''''''"The operation can not be completed because of an internal failure. A secure network communication has not been cleaned up correctly."''''''
How can I solve this problem?
Thank you?

Not-cleaned-up-DB-sessions Forms6i/IAS

Environment: True Unix 64, IAS 1.0.2.1, 8.1.6
Since migrated to Forms 6i /IAS 1.0.2.1 there are in some cases not cleaned-up DB session on the db which is accessed by an Forms6i appl. Note: not the Webserver has this not-closed-sessions but the Oracle-database on a remote UNIX server (8.0.5). There I see these sessions with cursor-information:
ALTER SESSION SET NLS_LANGUAGE='AMERICAN' NLS_TERRITORY='AMERICA' NLS_CURRENCY='$' NLS_ISO_CURRENCY='AMERICA' NLS_NUMERIC_CHARACTERS='.,' NLS_CALENDAR='GREGORIAN' NLS_DATE_FORMAT='DD-MON-RR' NLS_DATE_LANGUAGE='AMERICAN' NLS_SORT='BINARY'
Is there any parameter which helps me to kill these needless sessions automatically ? And, what action makes Oracle to behave to keep these sessions ?
Thanx a lot.

Please reread your post with great care.
Do you see a platform and operating system?
Do you see a product name and full version number?
Do you see a description of which commands were executed?
Good. Because I don't either.
Post a full and complete description of the environment so we can try to replicate it.

I can not clean status yahoo, who help me

i hope some one help me

what do you mean "I can not clean status yahoo"? That doesn't make sense in English.

Apple mail not cleaning up POP3 server?

I use Apple Mail (in POP3 mode) and Spamsieve, and it appearsthat it never removes junk mail and/or moved mail from my mail server (a Unix hosted domain). I have "delete permanently on move from inbox" and "delete permanently when deleted in Mail" set properly.
How do I know? If I read/move/delete all mail in my inbox, and then manually delete all the mail in the junk mail folder, then use something like Thunderbird in IMAP mode, I found that my /var/mail/sparker was 95+Mb full of garbage from the previous year (or much more)
Interestingly, if I have message that lands in my inbox (no rules processing) and I manually delete them, they get removed properly from the /var/mail/sparker file. If Rules or SpamSieve move them, they never get deleted properly.
So... For those of you with external hosts for your mail, go check your /var/mail/<userid> file. I'd bet they're huge.....
I've got to the point where I read and process all my mail using AppleMail, then quit, launch thunderbird, and delete everything manually. Seems ridiculous, but that's what I'm doing now.
I like SpamSieve enough (with 99.7% accuracy) that I'd prefer not to switch to Thunderbird exclusively. But if I have to keep processing mail using BOTH tools, then I'm going to have to switch.
Steve

I have [...] "delete permanently when deleted in
Mail"
set properly.
Considering that no such setting exists in Mail, I
find this hard to believe.
Wow... Sorry I upset you. I was asking this question from another machine, and hoped people would be intuit that I really meant "Remove copy from server after retrieving a message". I was obviously wrong that you could intuit that I just got the exact string setting incorrectly.
I found that my /var/mail/sparker was 95+Mb
full of garbage from the previous year (or much
more)
What does /var/mail have to do with Apple
Mail?
On my web host that hosts my domain, all their mail pools in /var/mail/<user> until I hook up my Powerbook and download it as POP3 mail. If I don't go get it, it accumulates in this file. It's standard Unix type mail.
Interestingly, if I have message that lands in my
inbox
(no rules processing) and I manually delete them,
they
get removed properly from the /var/mail/sparker
file.
That's interesting, indeed. But even more interesting
is that I manage 8 POP accounts in Mail (5 different
"external hosts"), and my /var/mail
directory is always empty. I don't even have a
/var/mail/username file...
I'm sorry to hear that. I do have a /var/mail/<username> where all my mail accumulates. It's on a FreeBSD server. It does exist, as does a mail file for everybody else on that host.
So... For those of you with external hosts for
your
mail, go check your /var/mail/<userid> file. I'd
bet
they're huge.....
I bet they aren't. Actually, I bet no such file
exists at all in most cases...
I can generate a listing here, but that wouldn't solve this problem.
I'm sorry that I upset you by asking this question. I've used many email clients on Mac, Windows, and quite as few flavors of Unix, and this mail client is the first time I've encountered the lack of clean up of the POP3 mailbox.
However, in a post earlier this evening, I mentioned that I changed the setting for the "Remove copy from server after retrieving a message:" from "Right Away" to "When moved from Inbox" (and yes, those are the exact text strings in the Accounts -> Advanced Preference pane), and the messages are now removed correctly from /var/mail/<user> on my host.
So, something that the rules processing interacting with the "Right Away" setting is not cleaning up properly. Changing it to "When moved from Inbox" is cleaning up messages that the Rules move to other folders (including messages that Spamsieve moves to other folders).
Steve

Activities not cleaning text log when ending contact

Hi:
I have a problem, we are using sap crm 5.0 with ic web client, when the user opens, or create a new activitie it shows the text log in the followupviewset, but when it hits the "end contact" button it does not clean the view in the text log, how can i clean that text log so it does not saves those text's in other activities.
Thanks & regards

I just figured it out- first I tried resetting, but to no avail. Then I turned off my iCloud sync I'm settings (under contacts, of course) and voila! All to those missing contacts appeared! So moral of the story- iCloud can cause a few kinks in certain situations.
Thanks for the reply!

Iphone 4s imei is not clean

can you tell me when you say my phone imei is not clean what does it mean

You are being replied to.
So your uncle bought you the iphone as a gift. To use in Africa, do you have an Apple store where you live? if you do just go there and have them work on it. The meid of the phone maybe screwed up, or you entered the number wrong.
Did your uncle purchase from a Verizon store or an Apple store? The phone maybe locked to only verizon so that also could be the problem. There is no verizon store in Africa so how would you use verizons service there? Call verizon at the global customer service number and ask. If the phone is going to be used in Africa it has to be unlocked to use there, and a verizon cell is cdma and not gsm so its doubtful it will work at all.
Your uncle should have purchased the phone in Africa to use in Africa.
And you being proud has nothing to do with anything.
http://www.verizonwireless.com/wcms/global/support.html

GC not cleaning up in solaris

Similar Messages

Maybe you are looking for