fiddler - No SOAP message exchange between Metro client and WCF service on 64Bit Win7 and Windows 2008 Server -

i have running web service connection between java client program metro {2.2.1-1} web service stack , wcf {.net 4.0 v30319} wshttpbinding web service on windows xp sp3.

if move exact same setup windows 7 {with enterprise setup} or windows 2008 r2 server sp1 {from ms dvd}, hanging requests java client wcf service. i.e. there no symptoms of data exchange between 2 partners {i have -dcom.sun.xml.ws.transport.http.client.httptransportpipe.dump=true on client side , diagnostic print messages on server side -- both without output}. networkologically, tcp connection open ("netstat -a") until timeout occurs after 200+-5 seconds following stack trace:

jul 19, 2013 12:13:00 pm ch.xxxxxxxx.xxxxx.balance.client.start.start main severe: null com.sun.xml.ws.streaming.xmlstreamreaderexception: xml reader error: com.ctc.wstx.exc.wstxioexception: connection reset     @ com.sun.xml.ws.streaming.xmlstreamreaderutil.wrapexception(xmlstreamreaderutil.java:326)     @ com.sun.xml.ws.streaming.xmlstreamreaderutil.next(xmlstreamreaderutil.java:99)     @ com.sun.xml.ws.streaming.xmlstreamreaderutil.nextcontent(xmlstreamreaderutil.java:169)     @ com.sun.xml.ws.streaming.xmlstreamreaderutil.nextelementcontent(xmlstreamreaderutil.java:104)     @ com.sun.xml.ws.wsdl.parser.runtimewsdlparser.parsebinding(runtimewsdlparser.java:584)     @ com.sun.xml.ws.wsdl.parser.runtimewsdlparser.parsewsdl(runtimewsdlparser.java:470)     @ com.sun.xml.ws.wsdl.parser.runtimewsdlparser.parseimport(runtimewsdlparser.java:427)     @ com.sun.xml.ws.wsdl.parser.runtimewsdlparser.parseimport(runtimewsdlparser.java:835)     @ com.sun.xml.ws.wsdl.parser.runtimewsdlparser.parsewsdl(runtimewsdlparser.java:464)     @ com.sun.xml.ws.wsdl.parser.runtimewsdlparser.parse(runtimewsdlparser.java:232)     @ com.sun.xml.ws.wsdl.parser.runtimewsdlparser.parse(runtimewsdlparser.java:192)     @ com.sun.xml.ws.wsdl.parser.runtimewsdlparser.parse(runtimewsdlparser.java:161)     @ com.sun.xml.ws.client.wsservicedelegate.parsewsdl(wsservicedelegate.java:328)     @ com.sun.xml.ws.client.wsservicedelegate.<init>(wsservicedelegate.java:290)     @ com.sun.xml.ws.client.wsservicedelegate.<init>(wsservicedelegate.java:217)     @ com.sun.xml.ws.client.wsservicedelegate.<init>(wsservicedelegate.java:199)     @ com.sun.xml.ws.client.wsservicedelegate.<init>(wsservicedelegate.java:195)     @ com.sun.xml.ws.spi.providerimpl.createservicedelegate(providerimpl.java:112)     @ javax.xml.ws.service.<init>(unknown source)     @ ch.xxxxxxxx.xxxxx.balance.client.systemintegrationservicebridge.<init>(systemintegrationservicebridge.java:50)     @ ch.xxxxxxxx.xxxxx.balance.client.start.start.main(start.java:37) caused by: com.ctc.wstx.exc.wstxioexception: connection reset     @ com.ctc.wstx.sr.streamscanner.constructfromioe(streamscanner.java:625)     @ com.ctc.wstx.sr.streamscanner.loadmorefromcurrent(streamscanner.java:1049)     @ com.ctc.wstx.sr.streamscanner.parselocalname2(streamscanner.java:1857)     @ com.ctc.wstx.sr.streamscanner.parselocalname(streamscanner.java:1817)     @ com.ctc.wstx.sr.basicstreamreader.handlestartelem(basicstreamreader.java:2925)     @ com.ctc.wstx.sr.basicstreamreader.nextfromtree(basicstreamreader.java:2817)     @ com.ctc.wstx.sr.basicstreamreader.next(basicstreamreader.java:1065)     @ com.sun.xml.ws.util.xml.xmlstreamreaderfilter.next(xmlstreamreaderfilter.java:96)     @ com.sun.xml.ws.streaming.xmlstreamreaderutil.next(xmlstreamreaderutil.java:80)     ... 19 more caused by: java.net.socketexception: connection reset     @ java.net.socketinputstream.read(unknown source)     @ java.net.socketinputstream.read(unknown source)     @ java.io.bufferedinputstream.fill(unknown source)     @ java.io.bufferedinputstream.read1(unknown source)     @ java.io.bufferedinputstream.read(unknown source)     @ sun.net.www.meteredstream.read(unknown source)     @ java.io.filterinputstream.read(unknown source)     @ sun.net.www.protocol.http.httpurlconnection$httpinputstream.read(unknown source)     @ com.ctc.wstx.io.basereader.readbytes(basereader.java:155)     @ com.ctc.wstx.io.utf8reader.loadmore(utf8reader.java:368)     @ com.ctc.wstx.io.utf8reader.read(utf8reader.java:111)     @ com.ctc.wstx.io.readersource.readinto(readersource.java:87)     @ com.ctc.wstx.io.branchingreadersource.readinto(branchingreadersource.java:57)     @ com.ctc.wstx.sr.streamscanner.loadmorefromcurrent(streamscanner.java:1046)     ... 26 more 

if terminate service during period, client stops waiting similar stack trace immediately, and, expected, no tcp connection existing anymore.
activating wcf logging (see http://msdn.microsoft.com/en-us/library/ms730064.aspx) shows log according wcf thinks, has delivered 3 parts of wsdl (/?wsdl, /?wsdl=wsdl0, /?wsdl=wsdl1) , successfully.
running administrator, uac switched off, doesn't matter, if have firewall off or on or if have ipv6 off or on. tried jre 7_u17 32bit, 7_u25 32bit , 7_u25 64bit.

soapui 4.5.1 communicates service locally on win7-oid platform.
wcf client communicates service locally , without proxy.
small java web service client using metro libraries, calling corresponding wcf web service locally, works fine.
if install http proxy fiddler on win7-oid platforms , reconfigure java client app use proxy {-dhttp.proxyhost=localhost -dhttp.proxyport=8888 -dhttp.nonproxyhosts=""}, fine.
if client side on xp box , service on w7oid 1 or other way around, remotely accessing wcf service works fine without tricks.

running out of imagination, may cause strange behaviour, i'd ask following questions:
- there out there, experienced similar problem
- propositions, windows mechanism interfere in described manner
- propositions, other experiments take on nearer solution
- additional diagnostic measures should take boil down problem [and solution, hope]

the symptoms above show, problem

• arises during retrieval of [parts of] wsdl
• occurs, when directly using w7oid network connection .

this gave rise of further analysis of happened on tcp level. first of all, not possible see local ip traffic of web service connection wireshark 1.10.2. ip traffic via physical ip interface not visible. also, of other @ least somehow freely available network anaysers did not seem support analysis of ip traffic on loopback interface of w7 , windows 2008 server.

finally, able bit of more insight trial versions of commview , localnetworkmonitor:

• also ip traffic, configured use physical ip interface [secretly] routed via local network stack if loopback connection.
• such loopback-like ip traffic seems work on technically different ip stack on w7oid platforms. otherwise, tools not distinguish between 2 situations.
• on tcp level, client begins opening http-tcp connection retrieve "?wsdl". ("?wsdl" contains references 2 large wsdl files "?wsdl=wsdl0" , "?wsdl=wsdl1") then, simultanously, client requests "?wsdl=wsdl0" on same first tcp connection (probably due keep-alive) , newly opened second tcp connection. 1 of these 2 connections hanging around unread , unterminated. after timeout of around 200 seconds, additional chunk of data gets on way , tcp connections both closed (immediately followed client stack trace above).

conclusions:
@ least http-keep-alive, standard setting wcf , metro, way, w7 , w2k8 server handle http-tcp traffic via loopback interface , way, wcf , metro expect it, not fit together.
in given scope, not possible boil down reason. however, seems w7 loopback network stack picky. network monitoring tools have severe problems offer correctly working solutions.

the workaround...
... configure web service channel physical ip interface , set high priority ip route on w7/w2k8 box, directs traffic interface via ip gateway. w2k8 have been forced refrain loopbacking , deliver ip traffic physical network interface via "usual" ip stack -- on everything, ie. web service , tools, works fine.