Bug 57542 - Test Operation error: Unable to internalize message
Test Operation error: Unable to internalize message
Status: CLOSED FIXED
Product: webservices
Classification: Unclassified
Component: Code
4.x
All All
: P1 (vote)
: 4.x
Assigned To: Petr Jiricka
issues@webservices
:
: 52685 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-06 14:05 UTC by L Martinek
Modified: 2006-03-24 12:56 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
WSDL to test (7.32 KB, text/xml)
2005-04-06 14:06 UTC, L Martinek
Details
Exception from Test Operation. I had to attach it as GIF, because Ctrl+C copy it without CRLF. (83.26 KB, image/gif)
2005-04-06 14:07 UTC, L Martinek
Details
NB message log (35.75 KB, text/plain)
2005-04-08 15:26 UTC, Petr Blaha
Details
IDE log (13.41 KB, text/plain)
2005-04-11 10:29 UTC, L Martinek
Details
server.log (24.27 KB, text/plain)
2005-04-11 10:30 UTC, L Martinek
Details
TCP dump when proxy is turned on (1.30 KB, text/plain)
2005-04-14 17:48 UTC, L Martinek
Details
Patch for IDESettings (against both trung and release41 branch) (2.66 KB, patch)
2005-04-18 18:32 UTC, Petr Jiricka
Details | Diff
patch reads IgnoreHost property from OS settings on unix (3.69 KB, patch)
2005-04-19 08:57 UTC, Jiri Rechtacek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description L Martinek 2005-04-06 14:05:47 UTC
I saw this message (Unable to internalize message) several time, but I hadn't
reproducible testcase. Now I have it:

1. Create new Web Applivation.
2. Create new Web Service from local file (will be attached). Name it e.g.
GoogleWebService1.
3. Deploy Web Application.
4. Add WS to registry.
5. Invoke Test Operation. It works.
6. Create another new Web Application.
7. Create new Web Service from URL http://api.google.com/GoogleSearch.wsdl. Name
it e.g. GoogleWebService2.
8. Deploy Web Application.
9. Add WS to registry.
10. Invoke Test Operation. Now it doesn't work. Try Test Operation on first WS.
It doesn't work too.

HTTP transport error: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Unable to
internalize message
Comment 1 L Martinek 2005-04-06 14:06:16 UTC
Created attachment 21423 [details]
WSDL to test
Comment 2 L Martinek 2005-04-06 14:07:35 UTC
Created attachment 21425 [details]
Exception from Test Operation. I had to attach it as GIF, because Ctrl+C copy it without CRLF.
Comment 3 L Martinek 2005-04-06 15:23:40 UTC
This is in messages.log:

6.4.2005 14:59:38 com.sun.xml.messaging.saaj.soap.MessageImpl identifyContentType
SEVERE: SAAJ0537: Invalid Content-Type. Could be an error message instead of a
SOAP message
6.4.2005 14:59:38 com.sun.xml.messaging.saaj.soap.MessageImpl <init>
SEVERE: SAAJ0535: Unable to internalize message

Both appserver and web service are running. When I create own ws client it works
without problems.
Comment 4 L Martinek 2005-04-06 17:40:10 UTC
I have next observation. When I got this exception, I remembered URL of my web
service used for registration. I exited IDE and started IDE with new userdir. I
registered AppServer and only added Web Service to the Web Service Registry - I
used remembered URL. I invoked Test Operation and it worked! I exited IDE and
started IDE with previous (first) userdir and invoked Test Operation - it still
didn't worked. I exited IDE and returned back to IDE with second userdir. I
invoked Test Operation and now it threw exception. I deleted it from Web Service
Registry and added again and then it worked. 

When I did all of these, appserver was running and I didn't change anything, I
didn't redeployed any application. So Test Operation worked in one IDE and
didn't worked in another so it might be a bug in IDE and not in appserver.
Comment 5 _ pcw 2005-04-06 22:30:54 UTC
Based on the bug description, this is what I think -- I'll confirm or update
once I've been able to investigate exactly which of these cases it is.

Looking at it right now -- if the bug is what I think it is, there are two ways
to interpret it:

A) The registry cannot expose two distinct WSDL's that refer to the same service
name -- cannot be fixed for 4.1.  Rave cheated to handle this case, we can't.

B) The "New Service From WSDL" option does not take the service name as
specified by the user (e.g. "GoogleService1") and use it in the WSDL.  In this
bug report, if this had happened, I would expect the actual service names should
have been different and the cause is something else -- I'm investigating this
right now.

If the reason is (A), then there is nothing we can fix here for 4.1 -- too hard
and disruptive. 
Comment 6 _ pcw 2005-04-07 01:09:35 UTC
Ok, I actually investigated this problem.  Forget my first hypothesis.

The two services (one each in two webapps) do maintain the distinct name
(GoogleWebService1, GoogleWebService2) in each project.  And actually, I was
able to follow the steps as written and have no problem testing either service
after creating them and adding them to the registry.

I was able to test both successfully.  I was able to shutdown the IDE and
restart, start the server, and retest both clients successfully without
redeploy.  This was all on Windows XP.
Comment 7 _ pcw 2005-04-07 01:59:26 UTC
Shutting down the IDE, removing the user directory, restarting, reinstalling and
starting the appserver and re-adding both web services to the registry also
produced working clients in test mode.

The only thing I can possibly think of, and I don't see how it could apply to
such strict steps, is if you did this on a laptop, shut down the computer,
restarted on a different port (such as switching to VPN from home).  Then the
WSDL files that built the existing clients would have the wrong IP address and
would not work.  But the clean userdir option should fix that, because in that
case, the services are re-added.

This bug sounds like a dup of a bug that I believe was finally closed as "cannot
reproduce".  In that report, I made the suggestion to the reporter to do the
following:

On the machine that reproduces this problem do this:

When a particular service works, go the browser with the WSDL URL, download it
and attach it to the bug report as the "working WSDL".  Next, go through the
tests to make the client not work.  Now go back to the browser, give it WSDL URL
again and download the WSDL a second time.  Attach it as "non-working WSDL" or
if the service is not working, add that comment to the report.  You can also
check to see if the WSDL files compare the same (they should, but may not, which
could help identify the problem.)

For this report, I'd expect 4 wsdls (2 each working and non-working) to be attached.
Comment 8 _ pcw 2005-04-07 18:34:10 UTC
Please respond to query for more info (last paragraph in previous comment) or
close this as WORKSFORME.
Comment 9 L Martinek 2005-04-07 20:07:31 UTC
I neither restarted IDE not computer. I haven't restarted appsever.

I compared WSDL when web service was working and then when "wasn't" working and
they are identical. Then I paralelly started second instance of IDE with new
userdir, registered same appserver and added webservice created in first IDE to
Web Service Registry (by WSDL URL). Here Test Operation worked so web service
*is* working and only can't be executed from first IDE. 

My colleague wasn't able to reproduce this issue too so maybe it's again one of
issues which I am the only one who can reproduce it.
Comment 10 _ ludo 2005-04-08 04:08:58 UTC
This seems to be linked to an env issue...
What is so special about your config or computer?
Can you attach ide and server logs, any other info that would be different than
our systems?
Comment 11 Lukas Jungmann 2005-04-08 14:50:20 UTC
just found http://forum.java.sun.com/thread.jspa?threadID=482307&tstart=135,
maybe it can be helpful
Comment 12 Petr Blaha 2005-04-08 15:25:45 UTC
Hi all, I am able to reproduce this issue on my NTB with Linux OS, message.log
is attached.
Comment 13 Petr Blaha 2005-04-08 15:26:43 UTC
Created attachment 21500 [details]
NB message log
Comment 14 Lukas Jungmann 2005-04-08 15:38:41 UTC
We've just test this little bit more and here is our result:

for the steps described above:
 - we can reproduce this on notebooks (2x winXP, 1x linux)

 - we cannot reproduce this on desktops (1x winXP, 1x Mac)


additional steps:
 - test websvc, which runs on notebook, on desktop => SAAJ0535 as above

 - test websvc, which runs on desktop, on notebook => successfull
Comment 15 _ pcw 2005-04-09 01:30:14 UTC
Is it conceivable that the IP address or name of the computer would have changed
between when the service worked and when it did not?  This might explain some of
the connection refused messages (though the other SOAP errors are still
unexplained.)

Also, is that a clean log, in that it was empty prior to attempting the steps in
this issue and all the errors therein were accumulated only by performing these
steps (once)?  I ask because there are an awful lot of errors in there -- do you
know what the action was that caused the first few errors to be recorded.
Comment 16 L Martinek 2005-04-11 10:29:36 UTC
Created attachment 21531 [details]
IDE log
Comment 17 L Martinek 2005-04-11 10:30:09 UTC
Created attachment 21532 [details]
server.log
Comment 18 L Martinek 2005-04-11 10:37:51 UTC
IP and name is same for all the time of the test. One difference between desktop
and notebook is DNS name. My notebook's name is libor-nb, but because I get IP
from DHCP, my name in DNS is general, e.g. d-eprg05-75-195, so name libor-nb is
not working outside my computer.
Comment 19 _ pcw 2005-04-13 19:42:19 UTC
Libor, Petr Blaha and I did VNC session where they demonstrated this behavior to
me.  It appears that on machines where this situation occurs, it is easy to get
into an invalid state where no clients work and once such a state is
encountered, the only way to fix it is to delete the user directory and start
over (probably deleting just the websvc subdirectory of the user directory will
work, but we did not test this.)

I examined the client jars that were created and then failed to work and they
appear fine.  I still do not have a clue as to what the problem is, though on
systems where this happens, test mode appears irretrievably broken once it happens.

I will discuss this with the JAXRPC team to try to get a better understanding of
the actual failure.
Comment 20 _ pcw 2005-04-13 23:54:49 UTC
*** Issue 52685 has been marked as a duplicate of this issue. ***
Comment 21 _ pcw 2005-04-14 01:11:56 UTC
Comments from JAXRPC team:

This is an error from SAAJ. This usually happens when the server responds with a
non-soap message, usually it is a standard web page error.  You should use a
network sniffer to see what the server is sending back.  My guess is that the
client is not sending the request to the proper address.  - Doug

Looks like the exception is coming from SAAJ, due to parsing of http headers or
SOAP  message(incorrect). There should be CAUSE messages in the full exception
stack trace. Without the complete stack trace, it's difficult say where exactly
SAAJ failed.  - Jitu
Comment 22 Martin Grebac 2005-04-14 13:09:11 UTC
I'm not able to reproduce on my notebook.
Comment 23 _ pcw 2005-04-14 15:36:18 UTC
According to Doug (JAXRPC team) and also help for this error message, this is
likely related to malformed SOAP data.

I enabled HTTP monitor on the application server to see if I could at least
indirectly view SOAP packets through that.  The HTTP POST request from <Test
Operation> shows up, but I was unable to retrieve the raw data for the message.
 This may simply be how HTTPMonitor works, or maybe I was using it incorrectly.

I think that in order to solve this problem we will need to determine exactly
what is wrong with the communication in the cases where it fails.
Comment 24 Sherold Dev 2005-04-14 16:31:09 UTC
The HTTP Monitor won't be much helpful since it can't display message body as
raw data yet.

A network sniffer like www.ethereal.com would definitely do much better job in
this case.
Comment 25 L Martinek 2005-04-14 17:47:12 UTC
We have it! It's caused by proxy. If I turn on proxy, Test Operation doesn't
work at all.

When proxy is turned off, HTTP request is "POST /WS1/NewWebService1 HTTP/1.1"
and it works. When proxy is turned on, HTTP request is "POST
http://localhost.czech.sun.com:8080/WS1/NewWebService1 HTTP/1.1" and proxy
server has no idea about localhost.czech.sun.com. On another computer there is
correct hostname instead of localhost, "POST
http://libor-nb.czech.sun.com:8080/WS1/NewWebService1 HTTP/1.1", but because IP
is obtained dynamically from DHCP, libor-nb.czech.sun.com is not assigned to my
IP and it doesn't work too.

So it works when proxy is on only if two conditions are fulfilled: 
1. there is correct host name in query
2. computer has static IP addres

It can be solved by not using proxy for localhost and use localhost and not
hostname in request.
Comment 26 L Martinek 2005-04-14 17:48:22 UTC
Created attachment 21657 [details]
TCP dump when proxy is turned on
Comment 27 _ ludo 2005-04-14 18:05:00 UTC
Great to know why!!!
When you say proxy, it is the proxy settings of the IDE itself?
Comment 28 _ pcw 2005-04-14 20:45:33 UTC
That's great that you found the problem.  We should be able to craft a solution
from that.  This prompts a new question though:  Why does it work the first time?

On a machine that could reproduce this, during the course of the test, no proxy
settings or server settings are ever changed.  Yet Test Operation works for the
first client until the second web application is deployed.  This seems very odd
to me.
Comment 29 Petr Blaha 2005-04-14 21:37:43 UTC
Yes, we are speaking about proxy in IDE, avalaible here Tools | Update Center |
Proxy Configuration.
Answer to Peter's question:
The first We sesrice worked since was created from local file, then we created
second web service from URL. Therefore, we should set up proxy before generation
second web service.
Comment 30 _ pcw 2005-04-15 02:00:53 UTC
Moving to Prague for finalization (release note or other appropriate action).
Comment 31 Sherold Dev 2005-04-15 10:16:24 UTC
Setting the RELNOTE keyword.
Comment 32 Petr Jiricka 2005-04-15 16:16:15 UTC
This was discussed more today in Prague, and we think the behavior could be
improved by adding the local machine (as localhost, 127.0.0.1 and real name) to
http.nonProxyHosts. Will attempt to fix after RC1.
Comment 33 Petr Jiricka 2005-04-18 17:20:26 UTC
Showstopper, raising priority to P1.
Comment 34 Petr Jiricka 2005-04-18 18:30:01 UTC
Attaching a fix that fixes this problem on Libor's machine.

The problem is that for some specific machine configurations, Java does not
correctly resolve the machine name, so the name is something like
localhost.czech.sun.com. When deploying the web service, appserver enters the
actual URL into the WSDL file as:

<soap:address location="http://localhost.czech.sun.com:8080/WebApp/WS" ... />

Next, when the web service registry in the IDE then tries to connect to this
URL, the Java HTTP client uses the proxy set by the IDE, and the proxy can
naturally not resolve the above machine name, so it returns HTTP error 500. This
then demonstrates itself as the exception.

The IDE used to have a way to set hosts for which proxy should not be contated
(the http.nonProxyHosts system property). This code is in
core/src/org/netbeans/core/IDESettings.java, but it looks like during recent
changes this code was deactivated (revision 1.63). So the code is to set
http.nonProxyHosts again, while also extending the value of this property to
include the host name for localhost is these weird machine configurations (like
Libor's machine).

QE verified that the attached patch resolves this problem.

Jesse and Jirka R., can you please review the patch, before it it put into the
trunk? Thanks.
Comment 35 Petr Jiricka 2005-04-18 18:32:38 UTC
Created attachment 21712 [details]
Patch for IDESettings (against both trung and release41 branch)
Comment 36 Jesse Glick 2005-04-18 19:03:16 UTC
Looks OK to me but it is Jirka who would know better.

Shouldn't the launcher try to detect the machine's proxy exclusions, too, for
use in autodetect mode? E.g. I see that core/launcher/unix/nbexec checks the
gconf keys /system/proxy/mode, /system/http_proxy/host, and
/system/http_proxy/port, yet it ignores /system/http_proxy/ignore_hosts, which
looks like what we want.
Comment 37 Jiri Rechtacek 2005-04-19 08:55:20 UTC
The fix is reasonable to me and the patch is correct. Please, apply it. I'll
attached the patch which allows to read ignoreHosts from system (on unix). IMHO
this fix in not needed in NB4.1, I'll change in later in main trunk. Thanks for
patch.
Comment 38 Jiri Rechtacek 2005-04-19 08:57:00 UTC
Created attachment 21715 [details]
patch reads IgnoreHost property from OS settings on unix
Comment 39 Petr Jiricka 2005-04-19 13:33:46 UTC
Fixed in trunk.

Checking in IDESettings.java;
/cvs/core/src/org/netbeans/core/IDESettings.java,v  <--  IDESettings.java
new revision: 1.66; previous revision: 1.65
done
Comment 40 L Martinek 2005-04-19 16:27:39 UTC
verified on trunk on continuous build 20050419-1321
Comment 41 Petr Jiricka 2005-04-20 07:43:35 UTC
Fixed also in the release41 branch.

Checking in IDESettings.java;
/cvs/core/src/org/netbeans/core/IDESettings.java,v  <--  IDESettings.java
new revision: 1.65.6.1; previous revision: 1.65
done
Comment 42 L Martinek 2005-04-20 14:46:07 UTC
verified in release41


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo