[ https://issues.jboss.org/browse/JBWS-3202?page=com.atlassian.jira.plugin.... ] Mustafa Musaji updated JBWS-3202: --------------------------------- Attachment: example.zip The files needed to replicate this issue -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBWS-3202?page=com.atlassian.jira.plugin.... ] Richard Opalka edited comment on JBWS-3202 at 1/24/11 9:45 AM: --------------------------------------------------------------- Remoting transport have been removed years ago from JBossWS trunk (community). We're using JBoss Netty nowadays. Regarding this issue (after exhaustive debugging) here's my conclusion: There's no way to reuse SSL connections when using remoting API. I first thought we're using remoting API in wrong way but this wasn't the case. We're using remoting the following way: HTTPRemotingConnection.invoke() { ... org.jboss.remoting.Client client = new Client(locator, "jbossws", clientConfig); client.connect(); client.setMarshaller(marshaller); client.setUnMarshaller(unmarshaller); Object resMessage = client.invoke(reqMessage, metadata); // MicroRemoteClientInvoker.invoke() { // ... // String sessionId = invocationReq.getSessionId(); // returnValue = transport(sessionId, payload, metadata, marshaller, unmarshaller); // HTTPClientInvoker.transport() { // ... // final HttpURLConnection conn = createURLConnection(validatedUrl, metadata); // HTTPSClientInvoker.createURLConnection() { // HttpURLConnection conn = super.createURLConnection(url, metadata); // HTTPClientInvoker.createURLConnection() { // ... // return new URL(url).openConnection(); // ... // } // ... // HttpsURLConnection sconn = (HttpsURLConnection) conn; // sconn.setSSLSocketFactory(sslSocketFactory); // setHostnameVerifier(sconn, metadata); // ... // } // ... // OutputStream stream = getOutputStream(conn); // marshaller.write(invocation, stream); // ... // InputStream is = (responseCode < 400) ? conn.getInputStream() : conn.getErrorStream(); // result = unmarshaller.read(is, map); // ... // // Here leaks conn object - known issue // } // ... // } client.disconnect(); ... return resMessage; } In short we're doing whole this procedure on each invocation. I first thought that reusing remoting Client (pooling) could solve this problem. But after investigation of remoting code base remoting is always calling new URL(targetURL).openConnection() and there's no way to reuse this created connection outside of remoting. I copied/pasted relevant bits of remoting code base above (in form of comments) so you can see what's happening inside of remoting2. was (Author: richard.opalka(a)jboss.com): Remoting transport have been removed years ago from JBossWS trunk (community). We're using JBoss Netty nowadays. Regarding this issue (after exhaustive debugging) here's my conclusion: There's no way to reuse SSL connections when using remoting API. I first thought we're using remoting API in wrong way but this wasn't the case. We're using remoting the following way: HTTPRemotingConnection.invoke() { ... org.jboss.remoting.Client client = new Client(locator, "jbossws", clientConfig); client.connect(); client.setMarshaller(marshaller); client.setUnMarshaller(unmarshaller); Object resMessage = client.invoke(reqMessage, metadata); // MicroRemoteClientInvoker.invoke() { // ... // String sessionId = invocationReq.getSessionId(); // returnValue = transport(sessionId, payload, metadata, marshaller, unmarshaller); // HTTPClientInvoker.transport() { // ... // final HttpURLConnection conn = createURLConnection(validatedUrl, metadata); // HTTPSClientInvoker.createURLConnection() { // HttpURLConnection conn = super.createURLConnection(url, metadata); // HTTPClientInvoker.createURLConnection() { // ... // return new URL(url).openConnection(); // ... // } // ... // HttpsURLConnection sconn = (HttpsURLConnection) conn; // sconn.setSSLSocketFactory(sslSocketFactory); // setHostnameVerifier(sconn, metadata); // ... // } // ... // OutputStream stream = getOutputStream(conn); // generates SSL handshake // marshaller.write(invocation, stream); // ... // InputStream is = (responseCode < 400) ? conn.getInputStream() : conn.getErrorStream(); // result = unmarshaller.read(is, map); // ... // // Here leaks conn object - known issue // } // ... // } client.disconnect(); ... return resMessage; } In short we're doing whole this procedure on each invocation. I first thought that reusing remoting Client (pooling) could solve this problem. But after investigation of remoting code base remoting is always calling new URL(targetURL).openConnection() and there's no way to reuse this created connection outside of remoting. I copied/pasted relevant bits of remoting code base above (in form of comments) so you can see what's happening inside of remoting2. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBWS-3202?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3202: --------------------------------------- -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBWS-3202?page=com.atlassian.jira.plugin.... ] Richard Opalka commented on JBWS-3202: -------------------------------------- JBoss WS (series 3.1.2x and before) transport delegates to JBoss Remoting and remoting uses URL facade for SSL communications. In order to reuse created SSL connections we would need access to JBoss Remoting created URLConnection objects. Unfortunately because of JBoss Remoting API design we don't have access to URLConnection objects that are created internally and thus we cannot reuse SSL sessions. In Java SSL session is created (in HttpsUrlConnectionImpl) when user is calling conn.getOutputStream(). If there's cached SSL session/connection it's reused. But Remoting is always creating new URL connection on each invocation request. This causes SSL handshakes on every request :( -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira