Radu, thanks for the thoughts. I will investigate some of those
ideas...since we are out of ideas at this point.
Thanks,
Joe
-----Original Message-----
From: Radu Preotiuc-Pietro [mailto:[EMAIL PROTECTED]
Sent: Monday, October 16, 2006 9:56 AM
To: [email protected]
Subject: RE: Wierd "Freeze" in Validate on WebSphere 5.1
Well, I got to say I have no idea where in the XMLBeans code this
problem might be. You say it's related to validation and it's not around
the SchemaTypeVisitorImpl.visit() method (which is the "trickiest"
validation method).
On the other hand, you are saying that you don't see this problem on
Windows, which hints that this is not an "algorithmic" problem, but
something environment-related (the one that we fixed for 1.0.4 was
happening regardless of the environment used if I remember correctly).
I guess one simple test that you could do is try to validate the same
document using the command-line tool "validate" or even better, your
code running outside of WebSphere.
One thing which _might_ be happening is that the loading of all the
Schema type information off the classpath during validation triggers
some weird classloading behaviour from WAS (that could also explain why
the whole server is frozen). By the way, XMLBeans uses the context
classloader (by default) to load this type information.
Radu
-----Original Message-----
From: Joseph Mihalich [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2006 6:15 PM
To: [email protected]
Subject: RE: Wierd "Freeze" in Validate on WebSphere 5.1
Hi all,
We are using xml beans 1.0.4, latest binary release. We're
having a really horrible problem on WebSphere 5.1 trying to
validate
xml requests coming in on our web services.
What seems to be randomly, different components (in our
ear's)
deserialize XML received from Axis, will call into the XmlObject
Validate method, and just go in, and sit there for anywhere
between
2 and 4 minutes. The xml is usually 1K or less, so it's really
small.
And the same XML Document doesn't cause the long delay if I try
to
replay the message.
During this time that validate is taking so long the entire
WebSphere AppServer is frozen...all execution and logging stops
until this call returns. (Not sure how that can happen, but
that's
another story).
I noticed a bug logged against 1.0.3 where the exact same
behavior
was noted, and an optimization was put into 1.0.4 to fix it. We
were
on 1.0.3, and upgraded to 1.0.4 and still experienced the
problem.
I pulled the 1.0.4 source, and added logging around the fix
that was made, and verified that in fact, the "delay" was NOT being
observed in that method, so the problem is somewhere else.
I attempted to add more logging to try and isolate where the
delay was coming from, but of course, once I did that I could
not
reproduce it...hinting at some kind of timing issue. Then I ran
out
of time, and had to put this problem aside for a while.
This happens on every single box we install on. This occurs
on
Suse Linux 9.1 Ent, WAS 5.1, IBM JDK 1.4.2. Also, we do NOT see
this
on our windows platform which runs Windows Server 2003, Jboss
4.0.4,
and Sun JDK 1.4.2.
Anyway, I was wondering if anyone else has experienced this
issue
on WAS 5.1, and if anyone has any suggestions on what or where
the
problem might be in the xml beans code?
Thanks for any help you can provide.
Thanks,
Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
