[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Eureka!
Hi Richard
Thanks for investigating this. I've just realised how cool the WS-I testing tool is (the log file looked great once I installed all the XSL). I'll try to look into getting it installed on our environment.
If you saw my previous message, you'll know that your theory was correct, and our proxy was the source of the problems we were having when the HTTP 1.0 Keep-Alive header was sent. It's only our runtime component that uses connection persistence (for the initCookie / getMarkup / performBlockingAction) calls, and it's only in our internal testing environment where we need to use a proxy for this component. In the portalstandards.oracle.com environment, these calls do not need to be proxied.
The successful calls you have in your log file where the connection actually was persisted were made from the portalstandards environment. Here we are experiencing a different problem - the calls only work when we register with an IP address rather than a domain name. This is weird, because I can ping and telnet to the domain name from the same machine with no problems. Any ideas?
Thanks again
Dave
Richard Jacob wrote:
Hi David, what you state concerning HTTP keep-alive is correct. I'll try to summerize and reword to check if we have the same understanding: HTTP 1.0 is by default request/response oriented without keeping the connection open, thus every new request opens a new socket and closes this after the resonse is received. To keep the connection open among the request/response messages, the HTTP 1.0 client sends a connection: keep-alive header. If the server supports this it send a connection: keep-alive in the response to indicate that the connection is not closed and can be reused. HTTP 1.1 remains the connection open by default. The connection: keep-alive is nearly meaningless in HTTP 1.1. If the server wants to close the connection it sends connection: close in its response. If it doesn't do so, the connection is kept open. I checked the log files which monitored the conversation between our producer and your consumer and between our producer and Citrix's consumer (thanks Andre for driving that test). See attached files, 8082 is Citrix, 8083 is Oracle. (See attached file: log8082.xml)(See attached file: log8083.xml) In Citrix's case the keep-alive seem to work. Andre's messages start with message 13, which is conversation 12. As you can see all the request/response up to message 66 are in the same conversation, i.e. connection. 67 starts a new conversation (maybe because the client or server decided to close the connection in between). In Oracle's case we see a lot of different connections for each request/response. But interestingly messages 135-138 and 141-144 share the same connection. Looking at 1-134 it seems that you use a proxy in between for the conversation, see header: Via: 1.1 inet-nc02 (NetCache NetApp/5.3.1R3) In 135 you are using a direct connection (no via: header). That's a guess but maybe the proxy in between doesn't support keep-alive? or is a 1.0 server? Currently I have no idea why the connection is closed after 138 and reopened for 139/140 and then again for 141... Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com |---------+----------------------------> | | David Ward | | | <david.ward@oracl| | | e.com> | | | | | | 06/16/2003 10:12 | | | PM | |---------+----------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Richard Jacob/Germany/IBM@IBMDE | | cc: wsrp-interop@lists.oasis-open.org | | Subject: Re: [wsrp-interop] Verify interoperability with Oracle Portal | >--------------------------------------------------------------------------------------------------------------------------------------------------| Richard I am attaching the trace I got from a TCP tunnel when our Portal tries to make consecutive initCookie and getMarkup requests through the same pooled TCP connection. After further investigation, I found that the "Keep-Alive" value we send in the Connection header of the first request is actually HTTP 1.0 semantics that can be ignored by an HTTP 1.1 server. That's why it doesn't appear in the second request. An HTTP 1.1 server would return Connection: close if it doesn't want the connection to be kept open, since the default is that the connection is kept alive. An HTTP 1.0 server would set the Keep-Alive header on the response if it wanted the connection to be kept open. Because we get an HTTP 1.1 response with no Connection close header, our client assumes it can keep the connection open and send another request on it, but this doesn't seem to be working. We are using the same HTTPClient library we have relied on for years (not that that means it might not have bugs!). You can force your JVM to use it instead of the regular JDK HttpURLConnection by setting the java.protocol.handler.pkgs system property to HTTPClient. Thanks Dave David Ward wrote: Hi David, thanks. 1. yes we have this namespacing issue still open due to the JSR168 container reference implementation. Once this is changed on the container side we can skip the namespacing here. 2. strange, we tested with both AXIS HTTP1.0 -> no keep alive and with .NETs HTTP1.1 and keep alive set. Citrix's consumer also sets the keep-alive flag. Andre, can you confirm please, and rerun your consumer against our producer over the monitoring port (8082). David could you also try to connect via the monitoring port 8083, please. Maybe we discover something. I'll attach one WSI-monitor file showing a conversation between Citrix and IBM, here the keep alive seem to work. You should have the xsl files (from the WS-I monitor) placed in the directory "../xsl" relative to your log file directory to generate a user-friedly output. (See attached file: log8082.xml.030606150200.xml)(See attached file: assertions.xsl)(See attached file: common.xsl)(See attached file: log.xsl) (See attached file: report.xsl) Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com |---------+----------------------------> | | David Ward | | | <david.ward@oracl| | | e.com> | | | | | | 06/16/2003 11:37 | | | AM | |---------+----------------------------> > --------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Richard Jacob/Germany/IBM@IBMDE | | cc: wsrp-interop@lists.oasis-open.org | | Subject: Re: [wsrp-interop] Verify interoperability with Oracle Portal | > --------------------------------------------------------------------------------------------------------------------------------------------------| Thanks I have altered our WSDL to reference http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_bindings.wsdl in the import, and will make this fix available when we next patch our site! We got the IBM portlet displaying, but there's a few glitches I want to talk about. I'll investigate further as soon as I get the chance, but: The portlet seems to be namespacing the input fields in its form. Is this required? The producer can't seem to cope with HTTP 1.1 keep alive behaviour - we can only register the producer when we turn off connection pooling Regards David Richard Jacob wrote: Hi David, there is an absolut location for the wsdl. You can find them here: http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_types.xsd http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_interfaces.wsdl http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_bindings.wsdl See chapter 14 of the spec or the wsrp group's home page. Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com |---------+----------------------------> | | David Ward | | | <david.ward@oracl| | | e.com> | | | | | | 06/12/2003 02:21 | | | PM | |---------+----------------------------> > --------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Peter Fischer3/Germany/IBM@IBMDE | | cc: Michael Freedman <Michael.Freedman@oracle.com>, wsrp-interop <wsrp-interop@lists.oasis-open.org> | | Subject: Re: [wsrp-interop] Verify interoperability with Oracle Portal | > --------------------------------------------------------------------------------------------------------------------------------------------------| This is indeed a bug. We will need to fix the WSDL we return so that the imports actually resolve to a location on our webserver. It would be useful if there was an absolute location on OASIS that everyone could use in their imports. Regards David Peter Fischer3 wrote: Hi Mike, our consumer is having problems reading the wsdl you provided. It imports the binding wsdl like this: <import namespace="urn:oasis:names:tc:wsrp:v1:bind" location=" wsrp_v1_bindings.wsdl" /> but at this location (realtive to http://portalstandards.oracle.com/wsrp/jaxrpc?WSDL)no such document can be found. Should a WSRP consumer be able to handle that by using a local version of the wsdl or must the producer provide a correct / complete wsdl? Mit freundlichen Grüßen / Best Regards Peter "Don't think of the problem - think of the solution!" ;-) ___________________________________________________________________ IBM WebSphere Portal Development Boeblingen, Germany Phone: ++49-7031-16-4497 eMail: peter.fischer@de.ibm.com |---------+-----------------------------> | | Michael Freedman | | | <Michael.Freedman@| | | oracle.com> | | | | | | 06/10/2003 07:45 | | | PM | | | | |---------+-----------------------------> > -----------------------------------------------------------------------------------------------------------------------------| | | | To: WSRP <wsrp@lists.oasis-open.org>, wsrp-interop <wsrp-interop@lists.oasis-open.org> | | cc: | | Subject: [wsrp-interop] Verify interoperability with Oracle Portal | | | | | > -----------------------------------------------------------------------------------------------------------------------------| As of yesterday, Monday June9th, Oracle is publically hosting a pre-release version of its portal implementing the TC 1.0 WSRP specification so other vendors/customers can verify their implementations interoperate with Oracle. By making this publically available we hope to accelerate the use and implementation of interoperable WSRP producers. The site is available at: http://portalstandards.oracle.com. Additonal supporting information is available if you click on the "Go back to Oracle9iAS Portal Center" link on this sites welcome page. To use the site [to test your producer] you must be a logged in "Oracle Technology Network" user. Login accounts are free and available to all. Merely click on the "login" link in the upper right corner and either login to an existing account or sign up for a new one. Once logged in you will be able to register your producer(s) with the Oracle Portal and add portlets from this producer to your own sandboxed portal page. The site contains instructions on how to do this as well as an existing sample page containing portlets from the Oracle WSRP Sample Producer. This later is also hosted publically so other WSRP consumers can test if they work/interoperate with Oracle's WSRP/JSR 168 container. The WSDL for this producer is available at http://portalstandards.oracle.com/wsrp/jaxrpc?WSDL . Though the site requests problems/support issues be directed to discussion lists/support, we prefer you use the wsrp-interop@lists.oasis-open.org mailing list to communicate questions/issues/problems. Dave and I track this list more closely ensuring faster turn around on reported issues. -Mike- You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php -- |--------------------+---------------------------+-----------------------| | | | | | David Ward | Oracle European | | | Principal | Development Centre | | | Software Engineer | 520 Oracle Parkway | Email: | | Oracle Portal | Thames Valley Park | david | | | Reading | .ward | | | Berkshire RG6 1RA | @orac | | | UK | le.co | | | | m | | | | Tel: | | | | +44 | | | | 118 | | | | 924 | | | | 5079 | | | | Fax: | | | | +44 | | | | 118 | | | | 924 | | | | 5005 | | | | | | | | | |--------------------+---------------------------+-----------------------| You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php -- |--------------------+---------------------------+-----------------------| | | | | | David Ward | Oracle European | | | Principal | Development Centre | | | Software Engineer | 520 Oracle Parkway | Email: | | Oracle Portal | Thames Valley Park | david | | | Reading | .ward | | | Berkshire RG6 1RA | @orac | | | UK | le.co | | | | m | | | | Tel: | | | | +44 | | | | 118 | | | | 924 | | | | 5079 | | | | Fax: | | | | +44 | | | | 118 | | | | 924 | | | | 5005 | | | | | | | | | |--------------------+---------------------------+-----------------------| -- |--------------------+---------------------------+-----------------------| | | | | | David Ward | Oracle European | | | Principal | Development Centre | | | Software Engineer | 520 Oracle Parkway | Email: | | Oracle Portal | Thames Valley Park | david | | | Reading | .ward | | | Berkshire RG6 1RA | @orac | | | UK | le.co | | | | m | | | | Tel: | | | | +44 | | | | 118 | | | | 924 | | | | 5079 | | | | Fax: | | | | +44 | | | | 118 | | | | 924 | | | | 5005 | | | | | | | | | |--------------------+---------------------------+-----------------------| Listen Port: 2222 Target Host: wsrp.dyndns.org Target Port: 8083 ==== Request ==== POST /wsrp/wsrp4j/WSRPBaseService HTTP/1.1 Host: ukp16267.uk.oracle.com:2222 Connection: Keep-Alive, TE TE: trailers, deflate, gzip, compress User-Agent: RPT-HTTPClient/0.3-3 Oracle-ECID: 1055791210625ApplicationServerThread SOAPAction: "urn:oasis:names:tc:wsrp:v1:initCookie" Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress Content-type: text/xml; charset="utf-8" Content-length: 452 <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance" xmlns:ns0 ="urn:oasis:names:tc:wsrp:v1:types"> <env:Body> <ns0:initCookie> <ns0:registrationContext> <ns0:registrationHandle>192.168.200.1_1055790421716_9</ns0:registrationHandle> </ns0:registrationContext> </ns0:initCookie> </env:Body> </env:Envelope> POST /wsrp/wsrp4j/WSRPBaseService HTTP/1.1 Host: ukp16267.uk.oracle.com:2222 Connection: TE TE: trailers, deflate, gzip, compress User-Agent: RPT-HTTPClient/0.3-3 Oracle-ECID: 1055791210625ApplicationServerThread Cookie: JSESSIONID=5934EF2F75DD19FA504553E09B8C2527 SOAPAction: "urn:oasis:names:tc:wsrp:v1:getMarkup" Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress Content-type: text/xml; charset="utf-8" Content-length: 2360 <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance" xmlns:ns0 ="urn:oasis:names:tc:wsrp:v1:types"> <env:Body> <ns0:getMarkup> <ns0:registrationContext> <ns0:registrationHandle>192.168.200.1_1055790421716_9</ns0:registrationHandle> </ns0:registrationContext> <ns0:portletContext> <ns0:portletHandle>0.192.168.200.1_1055790532049_10</ns0:portletHandle> <ns0:portletState/> </ns0:portletContext> <ns0:runtimeContext> <ns0:userAuthentication>wsrp:password</ns0:userAuthentication> <ns0:portletInstanceKey>253_34169_253_1_1</ns0:portletInstanceKey> <ns0:namespacePrefix> __ns253_34169_253_1_1_</ns0:namespacePrefix> </ns0:runtimeContext> <ns0:userContext> <ns0:userContextKey>DXWARD4[1]</ns0:userContextKey> </ns0:userContext> <ns0:markupParams> <ns0:secureClientCommunication>false</ns0:secureClientCommunication> <ns0:locales>en-gb</ns0:locales> <ns0:mimeTypes>text/html</ns0:mimeTypes> <ns0:mimeTypes>text/xml</ns0:mimeTypes> <ns0:mimeTypes>text/vnd.oracle.mobilexml</ns0:mimeTypes> <ns0:mode>wsrp:view</ns0:mode> <ns0:windowState>wsrp:normal</ns0:windowState> <ns0:clientData> <ns0:userAgent>Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) RPT-HTTPClient/0.3-3</ns0:userAgent> <ns0:extensions> <oracle:GenericExtension xmlns:oracle=" http://xmlns.oracle.com/portal/wsrp/v1"> <ns0:NamedString name ="X-Oracle-Device.Orientation"> <ns0:value>landscape</ns0:value> </ns0:NamedString> <ns0:NamedString name ="X-Oracle-Device.MaxDocSize"> <ns0:value>0</ns0:value> </ns0:NamedString> <ns0:NamedString name="X-Oracle-Device.Class"> <ns0:value>pcbrowser</ns0:value> </ns0:NamedString> <ns0:NamedString name="X-Oracle-Device.Secure"> <ns0:value>false</ns0:value> </ns0:NamedString> </oracle:GenericExtension> </ns0:extensions> </ns0:clientData> <ns0:navigationalState></ns0:navigationalState> <ns0:markupCharacterSets>utf-8</ns0:markupCharacterSets> <ns0:validNewModes>wsrp:view</ns0:validNewModes> <ns0:validNewModes>wsrp:edit</ns0:validNewModes> <ns0:validNewModes>wsrp:help</ns0:validNewModes> <ns0:validNewWindowStates>wsrp:normal</ns0:validNewWindowStates> <ns0:validNewWindowStates>wsrp:maximized</ns0:validNewWindowStates> <ns0:validNewWindowStates>wsrp:minimized</ns0:validNewWindowStates> </ns0:markupParams> </ns0:getMarkup> </env:Body> </env:Envelope> ==== Response ==== HTTP/1.1 200 OK Transfer-Encoding: chunked Date: Mon, 16 Jun 2003 19:18:53 GMT Content-Type: text/xml; charset=utf-8 Set-Cookie: JSESSIONID=5934EF2F75DD19FA504553E09B8C2527; Path=/wsrp Server: Apache Coyote/1.0 Via: 1.1 inet-nc01 (NetCache NetApp/5.3.1R3) 14c <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv=" http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd=" http://www.w3.org/2001/XMLSchema" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <initCookieResponse xmlns="urn:oasis:names:tc:wsrp:v1:types"/> </soapenv:Body> </soapenv:Envelope> 0 HTTP/1.1 500 Server Error Date: Mon, 16 Jun 2003 19:18:54 GMT Content-Length: 263 Content-Type: text/html Server: NetCache appliance (NetApp/5.3.1R3) <HTML> <!-- $Id: //depot/prod/ontap/Rbrutus/prod/netcache/errors/500.html#1 $ --> <HEAD> <TITLE>500 Server Error</TITLE> </HEAD> <BODY> <H1>Server Error</H1> <H4>The following error occurred: <P>Bad URL</H4> <HR>Please contact the administrator.</BODY> </HTML> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
--
David Ward
Principal Software Engineer
Oracle Portal
Oracle European Development Centre
520 Oracle Parkway
Thames Valley Park
Reading
Berkshire RG6 1RA
UK
Email: david.ward@oracle.com Tel: +44 118 924 5079 Fax: +44 118 924 5005
| David Ward Principal Software Engineer Oracle Portal |
Oracle European Development Centre 520 Oracle Parkway Thames Valley Park Reading Berkshire RG6 1RA UK |
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]