Thread deadlock in ClassMetaData

Within a single JVM we are running 4-5 Threads that each create and use
their own PM. The multiThreaded option is set to true, even though the
threads don't share any common data or variables.
We have an intermittent problem where all threads appear to hang from which
they never recover. While it doesn't always occur, it seems to happen more
often when the application run and the threads are first started. When first
started they are all trying to perform queries which ends in the deadlock.
Could you please look into this and suggest a work around that doesn't
invlove upgrading to 3.1.
Regards
Nathan
OS Win 2k3 and XP
Kodo 2.5.8
See attached for Stacktrace and properties
begin 666 JVM Full Hang Thread States.txt
M,C P-"TP-2TQ." Q-#HS,3HS-2PQ-3$@1$5"54<@;6%I;B @(" @(" @(" @
M(" @(" M($-O;G1R;VQL97(N<G5N*"D@+2!E;G1E<@T*,C P-"TP-2TQ." Q
M-#HS,3HS-2PR-S8@1$5"54<@;6%I;B @(" @(" @(" @(" @(" M(%!R;W!E
M<G1I97,@9FEL92 B:V]D;RYP<F]P97)T:65S(B!H87,@8F5E;B!R96%D(&%N
M9"!C86-H960@9F]R(&-U<G)E;G0@2E9-#0HR,# T+3 U+3$X(#$T.C,Q.C,U
M+#(W-B!$14)51R!M86EN(" @(" @(" @(" @(" @("T@4')O<&5R=&EE<R!F
M:6QE(")#;VYF:6=U<F%T:6]N4WES=&5M+G!R;W!E<G1I97,B(&AA<R!B965N
M(')E860@86YD(&-A8VAE9"!F;W(@8W5R<F5N="!*5DT-"C(P,#0M,#4M,3@@
M,30Z,S$Z,S4L,C<V($E.1D\@(&UA:6X@(" @(" @(" @(" @(" @+2!097)S
M:7-T96YC94UA;F%G97)&86-T;W)I97,@=VEL;"!B92!C<F5A=&5D('5S:6YG
M('1H92!097)S:7-T)W,@8VQA<W-L;V%D97(N#0HR,# T+3 U+3$X(#$T.C,Q
M.C,W+#DQ-R!$14)51R!M86EN(" @(" @(" @(" @(" @("T@3F5W(%!E<G-I
M<W0@3V)T86EN960@8V]M+G-O;&%R;65T<FEC+FMO9&\N<G5N=&EM92Y097)S
M:7-T96YC94UA;F%G97));7!L0&%D8C%D- T*,C P-"TP-2TQ." Q-#HS,3HT
M,"PP-3<@1$5"54<@;6%I;B @(" @(" @(" @(" @(" M($)E86Y#;VYT<F]L
M;&5R+G!R;V-E<W,H*2 M($EN<W1A;G1I871I;F<@5V]R:V5R5&AR96%D.C(P
M,@T*,C P-"TP-2TQ." Q-#HS,3HT,"PP-S,@1$5"54<@;6%I;B @(" @(" @
M(" @(" @(" M($YE=R!097)S:7-T($]B=&%I;F5D(&-O;2YS;VQA<FUE=')I
M8RYK;V1O+G)U;G1I;64N4&5R<VES=&5N8V5-86YA9V5R26UP;$ Q-CDQ-V5E
M#0HR,# T+3 U+3$X(#$T.C,Q.C0P+#$S-2!$14)51R!M86EN(" @(" @(" @
M(" @(" @("T@0F5A;D-O;G1R;VQL97(N<')O8V5S<R@I("T@26YS=&%N=&EA
M=&EN9R!7;W)K97)4:')E860Z,C S#0HR,# T+3 U+3$X(#$T.C,Q.C0P+#$S
M-2!$14)51R!M86EN(" @(" @(" @(" @(" @("T@3F5W(%!E<G-I<W0@3V)T
M86EN960@8V]M+G-O;&%R;65T<FEC+FMO9&\N<G5N=&EM92Y097)S:7-T96YC
M94UA;F%G97));7!L0#$T.3$P-6(-"C(P,#0M,#4M,3@@,30Z,S$Z-# L,C8P
M($1%0E5'(&UA:6X@(" @(" @(" @(" @(" @+2!"96%N0V]N=')O;&QE<BYP
M<F]C97-S*"D@+2!);G-T86YT:6%T:6YG(%=O<FME<E1H<F5A9#HR,#$-"C(P
M,#0M,#4M,3@@,30Z,S$Z-# L,C<V($1%0E5'(&UA:6X@(" @(" @(" @(" @
M(" @+2!.97<@4&5R<VES="!/8G1A:6YE9"!C;VTN<V]L87)M971R:6,N:V]D
M;RYR=6YT:6UE+E!E<G-I<W1E;F-E36%N86=E<DEM<&Q 8V%F-F,Q#0HR,# T
M+3 U+3$X(#$T.C,Q.C0P+#4R-B!$14)51R!M86EN(" @(" @(" @(" @(" @
M("T@0F5A;D-O;G1R;VQL97(N<')O8V5S<R@I("T@26YS=&%N=&EA=&EN9R!7
M;W)K97)4:')E860Z,C T#0HR,# T+3 U+3$X(#$T.C,Q.C0P+#4R-B!$14)5
M1R!M86EN(" @(" @(" @(" @(" @("T@3F5W(%!E<G-I<W0@3V)T86EN960@
M8V]M+G-O;&%R;65T<FEC+FMO9&\N<G5N=&EM92Y097)S:7-T96YC94UA;F%G
M97));7!L0#%E8V9E,#<-"C(P,#0M,#4M,3@@,30Z,S$Z-# L-C@R($1%0E5'
M($5V96YT0F5A;CHR,#(@(" @(" @+2!;4W1A<G1=(&-O;2YM86QL97-O;G,N
M;&%W;6%N+F%P+F5X8VAA;F=E+E!R;V-E<W-&;VQD97(-"C(P,#0M,#4M,3@@
M,30Z,S$Z-# L.#<P($1%0E5'($5V96YT0F5A;CHR,#,@(" @(" @+2!;4W1A
M<G1=(&-O;2YM86QL97-O;G,N;&%W;6%N+F%P+FEM86YA9V4N4')O8V5S<U!R
M;VIE8W0-"C(P,#0M,#4M,3@@,30Z,S$Z-#0L-3<S($1%0E5'($5V96YT0F5A
M;CHR,#(@(" @(" @+2!.97<@4&5R<VES="!/8G1A:6YE9"!C;VTN<V]L87)M
M971R:6,N:V]D;RYR=6YT:6UE+E!E<G-I<W1E;F-E36%N86=E<DEM<&Q 9#8Q
M865F#0HR,# T+3 U+3$X(#$T.C,Q.C0T+#8V-R!$14)51R!%=F5N=$)E86XZ
M,C R(" @(" @("T@3&]C:R!O8G1A:6YE9"!I;B P;7,@(&]N(")C;VTN;6%L
M;&5S;VYS+FQA=VUA;BYA<"YE>&-H86YG92Y%>&-H86YG949O;&1E<B(@*R B
M-S0W,C(B#0HR,# T+3 U+3$X(#$T.C,Q.C0T+#8V-R!$14)51R!%=F5N=$)E
M86XZ,C R(" @(" @("T@4&5R<VES="YS:'5T9&]W;B@I("T@<&T@8VQO<V5D
M(#H@8V]M+G-O;&%R;65T<FEC+FMO9&\N<G5N=&EM92Y097)S:7-T96YC94UA
M;F%G97));7!L0&0V,6%E9@T*,C P-"TP-2TQ." Q-#HS,3HT-"PY.34@1$5"
M54<@179E;G1"96%N.C(P,R @(" @(" M($YE=R!097)S:7-T($]B=&%I;F5D
M(&-O;2YS;VQA<FUE=')I8RYK;V1O+G)U;G1I;64N4&5R<VES=&5N8V5-86YA
M9V5R26UP;$ R9&$U838-"C(P,#0M,#4M,3@@,30Z,S$Z-#4L,#$P($1%0E5'
M($5V96YT0F5A;CHR,#(@(" @(" @+2!.97<@4&5R<VES="!/8G1A:6YE9"!C
M;VTN<V]L87)M971R:6,N:V]D;RYR=6YT:6UE+E!E<G-I<W1E;F-E36%N86=E
M<DEM<&Q 830Q-6$S#0HR,# T+3 U+3$X(#$T.C,Q.C0U+# T,B!$14)51R!%
M=F5N=$)E86XZ,C S(" @(" @("T@3&]C:R!O8G1A:6YE9"!I;B P;7,@(&]N
M(")C;VTN;6%L;&5S;VYS+FQA=VUA;BYA<"YI;6%N86=E+DEM86YA9V50<F]J
M96-T4F]L92(@*R B-S0X,3$B#0HR,# T+3 U+3$X(#$T.C,Q.C0U+# U-R!$
M14)51R!%=F5N=$)E86XZ,C S(" @(" @("T@4&5R<VES="YS:'5T9&]W;B@I
M("T@<&T@8VQO<V5D(#H@8V]M+G-O;&%R;65T<FEC+FMO9&\N<G5N=&EM92Y0
M97)S:7-T96YC94UA;F%G97));7!L0#)D835A-@T*,C P-"TP-2TQ." Q-#HS
M,3HT-2PP-S,@1$5"54<@179E;G1"96%N.C(P,R @(" @(" M($EM86Y#;VYN
M96-T:6]N+F%D;6EN3&]G:6X@+2!E;G1E<@T*,C P-"TP-2TQ." Q-#HS,3HT
M-2PP.#D@1$5"54<@179E;G1"96%N.C(P,B @(" @(" M($QO8VL@;V)T86EN
M960@:6X@,&US("!O;B B8V]M+FUA;&QE<V]N<RYL87=M86XN86$N9F]L9&5R
M+D9O;&1E<B(@*R B-S0W,C(B#0HR,# T+3 U+3$X(#$T.C,Q.C0U+#$P-"!$
M14)51R!%=F5N=$)E86XZ,C R(" @(" @("T@4&5R<VES="YS:'5T9&]W;B@I
M("T@<&T@8VQO<V5D(#H@8V]M+G-O;&%R;65T<FEC+FMO9&\N<G5N=&EM92Y0
M97)S:7-T96YC94UA;F%G97));7!L0&$T,35A,PT*,C P-"TP-2TQ." Q-#HS
M,3HT-2PX,SD@1$5"54<@179E;G1"96%N.C(P,B @(" @(" M($%B;W5T('1O
M(&=E="!W<F%P<&5R+BXN#0HR,# T+3 U+3$X(#$T.C,Q.C0U+#@S.2!$14)5
M1R!%=F5N=$)E86XZ,C R(" @(" @("T@9V5T3F5W5W)A<'!E<B@I("T@96YT
M97(-"C(P,#0M,#4M,3@@,30Z,S$Z-#<L,#4W($1%0E5'($5V96YT0F5A;CHR
M,#(@(" @(" @+2!G971.97=7<F%P<&5R*"D@+2!E>&ET#0HR,# T+3 U+3$X
M(#$T.C,Q.C0W+# U-R!$14)51R!%=F5N=$)E86XZ,C R(" @(" @("T@9V]T
M('=R87!P97(-"C(P,#0M,#4M,3@@,30Z,S$Z-#<L,#4W($1%0E5'($5V96YT
M0F5A;CHR,#(@(" @(" @+2!G971397-S:6]N1G)O;5=R87!P97(H*2 M($=E
M='1I;F<@0V1O4V5S<VEO;@T*,C P-"TP-2TQ." Q-#HS,3HT-RPU-3<@1$5"
M54<@179E;G1"96%N.C(P,R @(" @(" M($EM86Y#;VYN96-T:6]N+F%D;6EN
M3&]G:6X@+2!E>&ET#0HR,# T+3 U+3$X(#$T.C,Q.C0X+#@P-R!$14)51R!%
M=F5N=$)E86XZ,C S(" @(" @("T@0D%#4D]#2T4@861D960@=&\@9W)O=7 @
M;&%W;6%N-S0Y-3D-"C(P,#0M,#4M,3@@,30Z,S$Z-#DL,C(Y($1%0E5'($5V
M96YT0F5A;CHR,#,@(" @(" @+2!*4TU)5$@@861D960@=&\@9W)O=7 @;&%W
M;6%N-S0Y-3D-"C(P,#0M,#4M,3@@,30Z,S$Z-#DL,S(S($1%0E5'($5V96YT
M0F5A;CHR,#,@(" @(" @+2!.97<@4&5R<VES="!/8G1A:6YE9"!C;VTN<V]L
M87)M971R:6,N:V]D;RYR=6YT:6UE+E!E<G-I<W1E;F-E36%N86=E<DEM<&Q
M-S5F-6(W#0HR,# T+3 U+3$X(#$T.C,Q.C0Y+#0Q-R!$14)51R!%=F5N=$)E
M86XZ,C S(" @(" @("T@3&]C:R!O8G1A:6YE9"!I;B P;7,@(&]N(")C;VTN
M;6%L;&5S;VYS+FQA=VUA;BYA<"YI;6%N86=E+DEM86YA9V50<F]J96-T4F]L
M92(@*R B-S0X,3 B#0HR,# T+3 U+3$X(#$T.C,Q.C0Y+#0Q-R!$14)51R!%
M=F5N=$)E86XZ,C S(" @(" @("T@4&5R<VES="YS:'5T9&]W;B@I("T@<&T@
M8VQO<V5D(#H@8V]M+G-O;&%R;65T<FEC+FMO9&\N<G5N=&EM92Y097)S:7-T
M96YC94UA;F%G97));7!L0#<U9C5B-PT*,C P-"TP-2TQ." Q-#HS,3HT.2PW
M-#4@1$5"54<@179E;G1"96%N.C(P,R @(" @(" M($)!0U)/0TM%(&%D9&5D
M('1O(&=R;W5P(&QA=VUA;C<T.38R#0HR,# T+3 U+3$X(#$T.C,Q.C0Y+#DQ
M-R!$14)51R!%=F5N=$)E86XZ,C S(" @(" @("T@2E--251((&%D9&5D('1O
M(&=R;W5P(&QA=VUA;C<T.38R#0I&=6QL('1H<F5A9"!D=6UP($IA=F$@2&]T
M4W!O="A432D@0VQI96YT(%9-("@Q+C0N,E\P-"UB,#4@;6EX960@;6]D92DZ
M#0H-"B)01%5-86YA9V5R26UP;"UO<&5N0V]N;F5C=&EO;B(@9&%E;6]N('!R
M:6\]-2!T:60],'@P,F1D-3$X."!N:60],'AA96,@<G5N;F%B;&4@6S-D868P
M,# N+C-D869D.3!=#0H@(" @(" @(&%T(&IA=F$N;F5T+E-O8VME=$EN<'5T
M4W1R96%M+G-O8VME=%)E860P*$YA=&EV92!-971H;V0I#0H@(" @(" @(&%T
M(&IA=F$N;F5T+E-O8VME=$EN<'5T4W1R96%M+G)E860H56YK;F]W;B!3;W5R
M8V4I#0H@(" @(" @(&%T(&IA=F$N:6\N1&%T84EN<'5T4W1R96%M+G)E861&
M=6QL>2A5;FMN;W=N(%-O=7)C92D-"B @(" @(" @870@8V]M+FQI;F%R+FII
M;G1E9W)A+E!$54UA;F%G97));7!L+G)U;BA5;FMN;W=N(%-O=7)C92D-"B @
M(" @(" @870@:F%V82YL86YG+E1H<F5A9"YR=6XH56YK;F]W;B!3;W5R8V4I
M#0H-"B)01%5-86YA9V5R26UP;"UO<&5N0V]N;F5C=&EO;B(@9&%E;6]N('!R
M:6\]-2!T:60],'@P,F1D-#@R."!N:60],'@Y,#0@<G5N;F%B;&4@6S-D-F8P
M,# N+C-D-F9D.3!=#0H@(" @(" @(&%T(&IA=F$N;F5T+E-O8VME=$EN<'5T
M4W1R96%M+G-O8VME=%)E860P*$YA=&EV92!-971H;V0I#0H@(" @(" @(&%T
M(&IA=F$N;F5T+E-O8VME=$EN<'5T4W1R96%M+G)E860H56YK;F]W;B!3;W5R
M8V4I#0H@(" @(" @(&%T(&IA=F$N:6\N1&%T84EN<'5T4W1R96%M+G)E861&
M=6QL>2A5;FMN;W=N(%-O=7)C92D-"B @(" @(" @870@8V]M+FQI;F%R+FII
M;G1E9W)A+E!$54UA;F%G97));7!L+G)U;BA5;FMN;W=N(%-O=7)C92D-"B @
M(" @(" @870@:F%V82YL86YG+E1H<F5A9"YR=6XH56YK;F]W;B!3;W5R8V4I
M#0H-"B)01%5-86YA9V5R26UP;"UO<&5N0V]N;F5C=&EO;B(@9&%E;6]N('!R
M:6\]-2!T:60],'@P,F1D-#4Y."!N:60],'AF-S0@<G5N;F%B;&4@6S-D,F8P
M,# N+C-D,F9D.3!=#0H@(" @(" @(&%T(&IA=F$N;F5T+E-O8VME=$EN<'5T
M4W1R96%M+G-O8VME=%)E860P*$YA=&EV92!-971H;V0I#0H@(" @(" @(&%T
M(&IA=F$N;F5T+E-O8VME=$EN<'5T4W1R96%M+G)E860H56YK;F]W;B!3;W5R
M8V4I#0H@(" @(" @(&%T(&IA=F$N:6\N1&%T84EN<'5T4W1R96%M+G)E861&
M=6QL>2A5;FMN;W=N(%-O=7)C92D-"B @(" @(" @870@8V]M+FQI;F%R+FII
M;G1E9W)A+E!$54UA;F%G97));7!L+G)U;BA5;FMN;W=N(%-O=7)C92D-"B @
M(" @(" @870@:F%V82YL86YG+E1H<F5A9"YR=6XH56YK;F]W;B!3;W5R8V4I
M#0H-"B)*+4EN=&5G<F$@:6YT97)N86P@=&EM97(@=&AR96%D(&9O<B!*:6YT
M96=R82!296U/6$E$4F5S;VQV97(@9F]R.B!.970]>WL@,'@W+"!S=%!%=V]R
M:S Q?2P@>R P>#<L(#$W,BXQ."XR,BXV.'U](%-E8SU[>R P>#DL(#!X9F9F
M9BP@?2P@>R P>#$P+" P>&9F9@T*9BP@?2P@>R P>&$L(#!X9F9F9BP@?2P@
M>R P>&4L(#!X9F9F9BP@?2P@>R P>#$Q+" P>&9F9F8L('TL('L@,'@Q,BP@
M,'AF9F9F+"!]?2(@9&%E;6]N('!R:6\]-2!T:60],'@P,F1B8CDQ,"!N:60]
M,'AB,#@@=V%I=&EN9R!O;B!C;VYD:71I;VX@6S-C968P,# N#0HN,V-E9F0Y
M,%T-"B @(" @(" @870@:F%V82YL86YG+E1H<F5A9"YS;&5E<"A.871I=F4@
M365T:&]D*0T*(" @(" @("!A="!C;VTN;&EN87(N:FEN=&5G<F$N8VDN<G5N
M*%5N:VYO=VX@4V]U<F-E*0T*#0HB4$1536%N86=E<DEM<&PM;W!E;D-O;FYE
M8W1I;VXB(&1A96UO;B!P<FEO/34@=&ED/3!X,#)D8C$U8C @;FED/3!X,38T
M(')U;FYA8FQE(%LS8V%F,# P+BXS8V%F9#DP70T*(" @(" @("!A="!J879A
M+FYE="Y3;V-K971);G!U=%-T<F5A;2YS;V-K971296%D,"A.871I=F4@365T
M:&]D*0T*(" @(" @("!A="!J879A+FYE="Y3;V-K971);G!U=%-T<F5A;2YR
M96%D*%5N:VYO=VX@4V]U<F-E*0T*(" @(" @("!A="!J879A+FEO+D1A=&%)
M;G!U=%-T<F5A;2YR96%D1G5L;'DH56YK;F]W;B!3;W5R8V4I#0H@(" @(" @
M(&%T(&-O;2YL:6YA<BYJ:6YT96=R82Y01%5-86YA9V5R26UP;"YR=6XH56YK
M;F]W;B!3;W5R8V4I#0H@(" @(" @(&%T(&IA=F$N;&%N9RY4:')E860N<G5N
M*%5N:VYO=VX@4V]U<F-E*0T*#0HB4$1536%N86=E<DEM<&PM;W!E;D-O;FYE
M8W1I;VXB(&1A96UO;B!P<FEO/34@=&ED/3!X,#)D8C8Y,S@@;FED/3!X8V$T
M(')U;FYA8FQE(%LS8S9F,# P+BXS8S9F9#DP70T*(" @(" @("!A="!J879A
M+FYE="Y3;V-K971);G!U=%-T<F5A;2YS;V-K971296%D,"A.871I=F4@365T
M:&]D*0T*(" @(" @("!A="!J879A+FYE="Y3;V-K971);G!U=%-T<F5A;2YR
M96%D*%5N:VYO=VX@4V]U<F-E*0T*(" @(" @("!A="!J879A+FEO+D1A=&%)
M;G!U=%-T<F5A;2YR96%D1G5L;'DH56YK;F]W;B!3;W5R8V4I#0H@(" @(" @
M(&%T(&-O;2YL:6YA<BYJ:6YT96=R82Y01%5-86YA9V5R26UP;"YR=6XH56YK
M;F]W;B!3;W5R8V4I#0H@(" @(" @(&%T(&IA=F$N;&%N9RY4:')E860N<G5N
M*%5N:VYO=VX@4V]U<F-E*0T*#0HB2BU);G1E9W)A(&EN=&5R;F%L('1I;65R
M('1H<F5A9"!F;W(@2FEN=&5G<F$@4F5M3UA)1%)E<V]L=F5R(&9O<CH@3F5T
M/7M[(#!X-RP@,3(W+C N,"XQ6S$S-5U]?2!396,]>WTB(&1A96UO;B!P<FEO
M/34@=&ED/3!X,#)D-C@R,S @;FED/3!X-C$X('=A:71I;F<-"B!O;B!C;VYD
M:71I;VX@6S-C,F8P,# N+C-C,F9D.3!=#0H@(" @(" @(&%T(&IA=F$N;&%N
M9RY4:')E860N<VQE97 H3F%T:79E($UE=&AO9"D-"B @(" @(" @870@8V]M
M+FQI;F%R+FII;G1E9W)A+F-I+G)U;BA5;FMN;W=N(%-O=7)C92D-"@T*(D5V
M96YT0F5A;CHR,#0B(&1A96UO;B!P<FEO/34@=&ED/3!X,#)D,F4P,#@@;FED
M/3!X-65C('=A:71I;F<@9F]R(&UO;FET;W(@96YT<GD@6S-B968P,# N+C-B
M969D.3!=#0H@(" @(" @(&%T(&-O;2YS;VQA<FUE=')I8RYK;V1O+FUE=&$N
M0VQA<W--971A1&%T82YG971);G-T86YC92A#;&%S<TUE=&%$871A+FIA=F$Z
M,3@U*0T*(" @(" @(" M('=A:71I;F<@=&\@;&]C:R \,'@Q-#(T.&9F,#X@
M*&$@:F%V82YL86YG+D-L87-S*0T*(" @(" @("!A="!C;VTN<V]L87)M971R
M:6,N:V]D;RYQ=65R>2Y1=65R>4EM<&PD1&%T87-T;W)E475E<GE%>&5C=71O
M<BX\:6YI=#XH475E<GE);7!L+FIA=F$Z,34S-"D-"B @(" @(" @870@8V]M
M+G-O;&%R;65T<FEC+FMO9&\N<75E<GDN475E<GE);7!L)%%U97)Y17AE8W5T
M:6]N36%N86=E<BYG9711=65R>45X96-U=&]R*%%U97)Y26UP;"YJ879A.C$S
M-C@I#0H@(" @(" @(&%T(&-O;2YS;VQA<FUE=')I8RYK;V1O+G%U97)Y+E%U
M97)Y26UP;"YI;G1E<FYA;$-O;7!I;&4H475E<GE);7!L+FIA=F$Z-#<T*0T*
M(" @(" @("!A="!C;VTN<V]L87)M971R:6,N:V]D;RYQ=65R>2Y1=65R>4EM
M<&PN97AE8W5T95%U97)Y5VET:$UA<"A1=65R>4EM<&PN:F%V83HV.#(I#0H@
M(" @(" @(&%T(&-O;2YS;VQA<FUE=')I8RYK;V1O+G%U97)Y+E%U97)Y26UP
M;"YE>&5C=71E5VET:$UA<"A1=65R>4EM<&PN:F%V83HU-#4I#0H@(" @(" @
M(&%T(&-O;2YS;VQA<FUE=')I8RYK;V1O+G%U97)Y+E%U97)Y26UP;"YE>&5C
M=71E5VET:$%R<F%Y*%%U97)Y26UP;"YJ879A.C4S,2D-"B @(" @(" @870@
M8V]M+G-O;&%R;65T<FEC+FMO9&\N<75E<GDN475E<GE);7!L+F5X96-U=&4H
M475E<GE);7!L+FIA=F$Z-3 Q*0T*(" @(" @("!A="!C;VTN;6%L;&5S;VYS
M+FQA=VUA;BYT82YS:&%R960N0D]1=65R>2YE>&5C=71E*$)/475E<GDN:F%V
M83HQ,S4I#0H@(" @(" @(&%T(&-O;2YM86QL97-O;G,N;&%W;6%N+G1A+F5V
M96YT+D5V96YT5&AR96%D+F=E=$YE>'1%=F5N="A%=F5N=$-O;G1R;VQL97(N
M:F%V83HR-C@I#0H@(" @(" @(&%T(&-O;2YM86QL97-O;G,N;&%W;6%N+G1A
M+F5V96YT+D5V96YT5&AR96%D+G!R;V-E<W,H179E;G1#;VYT<F]L;&5R+FIA
M=F$Z.3<I#0H@(" @(" @(&%T(&-O;2YM86QL97-O;G,N;&%W;6%N+G1A+F5V
M96YT+E=O<FME<E1H<F5A9"YR=6XH5V]R:V5R5&AR96%D+FIA=F$Z-S$I#0H-
M"B)%=F5N=$)E86XZ,C Q(B!D865M;VX@<')I;STU('1I9#TP># S,#4T-#8X
M(&YI9#TP>&(T-"!I;B!/8FIE8W0N=V%I="@I(%LS8CEF,# P+BXS8CEF9#DP
M70T*(" @(" @("!A="!J879A+FQA;F<N0VQA<W,N9F]R3F%M93 H3F%T:79E
M($UE=&AO9"D-"B @(" @(" @870@:F%V82YL86YG+D-L87-S+F9O<DYA;64H
M56YK;F]W;B!3;W5R8V4I#0H@(" @(" @(&%T(&-O;2YS;VQA<FUE=')I8RYK
M;V1O+FUE=&$N0VQA<W--971A1&%T82YN97=);G-T86YC92A#;&%S<TUE=&%$
M871A+FIA=F$Z,CDU*0T*(" @(" @("!A="!C;VTN<V]L87)M971R:6,N:V]D
M;RYM971A+D-L87-S365T841A=&$N9V5T26YS=&%N8V4H0VQA<W--971A1&%T
M82YJ879A.C(S.2D-"B @(" @(" @+2!L;V-K960@/#!X,30R-#AF9C ^("AA
M(&IA=F$N;&%N9RY#;&%S<RD-"B @(" @(" @870@8V]M+G-O;&%R;65T<FEC
M+FMO9&\N;65T82Y#;&%S<TUE=&%$871A+F=E=$EN<W1A;F-E*$-L87-S365T
M841A=&$N:F%V83HQ.#4I#0H@(" @(" @("T@;&]C:V5D(#PP>#$T,C0X9F8P
M/B H82!J879A+FQA;F<N0VQA<W,I#0H@(" @(" @(&%T(&-O;2YS;VQA<FUE
M=')I8RYK;V1O+FEM<&PN:F1B8RYS8VAE;6$N9&EC="Y344Q397)V97)$:6-T
M:6]N87)Y+G)E9VES=&5R0VQA<W,H4U%,4V5R=F5R1&EC=&EO;F%R>2YJ879A
M.C(U-BD-"B @(" @(" @870@8V]M+G-O;&%R;65T<FEC+FMO9&\N:6UP;"YJ
M9&)C+G-C:&5M82YD:6-T+E-13%-E<G9E<D1I8W1I;VYA<GDN86-C97-S)# P
M,"A344Q397)V97)$:6-T:6]N87)Y+FIA=F$Z,S4I#0H@(" @(" @(&%T(&-O
M;2YS;VQA<FUE=')I8RYK;V1O+FEM<&PN:F1B8RYS8VAE;6$N9&EC="Y344Q3
M97)V97)$:6-T:6]N87)Y)#$N869T97)#;VYN96-T*%-13%-E<G9E<D1I8W1I
M;VYA<GDN:F%V83HR-#8I#0H@(" @(" @(&%T(&-O;2YS;VQA<FUE=')I8RYK
M;V1O+FEM<&PN:F1B8RY!8G-T<F%C=%-13$5X96-U=&EO;DQI<W1E;F5R+F5V
M96YT3V-C=7)R960H06)S=')A8W1344Q%>&5C=71I;VY,:7-T96YE<BYJ879A
M.CDQ*0T*(" @(" @("!A="!C;VTN<V]L87)M971R:6,N:V]D;RYI;7!L+FID
M8F,N4U%,17AE8W5T:6]N36%N86=E<DEM<&PN9FER945V96YT*%-13$5X96-U
M=&EO;DUA;F%G97));7!L+FIA=F$Z,3 W-BD-"B @(" @(" @870@8V]M+G-O
M;&%R;65T<FEC+FMO9&\N:6UP;"YJ9&)C+E-13$5X96-U=&EO;DUA;F%G97))
M;7!L+F9I<F5%=F5N="A344Q%>&5C=71I;VY-86YA9V5R26UP;"YJ879A.CDX
M-2D-"B @(" @(" @870@8V]M+G-O;&%R;65T<FEC+FMO9&\N:6UP;"YJ9&)C
M+E-13$5X96-U=&EO;DUA;F%G97));7!L+F=E=$-O;FYE8W1I;VXH4U%,17AE
M8W5T:6]N36%N86=E<DEM<&PN:F%V83HQ-C(I#0H@(" @(" @(&%T(&-O;2YS
M;VQA<FUE=')I8RYK;V1O+FEM<&PN:F1B8RYR=6YT:6UE+DI$0D-3=&]R94UA
M;F%G97(N;F5W4U%,17AE8W5T:6]N36%N86=E<BA*1$)#4W1O<F5-86YA9V5R
M+FIA=F$Z.#(X*0T*(" @(" @("!A="!C;VTN<V]L87)M971R:6,N:V]D;RYI
M;7!L+FID8F,N<G5N=&EM92Y*1$)#4W1O<F5-86YA9V5R+F=E=%-13$5X96-U
M=&EO;DUA;F%G97(H2D1"0U-T;W)E36%N86=E<BYJ879A.C<Q-"D-"B @(" @
M(" @870@8V]M+G-O;&%R;65T<FEC+FMO9&\N:6UP;"YJ9&)C+G)U;G1I;64N
M2D1"0U-T;W)E36%N86=E<BYE>&5C=71E475E<GDH2D1"0U-T;W)E36%N86=E
M<BYJ879A.C$Q,C<I#0H@(" @(" @(&%T(&-O;2YS;VQA<FUE=')I8RYK;V1O
M+FEM<&PN:F1B8RYQ=65R>2Y*1$)#475E<GDN97AE8W5T95%U97)Y*$I$0D-1
M=65R>2YJ879A.C$R-BD-"B @(" @(" @870@8V]M+G-O;&%R;65T<FEC+FMO
M9&\N<75E<GDN475E<GE);7!L)$1A=&%S=&]R95%U97)Y17AE8W5T;W(N97AE
M8W5T95%U97)Y*%%U97)Y26UP;"YJ879A.C$U-C4I#0H@(" @(" @(&%T(&-O
M;2YS;VQA<FUE=')I8RYK;V1O+G%U97)Y+E%U97)Y26UP;"YE>&5C=71E475E
M<GE7:71H36%P*%%U97)Y26UP;"YJ879A.C8X-2D-"B @(" @(" @870@8V]M
M+G-O;&%R;65T<FEC+FMO9&\N<75E<GDN475E<GE);7!L+F5X96-U=&57:71H
M36%P*%%U97)Y26UP;"YJ879A.C4T-2D-"B @(" @(" @870@8V]M+G-O;&%R
M;65T<FEC+FMO9&\N<75E<GDN475E<GE);7!L+F5X96-U=&57:71H07)R87DH
M475E<GE);7!L+FIA=F$Z-3,Q*0T*(" @(" @("!A="!C;VTN<V]L87)M971R
M:6,N:V]D;RYQ=65R>2Y1=65R>4EM<&PN97AE8W5T92A1=65R>4EM<&PN:F%V
M83HU,#$I#0H@(" @(" @(&%T(&-O;2YM86QL97-O;G,N;&%W;6%N+G1A+G-H
M87)E9"Y"3U%U97)Y+F5X96-U=&4H0D]1=65R>2YJ879A.C$S-2D-"B @(" @
M(" @870@8V]M+FUA;&QE<V]N<RYL87=M86XN=&$N979E;G0N179E;G14:')E
M860N9V5T3F5X=$5V96YT*$5V96YT0V]N=')O;&QE<BYJ879A.C(V."D-"B @
M(" @(" @870@8V]M+FUA;&QE<V]N<RYL87=M86XN=&$N979E;G0N179E;G14
M:')E860N<')O8V5S<RA%=F5N=$-O;G1R;VQL97(N:F%V83HY-RD-"B @(" @
M(" @870@8V]M+FUA;&QE<V]N<RYL87=M86XN=&$N979E;G0N5V]R:V5R5&AR
M96%D+G)U;BA7;W)K97)4:')E860N:F%V83HW,2D-"@T*(D5V96YT0F5A;CHR
M,#,B(&1A96UO;B!P<FEO/34@=&ED/3!X,#)F93,T-3 @;FED/3!X,3(X('=A
M:71I;F<@9F]R(&UO;FET;W(@96YT<GD@6S-B-68P,# N+C-B-69D.3!=#0H@
M(" @(" @(&%T(&-O;2YS;VQA<FUE=')I8RYK;V1O+FUE=&$N0VQA<W--971A
M1&%T82YG971);G-T86YC92A#;&%S<TUE=&%$871A+FIA=F$Z,C$T*0T*(" @
M(" @(" M('=A:71I;F<@=&\@;&]C:R \,'@Q-#(T.&9F,#X@*&$@:F%V82YL
M86YG+D-L87-S*0T*(" @(" @("!A="!C;VTN<V]L87)M971R:6,N:V]D;RYI
M;7!L+FID8F,N2D1"0U!E<G-I<W1E;F-E36%N86=E<D9A8W1O<GDN<F5G:7-T
M97)#;&%S<TEN=&5R;F%L*$I$0D-097)S:7-T96YC94UA;F%G97)&86-T;W)Y
M+FIA=F$Z-#0X*0T*(" @(" @("!A="!C;VTN<V]L87)M971R:6,N:V]D;RYI
M;7!L+FID8F,N2D1"0U!E<G-I<W1E;F-E36%N86=E<D9A8W1O<GDN<F5G:7-T
M97)#;&%S<RA*1$)#4&5R<VES=&5N8V5-86YA9V5R1F%C=&]R>2YJ879A.C,S
M."D-"B @(" @(" @870@8V]M+G-O;&%R;65T<FEC+FMO9&\N:6UP;"YJ9&)C
M+E)E9VES=&5R3&ES=&5N97(N<F5G:7-T97)#;&%S<RA296=I<W1E<DQI<W1E
M;F5R+FIA=F$Z-3,I#0H@(" @(" @(&%T(&IA=F%X+FID;RYS<&DN2D1/26UP
M;$AE;'!E<BYR96=I<W1E<D-L87-S*$I$3TEM<&Q(96QP97(N:F%V83HR-CDI
M#0H@(" @(" @("T@;&]C:V5D(#PP>#$P-3$X9C4X/B H82!J879A+G5T:6PN
M07)R87E,:7-T*0T*(" @(" @("!A="!C;VTN;6%L;&5S;VYS+FQA=VUA;BYA
M82YI;G1E<F%C=&EO;BY!;'1);G1E<F%C=&EO;D1O8W5M96YT+CQC;&EN:70^
M*$%L=$EN=&5R86-T:6]N1&]C=6UE;G0N:F%V82D-"B @(" @(" @870@:F%V
M82YL86YG+D-L87-S+F9O<DYA;64P*$YA=&EV92!-971H;V0I#0H@(" @(" @
M(&%T(&IA=F$N;&%N9RY#;&%S<RYF;W).86UE*%5N:VYO=VX@4V]U<F-E*0T*
M(" @(" @("!A="!C;VTN<V]L87)M971R:6,N:V]D;RYU=&EL+DUU;'1I3&]A
M9&5R0VQA<W-297-O;'9E<BYR97-O;'9E0VQA<W,H375L=&E,;V%D97)#;&%S
M<U)E<V]L=F5R+FIA=F$Z.#4I#0H@(" @(" @(&%T(&-O;2YS;VQA<FUE=')I
M8RYK;V1O+G)U;G1I;64N2D1/0VQA<W-297-O;'9E<BYR97-O;'9E0VQA<W,H
M2D1/0VQA<W-297-O;'9E<BYJ879A.C8Y*0T*(" @(" @("!A="!C;VTN<V]L
M87)M971R:6,N:V]D;RYI;7!L+FID8F,N;W)M87!P:6YG+E-U8F-L87-S4')O
M=FED97));7!L+F=E=%1Y<&4H4W5B8VQA<W-0<F]V:61E<DEM<&PN:F%V83HQ
M,3DI#0H@(" @(" @(&%T(&-O;2YS;VQA<FUE=')I8RYK;V1O+FEM<&PN:F1B
M8RYO<FUA<'!I;F<N4W5B8VQA<W-0<F]V:61E<DEM<&PN9V5T4W5B8VQA<W-E
M<RA3=6)C;&%S<U!R;W9I9&5R26UP;"YJ879A.C(V.2D-"B @(" @(" @870@
M8V]M+G-O;&%R;65T<FEC+FMO9&\N:6UP;"YJ9&)C+F]R;6%P<&EN9RY#;&%S
M<TUA<'!I;F<N9V5T4')I;6%R>4UA<'!I;F=&:65L9',H0VQA<W--87!P:6YG
M+FIA=F$Z,3$R,"D-"B @(" @(" @870@8V]M+G-O;&%R;65T<FEC+FMO9&\N
M:6UP;"YJ9&)C+F]R;6%P<&EN9RY#;&%S<TUA<'!I;F<N;&]A9$)Y4$LH0VQA
M<W--87!P:6YG+FIA=F$Z.3(T*0T*(" @(" @("!A="!C;VTN<V]L87)M971R
M:6,N:V]D;RYI;7!L+FID8F,N<G5N=&EM92Y*1$)#4W1O<F5-86YA9V5R+FEN
M:71I86QI>F4H2D1"0U-T;W)E36%N86=E<BYJ879A.C,X."D-"B @(" @(" @
M870@8V]M+G-O;&%R;65T<FEC+FMO9&\N<G5N=&EM92Y3=&%T94UA;F%G97))
M;7!L+FQO861);FET:6%L4W1A=&4H4W1A=&5-86YA9V5R26UP;"YJ879A.C(Q
M."D-"B @(" @(" @870@8V]M+G-O;&%R;65T<FEC+FMO9&\N<G5N=&EM92Y0
M97)S:7-T96YC94UA;F%G97));7!L+F=E=$]B:F5C=$)Y261&:6QT97(H4&5R
M<VES=&5N8V5-86YA9V5R26UP;"YJ879A.C$R-S@I#0H@(" @(" @(&%T(&-O
M;2YS;VQA<FUE=')I8RYK;V1O+G)U;G1I;64N4&5R<VES=&5N8V5-86YA9V5R
M26UP;"YG971/8FIE8W1">4ED*%!E<G-I<W1E;F-E36%N86=E<DEM<&PN:F%V
M83HQ,3DV*0T*(" @(" @("!A="!C;VTN<V]L87)M971R:6,N:V]D;RYI;7!L
M+FID8F,N;W)M87!P:6YG+D]N951O3VYE36%P<&EN9RYL;V%D*$]N951O3VYE
M36%P<&EN9RYJ879A.C$U,2D-"B @(" @(" @870@8V]M+G-O;&%R;65T<FEC
M+FMO9&\N:6UP;"YJ9&)C+G)U;G1I;64N2D1"0U-T;W)E36%N86=E<BYL;V%D
M*$I$0D-3=&]R94UA;F%G97(N:F%V83HT.30I#0H@(" @(" @(&%T(&-O;2YS
M;VQA<FUE=')I8RYK;V1O+G)U;G1I;64N4W1A=&5-86YA9V5R26UP;"YL;V%D
M1FEE;&0H4W1A=&5-86YA9V5R26UP;"YJ879A.C(R-C I#0H@(" @(" @(&%T
M(&-O;2YS;VQA<FUE=')I8RYK;V1O+G)U;G1I;64N4W1A=&5-86YA9V5R26UP
M;"YI<TQO861E9"A3=&%T94UA;F%G97));7!L+FIA=F$Z.3(X*0T*(" @(" @
M("!A="!C;VTN;6%L;&5S;VYS+FQA=VUA;BYT82YA=61I="Y"3T$N:F1O1V5T
M8W5R<F5N=$%L=&5R871I;VXH0D]!+FIA=F$I#0H@(" @(" @(&%T(&-O;2YM
M86QL97-O;G,N;&%W;6%N+G1A+F%U9&ET+D)/02YG971#=7)R96YT06QT97)A
M=&EO;BA"3T$N:F%V83HR,#8I#0H@(" @(" @(&%T(&-O;2YM86QL97-O;G,N
M;&%W;6%N+G1A+F%U9&ET+D)/02YG971#=7)R96YT06QT97)A=&EO;BA"3T$N
M:F%V83HR,# I#0H@(" @(" @(&%T(&-O;2YM86QL97-O;G,N;&%W;6%N+F%P
M+FEM86YA9V4N4')O8V5S<U!R;VIE8W0N:&%S4')O:F5C=$-H86YG960H4')O
M8V5S<U!R;VIE8W0N:F%V83HY,BD-"B @(" @(" @870@8V]M+FUA;&QE<V]N
M<RYL87=M86XN87 N:6UA;F%G92Y0<F]C97-S4')O:F5C="YP<F]C97-S*%!R
M;V-E<W-0<F]J96-T+FIA=F$Z-3,I#0H@(" @(" @(&%T(&-O;2YM86QL97-O
M;G,N;&%W;6%N+G1A+F5V96YT+D5V96YT5&AR96%D+G!R;V-E<W,H179E;G1#
M;VYT<F]L;&5R+FIA=F$Z,30U*0T*(" @(" @("!A="!C;VTN;6%L;&5S;VYS
M+FQA=VUA;BYT82YE=F5N="Y7;W)K97)4:')E860N<G5N*%=O<FME<E1H<F5A
M9"YJ879A.C<Q*0T*#0HB179E;G1"96%N.C(P,B(@9&%E;6]N('!R:6\]-2!T
M:60],'@P,S(S-C0Y."!N:60],'AC9C @=V%I=&EN9R!F;W(@;6]N:71O<B!E
M;G1R>2!;,V(Q9C P,"XN,V(Q9F0Y,%T-"B @(" @(" @870@8V]M+G-O;&%R
M;65T<FEC+FMO9&\N;65T82Y#;&%S<TUE=&%$871A+F=E=$EN<W1A;F-E*$-L
M87-S365T841A=&$N:F%V83HQ.#4I#0H@(" @(" @("T@=V%I=&EN9R!T;R!L
M;V-K(#PP>#$T,C0X9F8P/B H82!J879A+FQA;F<N0VQA<W,I#0H@(" @(" @
M(&%T(&-O;2YS;VQA<FUE=')I8RYK;V1O+G%U97)Y+E%U97)Y26UP;"1$871A
M<W1O<F51=65R>45X96-U=&]R+CQI;FET/BA1=65R>4EM<&PN:F%V83HQ-3,T
M*0T*(" @(" @("!A="!C;VTN<V]L87)M971R:6,N:V]D;RYQ=65R>2Y1=65R
M>4EM<&PD475E<GE%>&5C=71I;VY-86YA9V5R+F=E=%%U97)Y17AE8W5T;W(H
M475E<GE);7!L+FIA=F$Z,3,V."D-"B @(" @(" @870@8V]M+G-O;&%R;65T
M<FEC+FMO9&\N<75E<GDN475E<GE);7!L+FEN=&5R;F%L0V]M<&EL92A1=65R
M>4EM<&PN:F%V83HT-S0I#0H@(" @(" @(&%T(&-O;2YS;VQA<FUE=')I8RYK
M;V1O+G%U97)Y+E%U97)Y26UP;"YE>&5C=71E475E<GE7:71H36%P*%%U97)Y
M26UP;"YJ879A.C8X,BD-"B @(" @(" @870@8V]M+G-O;&%R;65T<FEC+FMO
M9&\N<75E<GDN475E<GE);7!L+F5X96-U=&57:71H36%P*%%U97)Y26UP;"YJ
M879A.C4T-2D-"B @(" @(" @870@8V]M+FUA;&QE<V]N<RYL87=M86XN=&$N
M<VAA<F5D+D)/475E<GDN97AE8W5T95=I=&A-87 H0D]1=65R>2YJ879A.C$U
M.2D-"B @(" @(" @870@8V]M+FUA;&QE<V]N<RYL87=M86XN=&$N<VAA<F5D
M+E!E<G-I<W0N9V5T0D]S0GE#;VQU;6Y686QU97,H4&5R<VES="YJ879A.C4S
M-RD-"B @(" @(" @870@8V]M+FUA;&QE<V]N<RYL87=M86XN=&$N<VAA<F5D
M+E!E<G-I<W0N9V5T0D]S0GE#;VQU;6Y686QU97,H4&5R<VES="YJ879A.C0U
M,RD-"B @(" @(" @870@8V]M+FUA;&QE<V]N<RYL87=M86XN=&$N<VAA<F5D
M+E!E<G-I<W0N9V5T56YI<75E0D]">4-O;'5M;E9A;'5E<RA097)S:7-T+FIA
M=F$Z-C(T*0T*(" @(" @("!A="!C;VTN;6%L;&5S;VYS+FQA=VUA;BYT82YS
M:&%R960N4&5R<VES="YG9715;FEQ=65"3T)Y0V]L=6UN5F%L=64H4&5R<VES
M="YJ879A.C<P,2D-"B @(" @(" @870@8V]M+FUA;&QE<V]N<RYL87=M86XN
M=&$N<VAA<F5D+E!E<G-I<W0N9V5T56YI<75E0D]">4-O;'5M;E9A;'5E*%!E
M<G-I<W0N:F%V83HV.#(I#0H@(" @(" @(&%T(&-O;2YM86QL97-O;G,N;&%W
M;6%N+F%A+G!R;VIE8W0N4')O:F5C="YG971">4AO;65&;VQD97(H4')O:F5C
M="YJ879A.C$V-RD-"B @(" @(" @870@8V]M+FUA;&QE<V]N<RYL87=M86XN
M87 N97AC:&%N9V4N17AC:&%N9V5&;VQD97(N9V5T4')O:F5C="A%>&-H86YG
M949O;&1E<BYJ879A.CDV-BD-"B @(" @(" @870@8V]M+FUA;&QE<V]N<RYL
M87=M86XN87 N97AC:&%N9V4N17AC:&%N9V5&;VQD97(N<V5T2&]M97!A9V4H
M17AC:&%N9V5&;VQD97(N:F%V83HQ-3<Q*0T*(" @(" @("!A="!C;VTN;6%L
M;&5S;VYS+FQA=VUA;BYA<"YE>&-H86YG92Y%>&-H86YG949O;&1E<BYS>6YC
M1G)O;45D9V4H17AC:&%N9V5&;VQD97(N:F%V83HW-C I#0H@(" @(" @(&%T
M(&-O;2YM86QL97-O;G,N;&%W;6%N+F%P+F5X8VAA;F=E+D5X8VAA;F=E1F]L
M9&5R+F=E=%-Y;F-H<F]N:7-E9$9R;VU%9&=E*$5X8VAA;F=E1F]L9&5R+FIA
M=F$Z-#$T*0T*(" @(" @("!A="!C;VTN;6%L;&5S;VYS+FQA=VUA;BYA<"YE
M>&-H86YG92Y%>&-H86YG949O;&1E<BYG9713>6YC:')O;FES961&<F]M161G
M92A%>&-H86YG949O;&1E<BYJ879A.C,R.2D-"B @(" @(" @870@8V]M+FUA
M;&QE<V]N<RYL87=M86XN87 N97AC:&%N9V4N4')O8V5S<T9O;&1E<BYP<F]C
M97-S*%!R;V-E<W-&;VQD97(N:F%V83HU,"D-"B @(" @(" @870@8V]M+FUA
M;&QE<V]N<RYL87=M86XN=&$N979E;G0N179E;G14:')E860N<')O8V5S<RA%
M=F5N=$-O;G1R;VQL97(N:F%V83HQ-#4I#0H@(" @(" @(&%T(&-O;2YM86QL
M97-O;G,N;&%W;6%N+G1A+F5V96YT+E=O<FME<E1H<F5A9"YR=6XH5V]R:V5R
M5&AR96%D+FIA=F$Z-S$I#0H-"B)3:6=N86P@1&ES<&%T8VAE<B(@9&%E;6]N
M('!R:6\],3 @=&ED/3!X,# Y9C0X,#@@;FED/3!X-3DP('=A:71I;F<@;VX@
M8V]N9&ET:6]N(%LP+BXP70T*#0HB1FEN86QI>F5R(B!D865M;VX@<')I;STY
M('1I9#TP># P.6)B8C8P(&YI9#TP>&1C(&EN($]B:F5C="YW86ET*"D@6S)B
M-68P,# N+C)B-69D.3!=#0H@(" @(" @(&%T(&IA=F$N;&%N9RY/8FIE8W0N
M=V%I="A.871I=F4@365T:&]D*0T*(" @(" @(" M('=A:71I;F<@;VX@/#!X
M,3 U,#-E93 ^("AA(&IA=F$N;&%N9RYR968N4F5F97)E;F-E475E=64D3&]C
M:RD-"B @(" @(" @870@:F%V82YL86YG+G)E9BY2969E<F5N8V51=65U92YR
M96UO=F4H56YK;F]W;B!3;W5R8V4I#0H@(" @(" @("T@;&]C:V5D(#PP>#$P
M-3 S964P/B H82!J879A+FQA;F<N<F5F+E)E9F5R96YC95%U975E)$QO8VLI
M#0H@(" @(" @(&%T(&IA=F$N;&%N9RYR968N4F5F97)E;F-E475E=64N<F5M
M;W9E*%5N:VYO=VX@4V]U<F-E*0T*(" @(" @("!A="!J879A+FQA;F<N<F5F
M+D9I;F%L:7IE<B1&:6YA;&EZ97)4:')E860N<G5N*%5N:VYO=VX@4V]U<F-E
M*0T*#0HB4F5F97)E;F-E($AA;F1L97(B(&1A96UO;B!P<FEO/3$P('1I9#TP
M># P.6)A-S(X(&YI9#TP>&$W8R!I;B!/8FIE8W0N=V%I="@I(%LR8C%F,# P
M+BXR8C%F9#DP70T*(" @(" @("!A="!J879A+FQA;F<N3V)J96-T+G=A:70H
M3F%T:79E($UE=&AO9"D-"B @(" @(" @+2!W86ET:6YG(&]N(#PP>#$P-3 S
M9C0X/B H82!J879A+FQA;F<N<F5F+E)E9F5R96YC921,;V-K*0T*(" @(" @
M("!A="!J879A+FQA;F<N3V)J96-T+G=A:70H56YK;F]W;B!3;W5R8V4I#0H@
M(" @(" @(&%T(&IA=F$N;&%N9RYR968N4F5F97)E;F-E)%)E9F5R96YC94AA
M;F1L97(N<G5N*%5N:VYO=VX@4V]U<F-E*0T*(" @(" @(" M(&QO8VME9" \
M,'@Q,#4P,V8T.#X@*&$@:F%V82YL86YG+G)E9BY2969E<F5N8V4D3&]C:RD-
M"@T*(FUA:6XB('!R:6\]-2!T:60],'@P,# S-V,Y."!N:60],'@Q.3@@=V%I
M=&EN9R!F;W(@;6]N:71O<B!E;G1R>2!;-V8P,# N+C=F8S-C70T*(" @(" @
M("!A="!C;VTN<V]L87)M971R:6,N:V]D;RYM971A+D-L87-S365T841A=&$N
M9V5T26YS=&%N8V4H0VQA<W--971A1&%T82YJ879A.C$X-2D-"B @(" @(" @
M+2!W86ET:6YG('1O(&QO8VL@/#!X,30R-#AF9C ^("AA(&IA=F$N;&%N9RY#
M;&%S<RD-"B @(" @(" @870@8V]M+G-O;&%R;65T<FEC+FMO9&\N:6UP;"YJ
M9&)C+G-C:&5M82YD:6-T+E-13%-E<G9E<D1I8W1I;VYA<GDN<F5G:7-T97)#
M;&%S<RA344Q397)V97)$:6-T:6]N87)Y+FIA=F$Z,C4V*0T*(" @(" @("!A
M="!C;VTN<V]L87)M971R:6,N:V]D;RYI;7!L+FID8F,N<V-H96UA+F1I8W0N
M4U%,4V5R=F5R1&EC=&EO;F%R>2YA8V-E<W,D,# P*%-13%-E<G9E<D1I8W1I
M;VYA<GDN:F%V83HS-2D-"B @(" @(" @870@8V]M+G-O;&%R;65T<FEC+FMO
M9&\N:6UP;"YJ9&)C+G-C:&5M82YD:6-T+E-13%-E<G9E<D1I8W1I;VYA<GDD
M,2YA9G1E<D-O;FYE8W0H4U%,4V5R=F5R1&EC=&EO;F%R>2YJ879A.C(T-BD-
M"B @(" @(" @870@8V]M+G-O;&%R;65T<FEC+FMO9&\N:6UP;"YJ9&)C+D%B
M<W1R86-T4U%,17AE8W5T:6]N3&ES=&5N97(N979E;G1/8V-U<G)E9"A!8G-T
M<F%C=%-13$5X96-U=&EO;DQI<W1E;F5R+FIA=F$Z.3$I#0H@(" @(" @(&%T
M(&-O;2YS;VQA<FUE=')I8RYK;V1O+FEM<&PN:F1B8RY344Q%>&5C=71I;VY-
M86YA9V5R26UP;"YF:7)E179E;G0H4U%,17AE8W5T:6]N36%N86=E<DEM<&PN
M:F%V83HQ,#<V*0T*(" @(" @("!A="!C;VTN<V]L87)M971R:6,N:V]D;RYI
M;7!L+FID8F,N4U%,17AE8W5T:6]N36%N86=E<DEM<&PN9FER945V96YT*%-1
M3$5X96-U=&EO;DUA;F%G97));7!L+FIA=F$Z.3@U*0T*(" @(" @("!A="!C
M;VTN<V]L87)M971R:6,N:V]D;RYI;7!L+FID8F,N4U%,17AE8W5T:6]N36%N
M86=E<DEM<&PN9V5T0V]N;F5C=&EO;BA344Q%>&5C=71I;VY-86YA9V5R26UP
M;"YJ879A.C$V,BD-"B @(" @(" @870@8V]M+G-O;&%R;65T<FEC+FMO9&\N
M:6UP;"YJ9&)C+G)U;G1I;64N2D1"0U-T;W)E36%N86=E<BYN97=344Q%>&5C
M=71I;VY-86YA9V5R*$I$0D-3=&]R94UA;F%G97(N:F%V83HX,C@I#0H@(" @
M(" @(&%T(&-O;2YS;VQA<FUE=')I8RYK;V1O+FEM<&PN:F1B8RYR=6YT:6UE
M+DI$0D-3=&]R94UA;F%G97(N9V5T4U%,17AE8W5T:6]N36%N86=E<BA*1$)#
M4W1O<F5-86YA9V5R+FIA=F$Z-S$T*0T*(" @(" @("!A="!C;VTN<V]L87)M
M971R:6,N:V]D;RYI;7!L+FID8F,N<G5N=&EM92Y*1$)#4W1O<F5-86YA9V5R
M+F-H96-K5F5R<VEO;BA*1$)#4W1O<F5-86YA9V5R+FIA=F$Z,S,P*0T*(" @
M(" @("!A="!C;VTN<V]L87)M971R:6,N:V]D;RYR=6YT:6UE+E-T871E36%N
M86=E<DEM<&PN<F5F<F5S:"A3=&%T94UA;F%G97));7!L+FIA=F$Z-S8X*0T*
M(" @(" @("!A="!C;VTN<V]L87)M971R:6,N:V]D;RYR=6YT:6UE+E!E<G-I
M<W1E;F-E36%N86=E<DEM<&PN<F5F<F5S:$9I;'1E<BA097)S:7-T96YC94UA
M;F%G97));7!L+FIA=F$Z,3<T-"D-"B @(" @(" @870@8V]M+G-O;&%R;65T
M<FEC+FMO9&\N<G5N=&EM92Y097)S:7-T96YC94UA;F%G97));7!L+G)E9G)E
M<V@H4&5R<VES=&5N8V5-86YA9V5R26UP;"YJ879A.C$W,C(I#0H@(" @(" @
M(&%T(&-O;2YM86QL97-O;G,N;&%W;6%N+G1A+G-H87)E9"Y097)S:7-T+G)E
M;&]A9$)/*%!E<G-I<W0N:F%V83HW.30I#0H@(" @(" @(&%T(&-O;2YM86QL
M97-O;G,N;&%W;6%N+G1A+F5V96YT+D-O;G1R;VQL97(N<W1A<G0H0V]N=')O
M;&QE<BYJ879A.C(T,BD-"B @(" @(" @870@8V]M+FUA;&QE<V]N<RYL87=M
M86XN=&$N979E;G0N0V]N=')O;&QE<BYM86EN*$-O;G1R;VQL97(N:F%V83HQ
M,C,I#0H-"B)632!4:')E860B('!R:6\]-2!T:60],'@P,#EF,S9D,"!N:60]
M,'@X9&,@<G5N;F%B;&4-"@T*(E9-(%!E<FEO9&EC(%1A<VL@5&AR96%D(B!P
M<FEO/3$P('1I9#TP># P.68W,# X(&YI9#TP>&8T."!W86ET:6YG(&]N(&-O
M;F1I=&EO;@T*(E-U<W!E;F0@0VAE8VME<B!4:')E860B('!R:6\],3 @=&ED
@/3!X,# Y8F1E-3 @;FED/3!X-3(X(')U;FYA8FQE#0H`
`
end
begin 666 kodo.properties
M(R!+;V1O($I$3R!0<F]P97)T:65S(&-O;F9I9W5R871I;VX-"B,@4UE35$5-
M(%1%4U0-"@T*8V]M+G-O;&%R;65T<FEC+FMO9&\N3&EC96YS94ME>3H@>'AX
M>'@-"F-O;2YS;VQA<FUE=')I8RYK;V1O+F5E+DUA;F%G9612=6YT:6UE4')O
M<&5R=&EE<SU4<F%N<V%C=&EO;DUA;F%G97).86UE/51R86YS86-T:6]N1F%C
M=&]R>0T*#0IJ879A>"YJ9&\N4&5R<VES=&5N8V5-86YA9V5R1F%C=&]R>4-L
M87-S/6-O;2YS;VQA<FUE=')I8RYK;V1O+FEM<&PN:F1B8RY*1$)#4&5R<VES
M=&5N8V5-86YA9V5R1F%C=&]R>0T*#0HC35,@4U%,('9I82!-4R!*1$)##0IJ
M879A>"YJ9&\N;W!T:6]N+D-O;FYE8W1I;VY$<FEV97).86UE/6-O;2YM:6-R
M;W-O9G0N:F1B8RYS<6QS97)V97(N4U%,4V5R=F5R1')I=F5R#0IJ879A>"YJ
M9&\N;W!T:6]N+D-O;FYE8W1I;VY5<V5R3F%M93UX>'@-"FIA=F%X+FID;RYO
M<'1I;VXN0V]N;F5C=&EO;E!A<W-W;W)D/7AX> T*:F%V87@N:F1O+F]P=&EO
M;BY#;VYN96-T:6]N55),/6ID8F,Z;6EC<F]S;V9T.G-Q;'-E<G9E<CHO+U-4
M4U%,,#$Z,30S,SM396QE8W1-971H;V0]8W5R<V]R.T1A=&%B87-E3F%M93UX
M>'AX#0H-"FIA=F%X+FID;RYO<'1I;VXN4F5T86EN5F%L=65S/71R=64-"FIA
M=F%X+FID;RYO<'1I;VXN4F5S=&]R959A;'5E<SUT<G5E#0IJ879A>"YJ9&\N
M;W!T:6]N+D]P=&EM:7-T:6,]=')U90T*:F%V87@N:F1O+F]P=&EO;BY.;VYT
M<F%N<V%C=&EO;F%L5W)I=&4]9F%L<V4-"FIA=F%X+FID;RYO<'1I;VXN3F]N
M=')A;G-A8W1I;VYA;%)E860]=')U90T*:F%V87@N:F1O+F]P=&EO;BY-=6QT
M:71H<F5A9&5D/71R=64-"FIA=F%X+FID;RYO<'1I;VXN37-786ET/34P,# -
M"FIA=F%X+FID;RYO<'1I;VXN36EN4&]O;#TU#0IJ879A>"YJ9&\N;W!T:6]N
M+DUA>%!O;VP]-# -"FIA=F%X+FID;RYO<'1I;VXN26=N;W)E0V%C:&4]=')U
M90T*#0IC;VTN<V]L87)M971R:6,N:V]D;RYI;7!L+FID8F,N<V-H96UA+D1"
M4V5Q=65N8V5&86-T;W)Y/3(P#0IC;VTN<V]L87)M971R:6,N:V]D;RYI;7!L
M+FID8F,N4W1A=&5M96YT0V%C:&5-87A3:7IE/3 -"F-O;2YS;VQA<FUE=')I
M8RYK;V1O+FEM<&PN:F1B8RY787)N3VY097)S:7-T96YT5'EP949A:6QU<F4]
M=')U90T*8V]M+G-O;&%R;65T<FEC+FMO9&\N:6UP;"YJ9&)C+E-E<75E;F-E
M1F%C=&]R>4-L87-S/6-O;2YS;VQA<FUE=')I8RYK;V1O+FEM<&PN:F1B8RYS
M8VAE;6$N1$)397%U96YC949A8W1O<GD-"F-O;2YS;VQA<FUE=')I8RYK;V1O
M+FEM<&PN:F1B8RY&;&%T26YH97)I=&%N8V5-87!P:6YG/71R=64-"F-O;2YS
M;VQA<FUE=')I8RYK;V1O+FEM<&PN:F1B8RY!=71O4F5T=7)N5&EM96]U=#TQ
M, T*8V]M+G-O;&%R;65T<FEC+FMO9&\N3&]G9V5R/7-T9&]U= T*8V]M+G-O
M;&%R;65T<FEC+FMO9&\N16YA8FQE475E<GE%>'1E;G-I;VYS/71R=64-"F-O
M;2YS;VQA<FUE=')I8RYK;V1O+D1E9F%U;'1&971C:%1H<F5S:&]L9#TU, T*
M8V]M+G-O;&%R;65T<FEC+FMO9&\N1&5F875L=$9E=&-H0F%T8VA3:7IE/34P
M#0IC;VTN<V]L87)M971R:6,N:V]D;RYI;7!L+FID8F,N5')A;G-A8W1I;VY)
M<V]L871I;VX]4D5!1%]#3TU-2514140-"F-O;2YS;VQA<FUE=')I8RYK;V1O
M+F5E+DUA;F%G9612=6YT:6UE4')O<&5R=&EE<SU4<F%N<V%C=&EO;DUA;F%G
M97)-971H;V0]8V]M+FEB;2YE:G,N:G1S+FIT82Y4<F%N<V%C=&EO;DUA;F%G
M97)&86-T;W)Y+F=E=%1R86YS86-T:6]N36%N86=E<@T*8V]M+G-O;&%R;65T
M<FEC+FMO9&\N964N36%N86=E9%)U;G1I;65#;&%S<SUC;VTN<V]L87)M971R
C:6,N:V]D;RYE92Y);G9O8V%T:6]N36%N86=E9%)U;G1I;64`
`
end

Could you send a thread dump? Also, you may want to increase the size of
your connection pool, if that's an option. Also, it looks like you may be
hanging on getting class metadata. You may be able to get rid of this by
trying to access the metadata for each of your PC classes when getting the
PMF for the first time (before you go multithreaded).
Thanks,
Greg
"nathan boyes" <[email protected]> wrote in message
news:c8e65a$jph$[email protected]..
Within a single JVM we are running 4-5 Threads that each create and use
their own PM. The multiThreaded option is set to true, even though the
threads don't share any common data or variables.
We have an intermittent problem where all threads appear to hang fromwhich
they never recover. While it doesn't always occur, it seems to happen more
often when the application run and the threads are first started. Whenfirst
started they are all trying to perform queries which ends in the deadlock.
Could you please look into this and suggest a work around that doesn't
invlove upgrading to 3.1.
Regards
Nathan
OS Win 2k3 and XP
Kodo 2.5.8
See attached for Stacktrace and properties

Similar Messages

  • Config changes to avoid JMS thread deadlock

              From various postings and Weblogic documentation I'm trying to understand the specifics
              of
              how to avoid a JMS thread deadlock problem. The Performance and Tuning Guide states
              "...consider a servlet that reads messages from a designated JMS queue. If all
              execute threads in a server are used to process the servlet requests, then no
              threads are available to
              deliver messages from the JMS queue. A deadlock condition exists,...". I believe
              that is
              what I have, and am trying to understand whether the solution is to create a separate
              execute queue for the servlets, or change the settings on the Execute and JMS
              Thread queues,
              or both, or something else, and if so, what are the settings I should use?
              Specifically, I have servlets that use connections to a custom resource adapter,
              and each
              custom adapter connection writes to a single (for all adapter connection instances)
              permanent JMS queue and reads a response from a one-per-adapter-connection temporary
              queue. Messages are read from the permanent JMS queue by a client process (running
              outside of WLS). My servlets use the default execute queue - i.e., the don't use
              a custom execute queue - and my reads on the temporary JMS queues are timing out,
              I believe because
              no threads are available to process the JMS message
              So can I avoid deadlocks by:
              1. creating a custom execute queue that has n threads
              2. allowing a maximum of n custom adapter connection instances
              3. Setting my JMS thread pool to n (assuming I have no other JMS activity)
              i.e., using the same number - n - for all three settings? I'm about to try this
              and see,
              but if it works I'd still like to have a better understanding as to why (and of
              course if it doesn't,
              I need that understanding even more).
              Or, is text somewhere describing the specifics of how all of the Weblogic thread
              queues
              and JMS play together? There seem to be pieces scattered in various Weblogic documents,
              but
              nowhere have I found a single, coherent and complete description of how all of
              these factors
              interact.
              

              Tom Barnes <[email protected]> wrote:
              >Thanks for the info. Allocating the servlets to their own execute queue solved
              my problem.
              >
              >Glen wrote:
              >
              >> From various postings and Weblogic documentation I'm trying to understand
              >the specifics
              >> of
              >> how to avoid a JMS thread deadlock problem. The Performance and Tuning
              >Guide states
              >> "...consider a servlet that reads messages from a designated JMS queue.
              >If all
              >> execute threads in a server are used to process the servlet requests,
              >then no
              >> threads are available to
              >> deliver messages from the JMS queue. A deadlock condition exists,...".
              > I believe
              >> that is
              >> what I have,
              >
              >You can often verify by inspecting a thread dump. Note that there
              >are other possible reasons for dead-lock, including
              >programming errors at the application level - and if that is
              >the case, the thread dump will likely reveal that as well.
              >
              >> and am trying to understand whether the solution is to create a separate
              >> execute queue for the servlets, or change the settings on the Execute
              >and JMS
              >> Thread queues,
              >> or both, or something else, and if so, what are the settings I should
              >use?
              >>
              >> Specifically, I have servlets that use connections to a custom resource
              >adapter,
              >> and each
              >> custom adapter connection writes to a single (for all adapter connection
              >instances)
              >> permanent JMS queue and reads a response from a one-per-adapter-connection
              >temporary
              >> queue. Messages are read from the permanent JMS queue by a client process
              >(running
              >> outside of WLS). My servlets use the default execute queue - i.e.,
              >the don't use
              >> a custom execute queue - and my reads on the temporary JMS queues are
              >timing out,
              >> I believe because
              >> no threads are available to process the JMS message
              >>
              >> So can I avoid deadlocks by:
              >> 1. creating a custom execute queue that has n threads
              >
              >yes, or configuring more threads for the default pool
              >(somewhat more than you have concurrent servlets)
              >
              >> 2. allowing a maximum of n custom adapter connection instances
              >
              >no - i think your servlets would just end up blocking waiting
              >for adapter connections (instead of blocking waiting for
              >response messages)
              >
              >> 3. Setting my JMS thread pool to n (assuming I have no other JMS
              >activity)
              >
              >i'm not sure, but I don't think this will help in your case - JMS
              >uses the JMS thread pool for a limited purpose, and
              >still uses the default thread pool otherwise (as documented in
              >the perf guide). Plus the default thread pool is needed for
              >RMI/timers/etc.
              >
              >If servlets are truly "stealing" all of the default threads,
              >I think the best option is give
              >the servlets their own thread-pool.
              >
              >> i.e., using the same number - n - for all three settings? I'm about
              >to try this
              >> and see,
              >> but if it works I'd still like to have a better understanding as to
              >why (and of
              >> course if it doesn't,
              >> I need that understanding even more).
              >>
              >> Or, is text somewhere describing the specifics of how all of the Weblogic
              >thread
              >> queues
              >> and JMS play together?
              >
              >The JMS performance guide
              >white-paper is probably the best resource at the moment, it seems
              >to be pointing you in the right direction (provided you confirm
              >the problem is thread pool limits)
              >
              >> There seem to be pieces scattered in various Weblogic documents,
              >> but
              >> nowhere have I found a single, coherent and complete description of
              >how all of
              >> these factors
              >> interact.
              >
              >You are welcome to email a suggestion to bea support.
              >Customer suggestions tend to have more weight than internally
              >generated suggestions.
              >
              >
              

  • Thread deadlocked on itself?

    Hi,
    we have a production server, where threads become occassionally unresponsive. At that time, we take a thread dump. A few of those thread dumps show a thread is waiting to lock an object. Strangely, a few lines down in the stack trace, the same thread has the object locked. No other thread has the particular object locked or waits on it.
    How is it possible that a thread can be waitin for an object that, it has locked itself?
    FYI, the first time, I saw this, I thought it was a fluke. Perhaps the thread wasn't really waiting, but in the progress of getting the lock. Though, this issues is showing up a few times a week.
    Because the entire thread dump is very huge (long stack traces, lots of threads), here are only the last lines of the relevant stack trace:
    "/atg/dynamo/server/DrpServer-11:ipaddr=68.212.254.42;path=/store/web/login/login.jsp;sessionid=54ACNL0PIMC5UCQ2M5SSAOQKDRT4IIV0" prio=1 tid=0x85252f08 nid=0x3b15 in Object.wait() [86c88000..86c8a8c4]
    at java.lang.Object.wait(Native Method)
    - waiting on <0x71c4bfc8> (a atg.service.lockmanager.ClientLockEntry)
    at atg.service.lockmanager.ClientLockEntry.acquireReadLock(ClientLockEntry.java:597)
    - locked <0x71c4bfc8> (a atg.service.lockmanager.ClientLockEntry)
    at atg.service.lockmanager.ClientLockManager.acquireReadLock(ClientLockManager.java:977)
    at atg.adapter.gsa.ItemTransactionState.acquireReadLock(ItemTransactionState.java:719)
    at atg.adapter.gsa.GSAItem.getPersistentPropertyValue(GSAItem.java:583)
    at atg.adapter.gsa.GSAItem.getPropertyValue(GSAItem.java:478)
    at atg.adapter.gsa.GSAItem.getItemTransactionState(GSAItem.java:1471)
    at atg.adapter.gsa.GSAItem.getItemTransactionState(GSAItem.java:1351)
    at atg.adapter.gsa.GSAItem.getItemTransactionStateUnchecked(GSAItem.java:1543)
    at atg.adapter.gsa.GSAItem.getPropertyValue(GSAItem.java:735)
    at atg.repository.RepositoryItemImpl.getPropertyValue(RepositoryItemImpl.java:127)

    we have a production server, where threads become
    occassionally unresponsive. At that time, we take a
    thread dump. A few of those thread dumps show a
    thread is waiting to lock an object. Strangely, a few
    lines down in the stack trace, the same thread has
    the object locked. No other thread has the particular
    object locked or waits on it.You said occasionally...you mean not frequently, don�t you? Just a wild guess: perhaps the notify() method is being used instead of notifyAll(). When you use notify() you wake up only one thread. Therefore, if some problem occur in this only one awaken thread, so that it is not able to wake up the other threads, then you will have a big deadlock like the problem you are describing.
    The problem that might happen with that only one awaken thread I mentioned can be everything unpredictable you can imagine. The JVM environment is subject to any kind of unpredictable problems. Not only JVM, but also any other software is subject to these same kinds of problem. Although these problems are rare, they can happen.
    If notifyAll() is used instead of notify(), at least all the threads are supposed to be awaken, and then, even if some problem occur with the awaken thread that is holding the monitor, other threads are permitted to hold the monitor, since all of them are awaken, and therefore the probability of occurring that big unpredictable deadlock decreases significantly.
    Maybe it sounds like notifyAll() is always better than notify(). I am not saying that. I am just saying something that is possibly happening in your case. I suggest you reviewing all the code where the handling of threads is being done. Try to find some suspicious piece of code that is causing the problem, related to those basic issues about threads. And after you are sure that everything related to the basic rules of thumb about thread handling is ok, then think about what I said (about those unpredictable and rare problems), and check if using notifyAll() instead of notify() makes your application works better.

  • Help on resolving thread deadlock?

    How to do you eliminate the problem of having
    deadlock or invalid values during Thread
    method access to a certain data variable. While getting
    the data from the method. Someone is updating
    it to the current data.

    You have to use the synchronized keyword on all methods that could access the data, which puts a lock on an object while a thread is "in" the body of the method. No other threads can enter a synchronized method while there is a lock on the given object (if the other synchronized methods use that same object for a lock).
    The problem of deadlock can come from many possibilities, too many to just sit here and suppose. For that you'll have to post code. If you do, be sure to use [ code ] tags ( http://forum.java.sun.com/faq.jsp#messageformat ).

  • Weblogic Threads Deadlock

    We are experiencing a problem with web services communicating within a weblogic managed server configured with 15 threads. When we have 2 web services in the managed server (named A and B), after flooding A with 20 or more simultaneous requests, we begin to get socket timeouts on the inbound side of A. The throughput goes to zero and the number of queued requests continues to climb.
    This does not happen if we flood the inbound side of B. It happily handles over 100 requests.
    Are there restrictions on running multiple web services within weblogic managed servers?

    Hi,
    There is no restriction on the number of services that may run on a managed server. Can you tell the WL version you are using? Is the service using SSL? WL 8.1.5 (or 8.1.6, I am not sure) fixes an SSL bug that causes something similar to what you are experiencing.
    Regards,
    LG

  • Multi-processor Multi-Threaded deadlock

    Hi all-
    I've posted this over at jGuru.com and haven't come up with an effective solution but I wanted to try here before I reported this as a bug. This deals with kicking off many threads at once (such as might happen when requests are coming in over a socket).
    I'm looking for a way to find out when all of my threads have finished processing. I have several different implementations that work on a single processor machine:
    inst is an array of 1000+ threads. The type of inst is a class that extends threads (and thus implements the runable interface).
    for (i = 0;i<Count;i++)
    inst[ i ].start()
    for (i = 0;i<Count;i++)
    inst[ i ].join();
    however this never terminates on a multiprocessor machine. I've also tried an isAlive loop instead of join that waits until all threads have terminated until it goes on. Again, this works on the single processor but not the multi-processor machine. Additionally someone suggested a solution with a third "counter" class that is synchronized and decremented in each thread as processing finishes, then a notifyAll is called. The main thread is waiting after it starts all the threads, wakes up to check if the count is zero, and if it's not it goes back to sleep. Again this will work on the single processor but not the multi-processor.
    The thread itself ends up doing a JNI call which in turn calls another DLL which I just finished making thread safe (this has been tested via C programs). The procedures are mathematically intensive but calculation time is around half a second on a P3 800Mhz.
    Any help on this is greatly appreciated. My next step will likely be tearing down the application to exclude the calculating part just to test the JVM behavior. Is there a spec with the JVM behavior on a multi processor machine, I haven't seen one and it's hard to know what to expect from join() (joining across to processors seems like wierd concept), getCurrentThread() (since 2+ threads are running at the same time), etc.

    My next step will likely be tearing down the application to
    exclude the calculating part just to test the JVM behavior.Sounds like a really good idea.
    Is there a spec with the JVM behavior on a multi processor machine, The behaviour of threads is defined in the specs.
    You might want to check the bug database also. There are bug fixes for various versions of java.

  • Thread deadlock inside Tuxedo?

    Hi,
    We are running a simple multithreaded server in Tuxedo 8 on HPUX 11. We occasionally
    experience a strange error in the ULOG. The error is:
    082327.wblvh067!gws_tuxedo_i.20931.1.-2: LIBTUX_CAT:6314: ERROR: Invalid message
    found, diagnostic=0/0/0x4002cd60/0x4002cee0/0
    082327.wblvh067!gws_tuxedo_i.20931.1.-2: LIBTUX_CAT:2021: ERROR: Unable to expand
    message
    After this error the process is hanging at 100% utilisation. Looking at the process
    using tusc we see:
    {6789} #0 In user-mode ...........................................................................
    [running]
    {6830} #2 ksleep(PTH_CONDVAR_OBJECT, 0x40041594, 0x4004159c, NULL) ....[sleeping]
    {6831} #3 ksleep(PTH_CONDVAR_OBJECT, 0x400414a4, 0x400414ac, NULL) ....[sleeping]
    {6832} #4 ksleep(PTH_CONDVAR_OBJECT, 0x400413b4, 0x400413bc, NULL) ....[sleeping]
    The thread id #0 is the internal thread, all user dispatch threads gets id's >1
    so it seems it is running and blocking the others. We are about to log a case
    we'd quickly like to find out if anyone else has seen a similiar behavior and
    knows what the problem is?
    Regards,
    Mikael

    Hi,
    We are running a simple multithreaded server in Tuxedo 8 on HPUX 11. We occasionally
    experience a strange error in the ULOG. The error is:
    082327.wblvh067!gws_tuxedo_i.20931.1.-2: LIBTUX_CAT:6314: ERROR: Invalid message
    found, diagnostic=0/0/0x4002cd60/0x4002cee0/0
    082327.wblvh067!gws_tuxedo_i.20931.1.-2: LIBTUX_CAT:2021: ERROR: Unable to expand
    message
    After this error the process is hanging at 100% utilisation. Looking at the process
    using tusc we see:
    {6789} #0 In user-mode ...........................................................................
    [running]
    {6830} #2 ksleep(PTH_CONDVAR_OBJECT, 0x40041594, 0x4004159c, NULL) ....[sleeping]
    {6831} #3 ksleep(PTH_CONDVAR_OBJECT, 0x400414a4, 0x400414ac, NULL) ....[sleeping]
    {6832} #4 ksleep(PTH_CONDVAR_OBJECT, 0x400413b4, 0x400413bc, NULL) ....[sleeping]
    The thread id #0 is the internal thread, all user dispatch threads gets id's >1
    so it seems it is running and blocking the others. We are about to log a case
    we'd quickly like to find out if anyone else has seen a similiar behavior and
    knows what the problem is?
    Regards,
    Mikael

  • Is Oracle JDBC driver thread safe

    Is the Oracle JDBC driver thread safe?

    Seems that this is not totally true.
    We have a Problem with Oracle JDBC driver 9.2.0.5.0 (thin)
    Using an IBM JDK 1.4
    Szenario:
    Thread 1 access to a CLOB via
    ResulSet.getCharacterStream(int)
    Thread 2 normal access via some select and
    ResulSet.getString(int)
    (Both using the same connection)
    The following threads appear to be in a circular deadlock.
    Further information can be found by looking in the Overall Thread Analysis
    section of this tool.
    Multi-threaded deadlock 1:
    "Servlet.Engine.Transports : 6" of (sys:0x39778800) (TID:0x104590D0)
    Holding Resource: oracle.jdbc.ttc7.TTC7Protocol@1ADEB358/1ADEB360
    Thread Waiting: "ProcessNotificationTask" (sys:0x3C51FC18) (TID:0x103B4C40)
    "ProcessNotificationTask" of (sys:0x3C51FC18) (TID:0x103B4C40)
    Holding Resource: oracle.jdbc.driver.OracleConnection@1AE45160/1AE45168
    Thread Waiting: "Servlet.Engine.Transports : 6" (sys:0x39778800) (TID:0x104590D0)
    4XESTACKTRACE at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2667)
    4XESTACKTRACE at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2840)
    4XESTACKTRACE at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:608)
    4XESTACKTRACE at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:536)
    4XESTACKTRACE at com.top_logic.knowledge.service.db.DBKnowledgeBase.getObjectsByAttribute(Unknown Source)
    4XESTACKTRACE at oracle.jdbc.ttc7.TTC7Protocol.getLobChunkSize(TTC7Protocol.java:3050)
    4XESTACKTRACE at oracle.sql.LobDBAccessImpl.getChunkSize(LobDBAccessImpl.java:687)
    4XESTACKTRACE at oracle.sql.CLOB.getChunkSize(CLOB.java:692)
    4XESTACKTRACE at oracle.sql.CLOB.getBufferSize(CLOB.java:717)
    4XESTACKTRACE at oracle.sql.CLOB.getCharacterStream(CLOB.java:345)
    4XESTACKTRACE at oracle.sql.CLOB.characterStreamValue(CLOB.java:1377)
    4XESTACKTRACE at oracle.jdbc.driver.OracleStatement.getCharacterStreamValue(OracleStatement.java:5817)
    4XESTACKTRACE at oracle.jdbc.driver.OracleResultSetImpl.getCharacterStream(OracleResultSetImpl.java:1230)
    It seems that the access to the CLOB needs another,
    internal SELECT to the Database and this way
    TTC7Protocol and OracleConnection lock out each other.
    This only happens on a true multiprocessor machine.
    We tried to reprodcue it on a Single Processor
    and some HyperThreading Machine but had no real sucess.
    Now where can I sumbit this as a Bug ?

  • Deadlock in PM?

    Hi,
    The following stack traces are the (shortened) result of a Linux thread dump
    during a program hang I encountered today. The main point of interest is
    that during this hang, there were two Kodo objects which appear to be stuck
    waiting on locks. These are the PersistenceManangerImpl ( line 552 ) and
    the StateManagerImpl ( line 323 ). The other threads you see from my
    application are all waiting for a lock on a single, static object, which
    happens to be a Map of Threads to running, transactional persistence
    managers. Those calls are just a step away from making other commit calls
    to Kodo. The lock they are waiting on is held by the first thread, which
    locks the map while updating the PMs with ids that have just been changed in
    a commit.
    I suspect the lock is caused by commits in two separate PersistenceManagers
    occurring at nearly the same time. The first thread commits successfully,
    and then attempts to update other persistenceManagers ( possibly including
    the pm involved in the second thread, the one that is in the middle of a
    commit ) by calling refreshAll.
    Hope this helps. Let me know if you need more information.
    -Eric Lindauer
    "[HCM] - Creating a new Pricing job" prio=1 tid=0x49192538 nid=0x7401
    waiting for monitor entry [0xbc5ff000..0xbc5ff8a4]
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.getObjectByIdFilter(Pers
    istenceManagerImpl.java:552)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.getObjectById(Persistenc
    eManagerImpl.java:529)
    at
    com.solarmetric.kodo.impl.jdbc.ormapping.OneToOneMapping.load(OneToOneMappin
    g.java:121)
    at
    com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManage
    r.java:242)
    at
    com.solarmetric.kodo.runtime.StateManagerImpl.loadFields(StateManagerImpl.ja
    va:1160)
    at
    com.solarmetric.kodo.runtime.PCleanState.refresh(PCleanState.java:90)
    at
    com.solarmetric.kodo.runtime.StateManagerImpl.refresh(StateManagerImpl.java:
    443)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.refreshFilter(Persistenc
    eManagerImpl.java:911)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.refreshAll(PersistenceMa
    nagerImpl.java:869)
    at
    com.hcm.tools.jdo.HCMPersistenceManager.refreshAll(HCMPersistenceManager.jav
    a:258)
    at
    com.hcm.tools.jdo.JDOFactory.updateTransactionalPms(JDOFactory.java:466)
    <...>
    "[HCM] - Creating a new Pricing job" prio=1 tid=0x49184c38 nid=0x73fe
    waiting for monitor entry [0xbcbff000..0xbcbff8a4]
    at
    com.solarmetric.kodo.runtime.StateManagerImpl.preStore(StateManagerImpl.java
    :323)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.flush(PersistenceManager
    Impl.java:319)
    at
    com.solarmetric.kodo.runtime.PersistenceManagerImpl.commit(PersistenceManage
    rImpl.java:245)
    <...>
    "[HCM] - Creating a new Pricing job" prio=1 tid=0x4890c5f0 nid=0x7400
    waiting for monitor entry [0xbc7ff000..0xbc7ff8a4]
    at
    com.hcm.tools.jdo.JDOFactory.getNewTransactionalPersistenceManager(JDOFactor
    y.java:318)
    <...>
    "[HCM] - Creating a new Pricing job" prio=1 tid=0x4890e738 nid=0x73ff
    waiting for monitor entry [0xbc9ff000..0xbc9ff8a4]
    at com.hcm.tools.jdo.JDOFactory.removeThread(JDOFactory.java:372)
    <...>
    "[HCM] - Creating a new Pricing job" prio=1 tid=0x491a1918 nid=0x73fd
    waiting for monitor entry [0xbcdff000..0xbcdff8a4]
    at com.hcm.tools.jdo.JDOFactory.removeThread(JDOFactory.java:372)
    <...>

    Hi,
    similar errors are in the wls 10.3.4 too (fpr Example MOS Note: WebLogic Server thread deadlocked at JMS utilization (waiting to acquire lock 'weblogic.jms.common.CDS@20a61785') (Doc ID 1382525.1).
    I would consider to upgrade to 10.3.6 or 12 (if possible)
    Borys

  • Fullscreen deadlock

    I've got a few problems with my fullscreen game. The main loop runs in it's own thread and paints the frame regularly, eg. uses BufferStrategy.getDrawGraphics() and then calls frame.paint().
    In the "level-choosing mode", the program shows a JPanel with a JList and a JTextArea. When the list selections changes, valueChanged is called, and I try to set a text in the JTextArea using setText(). This sometimes causes a deadlock (threadlock?) which causes the game to hang. By inspecting the different threads, I've figured out that this happens when the main loop tries to paint the JTextArea at the same time as it's being edited by AWT-EventQueue. More precisely, the main loop thread stops at a wait()-call in readLock(), while AWT-EventQueue halts somewhere in invalidate(), both in my JTextArea object.
    What can I do to avoid this problem? I have to excuse the absense of code in my problem description, but I really don't know which code snippets to show you... Ask me if you really need some code to solve the problem.

    Hi,
    similar errors are in the wls 10.3.4 too (fpr Example MOS Note: WebLogic Server thread deadlocked at JMS utilization (waiting to acquire lock 'weblogic.jms.common.CDS@20a61785') (Doc ID 1382525.1).
    I would consider to upgrade to 10.3.6 or 12 (if possible)
    Borys

  • Deadlock in ImageFetcher

    Following is the Thread dump which shows a typical deadlock scenario.Does anybody aware of it?
    "Image Fetcher 1" daemon prio=4 tid=0x0D083810 nid=0x1fc0 waiting for monitor entry [e57f000..e57fd90]
         at sun.awt.image.ImageDecoder.close(Unknown Source)
         - waiting to lock <109503D8> (a sun.awt.image.PNGImageDecoder)
         at sun.awt.image.ImageDecoder.abort(Unknown Source)
         at sun.awt.image.ImageDecoder.removeConsumer(Unknown Source)
         at sun.awt.image.InputStreamImageSource.removeConsumer(Unknown Source)
         - locked <12599558> (a sun.awt.image.ByteArrayImageSource)
         at java.awt.image.FilteredImageSource.removeConsumer(Unknown Source)
         - locked <10950488> (a java.awt.image.FilteredImageSource)
         at sun.awt.image.ImageRepresentation.imageComplete(Unknown Source)
         - locked <109504A0> (a sun.awt.windows.WImageRepresentation)
         at java.awt.image.ImageFilter.imageComplete(Unknown Source)
         at sun.awt.image.PixelStore.replay(Unknown Source)
         - locked <10950500> (a sun.awt.image.PixelStore8)
         at sun.awt.image.PixelStore.replay(Unknown Source)
         - locked <10950500> (a sun.awt.image.PixelStore8)
         at sun.awt.image.InputStreamImageSource.updateFromStore(Unknown Source)
         at sun.awt.image.InputStreamImageSource.doFetch(Unknown Source)
         at sun.awt.image.ImageFetcher.fetchloop(Unknown Source)
         at sun.awt.image.ImageFetcher.run(Unknown Source)
    "Image Fetcher 0" daemon prio=4 tid=0x0D0BD0D0 nid=0x13d8 waiting for monitor entry [8b1f000..8b1fd90]
         at sun.awt.image.InputStreamImageSource.isConsumer(Unknown Source)
         - waiting to lock <12599558> (a sun.awt.image.ByteArrayImageSource)
         at sun.awt.image.PixelStore.replay(Unknown Source)
         - locked <10950610> (a sun.awt.image.PixelStore8)
         at sun.awt.image.PixelStore.replay(Unknown Source)
         - locked <10950610> (a sun.awt.image.PixelStore8)
         at sun.awt.image.PNGImageDecoder.catchupConsumer(Unknown Source)
         - locked <109503D8> (a sun.awt.image.PNGImageDecoder)
         at sun.awt.image.InputStreamImageSource.latchConsumers(Unknown Source)
         at sun.awt.image.ImageDecoder.setPixels(Unknown Source)
         at sun.awt.image.PNGImageDecoder.sendPixels(Unknown Source)
         at sun.awt.image.PNGImageDecoder.produceImage(Unknown Source)
         at sun.awt.image.InputStreamImageSource.doFetch(Unknown Source)
         at sun.awt.image.ImageFetcher.fetchloop(Unknown Source)
         at sun.awt.image.ImageFetcher.run(Unknown Source)

    Hi,
    similar errors are in the wls 10.3.4 too (fpr Example MOS Note: WebLogic Server thread deadlocked at JMS utilization (waiting to acquire lock 'weblogic.jms.common.CDS@20a61785') (Doc ID 1382525.1).
    I would consider to upgrade to 10.3.6 or 12 (if possible)
    Borys

  • ScheduledThreadPoolExecutor Deadlock

    I've been trying to use ScheduledThreadPoolExecutor instead of the Timer class to handle a large amount of tasks with a thread pool. However, I'm running into a deadlock situation.
    I basically schedule tasks at a fixed rate. And in the run() method of these ScheduledFuture tasks, I decide whether a task is finished and do so by doing the following:
    scheduler.remove(this);
    task.cancel(false);
    Previously I used to just do task.cancel() without any issues. But I'm forced to the scheduler.remove() because the unlike the Timer task, the scheduler does not remove cancelled tasks when it sees them which makes the queue grow as a memory leak.
    However, during heavy load, all my new schedule()'s get stuck at offer() on the queue and all the worker threads are in take() waiting for tasks in the queue. It seems like somehow a lock was not unlocked if that makes sense because I've done a dump on the threads and I see no thread in a runnable state holding any locks in the ScheduledThreadPoolExecutor or its DelayQueue.
    Has anyone seen anything like this before?

    Hi,
    similar errors are in the wls 10.3.4 too (fpr Example MOS Note: WebLogic Server thread deadlocked at JMS utilization (waiting to acquire lock 'weblogic.jms.common.CDS@20a61785') (Doc ID 1382525.1).
    I would consider to upgrade to 10.3.6 or 12 (if possible)
    Borys

  • How not to use Cold Fusion and Java

    Overview
    This write up is intended to give java developers that are
    developing ColdFusion applications some beneficial information:
    things that are not documented.
    Scenario
    The company builds enterprise class web application software
    for fortune 500 companies. It had purchased a CF 7 based product,
    had and existing proprietary J2EE based product, and needed to
    integrate the two while meeting a host of new requirements. These
    requirements were based on delivering a better user experience,
    faster / cheaper integration, increased flexibility /
    configuration, useablily, decreasing maintenance costs, the ability
    to deploy in either install or ASP models. An initiative was
    started to create a new framework that integrated the best of each
    technologies. Tactically, this meant that we were to build a hybrid
    CF and java application: one that used building blocks (decoupled /
    cohesive components) that would allow applications to be rapidly
    assembled, configured and deployed. This made sense on several
    levels, the team was composed of Java and CF developers, the CF
    rapid application development was very productive, there is great
    functionality delivered in the CF platform and initial performance
    tests showed no cause for alarm
    The agreed upon design, based on requirements, and analysis
    by both the CF and Java staff has us using CF in the presentation
    layer, using a CF based MVC, use of CF based web services. The MVC
    was deployed using CFC inheritance for model objects and views made
    use of CF custom tags. The internals of the application, used a
    rules engine, some proprietary java, ORM, and other J2EE
    technology. The initial performance of the system was reasonable.
    We pushed on with product implementation.
    Then it was time to load test the application, and tune it.
    Under load the response times were orders of magnitude slower,
    sometimes the pages even timed out.
    Armed with our profiler, oracle execution plans and we
    charged ahead addressing issue after issue. Note that we took
    meticulous care in tweaking the active thread pool and ensuring
    that our CF setup was tuned for our application. None of the
    observations here are a condemnation of the language; rather they
    are aspects that, when considered together, not conducive for
    building integrated java and CF frameworks that use a structured /
    OO programming practices. Further detail can be provided on
    request.
    CFC inheritance should be avoided - resolution of variable
    scope is expensive even if properly declared.
    Since CF creates a class per method under the covers call
    stacks become very large, especially if used in a loop. This is
    nominally exacerbated by CF calls necessary to set up for the
    method call (String.toUpper()).
    Nesting of loops and if statements should be kept to a
    minimum - the conditional for each lookup of logical operator like
    LT, GT are synchronized. Under load this results in thread waits.
    Jrun has as single thread pool - both http and web service
    requests use the same pool. Under load this leads to thread
    deadlock. There are work arounds, but they are painful.
    Recursion should be avoided - we had a few recursive routines
    and these had to be rewritten.
    Custom Tags - should be used sparingly - each custom tag
    makes a synchronized call to the license server - (This may be
    fixed in CF 8)
    Summary
    In the end we got the performance to reasonable numbers, but
    we ended up moving some code to java (Custom Tags) and getting rid
    of 'good programming' practices (Inheritance, loops, etc), mandated
    proper variable scoping for those things left over. We prototyped a
    sans cold fusion implementation and had an order of magnitude
    improvement in performance and number of requests served per
    second.
    The lesson? Use Coldfusion in its sweet spot: make a query,
    iterate over the results and format for display. Extensive use of
    structure programming techniques or OO CFCs should be avoided: they
    will work but under load - but are better as a prototype. Building
    frameworks in CF? Think twice, no three times, and, if you must, be
    minimalist.
    Text

    interesting aslbert123,
    Not that I doubt you, but could you answer some questions
    about your implementation that was so slow:
    1.) Did you put your CFCs in the application or server scope?
    2.) Were you initializing your CFCs, via CreateObject or
    <cfinvoke>, on every request?
    3.) Are you sure that you were properly Var'ing every
    variable in your methods? (people typically forget about query
    names and loop iterator variables)
    4.) Could you give examples of how your inheritence was set
    up?
    5.) For CustomTags, did you call them the old <cf_tag>
    way or the newer, better-performing <cfimport> way?
    6.) How did you connect CF to Java exactly?
    Thanks,
    Aaron

  • Performanc​e issues - CVI 2010

    Hi all,
    I have code I've compiled on a development machine - XP Pro with SP3 - and I'm seeing some performance issues on a similarly configured test machine.  2GB Ram, Pentium 4 CPU 2.8GHz.  I had our IT person clean off another machine for me to use exclusively for testing (the other machine is our Tester's PC) and he gave me one with an Intel Core2 4300 @ 1.80 GHz.  My code on my test machine runs like a top with NO problems. 
    We have another PC running Win7 on an Intel Core i5-2400 @ 3.10 GHz, RAM = 4GB.  The code should be screaming on this machine but we're seeing performance problems here, too, that I believe may be due to the OS - Win7 may be a real hog.
    Can anyone make sense of this?  Is the dual core that much better even though that CPU is rated lower in PassMark Bench Ratings (http://www.cpubenchmark.net/cpu_list.php).  We're trying to work all this out so we can advise the customer on which machine he needs to run our software.
    Thanks,
    Judy

    Hi Judy,
    Looking at the spreadsheet it seems unlikely that memory or cpu requirements are the root cause of the issue because the second machine in the spreadsheet with poor "performance" has almost twice the CPU clock speed and twice the physical memory of the fourth machine that runs well.
    It sounds like your application is a fairly complex application that involves both GUI components and instrument I/O so what needs to be done is determine what part of the application is causing the bottleneck. There are many different factors which if not considered properly when developing applications that can cause performance problems such as thread deadlocks, device driver problems with the instruments or other hardware, needing to adjust the sleep policy for GUI events, writing to TDMS files in CVI versions before 2010 SP1, having memory leaks in the application code, etc. There is also a KB called Improving Performance of LabWindows™/CVI Applications that describes some changes which may help improve performance.
    The overall message is that it is not only CPU speed and quantity of RAM available that can cause performance problems. A way to check the amount of RAM used by an application and CPU Utilization is to use the Windows 7 Resource Monitor to watch the application. This can be done by running Task Manager (ctrl + shift + esc), selecting the Performance tab and pressing Resource Monitor. This will open the Resource Monitor window where you can check CPU usage, Memory, Disk and Network usage for the application while it is running.
    Milan

  • Error Invoking Java class from Stored proc

    We are getting this error while calling a stored procedure that invokes a
    static function of a java class from inside Oracle 8.1.7.
    ORA-29516: Aurora assertion failure: Java thread deadlock detected
    ORA-06512: at "APPS.SERVICECONSUMERINVOKE", line 0
    ORA-06512: at line 40
    In a Toad SQL Window, when I execute the stored procedure that invokes the
    java function, it executes successfully on the first attempt. When I try to
    execute it again on the same SQL Window, it gives the above error. The java
    class is part of a package and indirectly makes a JMS request-reply call
    via other helper classes.
    The same package works fine from other web containers and
    unlike the Oracle JVM Aurora, the JVMs don't detect a deadlock.
    Why does the Aurora throw an error?

    Did you try issusing a commit and then trying again in Toad SQL Window?
    The advice is to contact support:
    ORA-29516: Aurora assertion failure: string
    Cause: An internal error occurred in the Aurora module.
    Action: Contact Oracle Worldwide Support.

Maybe you are looking for

  • Dvi vs adc.

    I am looking for an Apple 23" monitor. See lots of ADC, and a few DVI. Which is the better way to go?

  • Can't update because "don't have permission to acess..." on new Mac

    I am trying to download the newest version of Firefox. Running Mac 10.6.6 Older version of Firefox exists. When I try to add the newer download I get ''The operation can't be completed because you don't have permission to access some of the items''.

  • Bdc recording with fk01 .. gives .. error

    hi experts i m now to .. abap .. i have done .. recordin on BDC fk01.. but .. it is not uploadin .. the the data from excel sheet .. kindly help me out in this ... here is the source code of it ..... report ZBDC no standard page heading line-size 255

  • Do i require the adobe player to be embedded in the source code while designing a site?

    In my website and I want to use a flash file inside with some animation in place of a slider with static images. I am confused if I am required to add a flash player on the website in its source code. Is there a way that I can use the flash player or

  • Scanning and displaying in JSP

    Hai I want to sacn an image and i want to display in the browser i mean in jsp page is there any API is doing this or else how can i achieve this thanx in advance suresh