java - 在 JAX-WS 中禁用 SSL 套接字连接池？

Question

我想知道是否可以在 JAX-WS 中禁用套接字连接池？

我正在从 Jetty 中调用网络服务。 Web 服务被设计为在任何给定时间最多有两个到服务器的连接。其中一个连接是阻塞连接，用于与服务器进行发布/订阅轮询。另一个连接用于发出标准的 SOAP 请求。一旦连接轮询，就不能再使用其他连接进行轮询，否则服务器会返回错误。

为此，我创建了两个 SOAP 端口，其中一个用于轮询，另一个用于发出请求。在轮询器返回一些数据并且 SOAP 请求连接处于空闲状态之前，这种方法非常有用。发生这种情况时，下次我尝试使用相同的 SOAP 端口进行轮询时，它会从连接池中选择一个连接并重新使用它。如果恰好获得了 SOAP 请求连接，则服务器返回一个错误。从那时起，轮询器就死机了，因为我创建的任何新 SOAP 端口最终都会重用这两个连接之一，这两个连接都被认为对轮询无效。

一个可能的解决方案是禁用连接池，这意味着每次我创建一个新的 SOAP 端口时，它都会建立一个新的连接。要么，要么是一种获取套接字本身的方法，我可以强行关闭它。

可能还值得一提的是，与服务器的连接是相互验证的 SSL 连接。

仅供引用，这是我尝试连接的服务器的规范:

http://www.trustedcomputinggroup.org/files/resource_files/93C23F2A-1A4B-B294-D0A36CCD8A9E7BD3/TNC_IFMAP_v2_0R0_47.pdf

任何帮助将不胜感激!谢谢，编码(marshal)

Answer 1

在尝试了许多不同的方法后，我找到了解决问题的方法。不幸的是，我无法弄清楚如何禁用连接池。如果有人知道该怎么做，我想听听解决方案。

我最终创建了我自己的自定义 SSL 套接字工厂，它充当默认 SSL 套接字工厂的传递，我在 HttpsURLConnection 类上设置了它:

SSLContext context = SSLContext.getInstance("TLS");
context.init(new KeyManager[] { new ClientKeyManager() }, 
    new TrustManager[] { new ClientTrustManager() }, 
    new SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(new ManagedSSLSocketFactory(context.getSocketFactory()));

请注意，我从 SSLContext 类传入默认套接字工厂。 ManagedSSLSocketFactory 的代码如下所示:

private class ManagedSSLSocketFactory extends SSLSocketFactory
{
    private SSLSocketFactory m_socketFactory;

    public ManagedSSLSocketFactory(SSLSocketFactory socketFactory)
    {
        m_socketFactory = socketFactory;
    }

    @Override
    public Socket createSocket(Socket s, String host, int port, boolean autoClose) throws IOException
    {
        Socket socket = m_socketFactory.createSocket(s, host, port, autoClose);

        //Note that m_arcThread, m_arcSocket, etc are defined in the containing class
        if(Thread.currentThread() == m_arcThread)
        {
            if(m_arcSocketInvalid || (socket == m_ssrcSocket))
            {
                closeSocketQuietly(socket);
                return createSocket(s, host, port, autoClose);
            }
            m_arcSocketInvalid = false;
        }

        ... omitted some convoluted code that deals with edge cases

        return socket;
    }

    ... rest of implementation

}