10 Replies Latest reply: Jul 25, 2012 1:26 AM by Ron Sigal RSS

WorkerThread exception occured .... InvocationTargetException / SocketTimeoutException

red Car Newbie

Hallo,

 

my App calls only one method in a SFSB.

I can call this method for example 40 times in short time (per mouse click) and after this, I get a exception inside serverlog.

 

First the WorkerThread#1 closes a ServerSocketWrapper.

Second a WorkerThread#0 throws a exception occured during first invocation.

My Application is hanging until this exception is comming, after this, the calls are done successful.

The waiting time can be 60 seconds until the call ist fullfilled.

 

What's the reason of this error, and what can I do, to avoid this error?

Use: JBoss 5.1.0GA

 

Thank you,

Werner

 

=== snipp ===

 

2012-03-15 13:15:47,389 INFO  [STDOUT] (WorkerThread#0[192.168.7.3:2346]) -------> (86)ApplMeldMonitorBean.getCrossReferences ... done.

2012-03-15 13:15:47,389 DEBUG [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#0[192.168.7.3:2346]) WorkerThread#0[192.168.7.3:2346] closed socketWrapper: ServerSocketWrapper[Socket[addr=/192.168.7.3,port=2346,localport=4473].c627f5]

2012-03-15 13:15:49,530 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] (Thread-12) Periodic recovery - second pass <Do, 15 Mrz 2012 13:15:49>

2012-03-15 13:15:49,530 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] (Thread-12) AtomicActionRecoveryModule: Second pass

2012-03-15 13:15:49,530 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] (Thread-12) [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_6] - TORecoveryModule - second pass

2012-03-15 13:15:49,530 DEBUG [com.arjuna.ats.jta.logging.loggerI18N] (Thread-12) [com.arjuna.ats.internal.jta.recovery.info.secondpass] Local XARecoveryModule - second pass

2012-03-15 13:16:48,043 ERROR [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#1[192.168.7.3:2348]) WorkerThread#1[192.168.7.3:2348] exception occurred during first invocation

java.lang.reflect.InvocationTargetException

    at sun.reflect.GeneratedConstructorAccessor262.newInstance(Unknown Source)

    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

    at org.jboss.remoting.transport.socket.ServerThread.createServerSocketWrapper(ServerThread.java:909)

    at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:491)

    at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)

Caused by: java.net.SocketTimeoutException: Read timed out

    at java.net.SocketInputStream.socketRead0(Native Method)

    at java.net.SocketInputStream.read(SocketInputStream.java:129)

    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)

    at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)

    at java.io.BufferedInputStream.read(BufferedInputStream.java:317)

    at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2266)

    at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2279)

    at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)

    at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)

    at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)

    at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(ObjectInputStreamWithClassLoader.java:100)

    at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:54)

    at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:75)

    at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:58)

    at org.jboss.remoting.transport.socket.ClientSocketWrapper.createInputStream(ClientSocketWrapper.java:179)

    at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:162)

    at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)

    at org.jboss.remoting.transport.socket.ServerSocketWrapper.<init>(ServerSocketWrapper.java:46)

    ... 6 more

2012-03-15 13:16:48,043 DEBUG [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#1[192.168.7.3:2348]) WorkerThread#1[192.168.7.3:2348] closed socketWrapper: ServerSocketWrapper[null.0]

2012-03-15 13:16:52,340 DEBUG [org.jboss.ejb3.stateful.StatefulContainer] (WorkerThread#0[192.168.7.3:2435]) Received dynamic invocation for method with hash: 2241879895498260985

2012-03-15 13:16:52,340 DEBUG [org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor] (WorkerThread#0[192.168.7.3:2435]) ++++ LongLivedSessionPropagationInterceptor

2012-03-15 13:16:52,340 DEBUG [org.jboss.ejb3.interceptors.aop.InterceptorSequencer] (WorkerThread#0[192.168.7.3:2435]) aroundInvoke [advisedMethod=public java.util.Map com.gevas.jeb3.meld.session.bean.ApplMeldMonitorBean.getCrossReferences(long), unadvisedMethod=public java.util.Map com.gevas.jeb3.meld.session.bean.ApplMeldMonitorBean.getCrossReferences(long), metadata=[metaData={DISPATCHER={OID=[type=AS_ISvalue=jboss.j2ee:ear=MeldServer-1.2.1.19.ear,jar=MeldServer-1.2.1.19.ear,name=ApplMeldMonitorBean,service=EJB3]}, REMOTING={SUBSYSTEM=[type=AS_ISvalue=AOP], INVOKER_LOCATOR=[type=AS_ISvalue=InvokerLocator [socket://APPLIKATION:4473/?]]}, SFSBInvocation={SessionID=[type=AS_ISvalue=5c4o73-xs6k2h-gztrf7s6-1-gztrhdqx-a8]}, security={context=[type=MARSHALLEDvalue=[org.jboss.security.plugins.JBossSecurityContext()CLIENT)]]}, IS_LOCAL={GUID=[type=AS_ISvalue=jboss.j2ee:ear=MeldServer-1.2.1.19.ear,jar=MeldServer-1.2.1.19.ear,name=ApplMeldMonitorBean,service=EJB3,VMID=fcc850ec3650b463:-725119d8:1361646a53d:-7ff9]}, SessionInvocation={InvokedMethod=[type=AS_ISvalue=com.gevas.jeb3.meld.session.bean.ApplMeldMonitorRemote: com.gevas.jeb3.meld.session.bean.ICrossReference.getCrossReferences(long)]}}], targetObject=com.gevas.jeb3.meld.session.bean.ApplMeldMonitorBean@13ae670, arguments=[Ljava.lang.Object;@11b29ef]

2012-03-15 13:16:52,340 INFO  [STDOUT] (WorkerThread#0[192.168.7.3:2435]) -------> (86)ApplMeldMonitorBean.getCrossReferences ...

  • 1. Re: WorkerThread exception occured .... InvocationTargetException / SocketTimeoutException
    Ron Sigal Master

    Hi Werner,

     

    Well, I'm not sure what is going wrong, but I can describe the context.

     

    When the client does an invocation and there is no existing pooled connection, a new socket is created, on both the client side and the server side.  The client side creates an ObjectOutputStream and the server side creates a matching ObjectInputStream.  When the ObjectOutputStream is created, some header bytes are written, and the ObjectInputStream's constructor tries to read them.  For some reason, it is unable to read the header bytes, and eventually it times out.

     

    So you should look for something in your system that is preventing those header bytes from getting to the server.

     

    -Ron

  • 2. Re: WorkerThread exception occured .... InvocationTargetException / SocketTimeoutException
    red Car Newbie

    Hallo,

     

    now I have recognized the problem:

    The client instantiates a connection to the SFSB and holds it. Each call to this bean starts a new WorkerThread on the server with a new TCP/IP-Port.

    Because on the server-machine are running a lot of progs with many ports, I can run in a situation relative quickly, when a workerthread wants to

    hire an used port from another process. This will throw an InvocationTargetException and SocketTimeout Exception on the server, because he can not open his

    prefered port.

     

    Is there any possibility to set the range for workerthread-ports in a higher direction?

    Or is there any other possibility to avoid port-conflicts?

     

    Werner

  • 3. Re: WorkerThread exception occured .... InvocationTargetException / SocketTimeoutException
    Ron Sigal Master

    Hi Werner,

     

    re: "Each call to this bean starts a new WorkerThread on the server with a new TCP/IP-Port."

     

    The server has an upper limit on the number of worker threads that can be created, which can be modified by setting the parameter "maxPoolSize", so you might be on the right track.  If a client connects to the server and (1) all existing worker threads are in use, and (2) the number of worker threads has reached the upper limit, the server will wait for a worker thread to be returned to the pool.  But the stack trace in your first comment shows that the worker thread has alread been created, so that doesn't seem to fit your hypothesis.

     

    re: "This will throw an InvocationTargetException and SocketTimeout Exception on the server, because he can not open his prefered port."

     

    I'm not sure what you mean by "prefered port".

     

    re: "Is there any possibility to set the range for workerthread-ports in a higher direction?"

     

    No, the sockets used by the worker threads are created by ServerSocket.accept().

  • 4. Re: WorkerThread exception occured .... InvocationTargetException / SocketTimeoutException
    red Car Newbie

    Hallo Ron,

     

    you are right, the new port for workerthread is created by ServerSocket.accept(). That I meant with prefered.

     

    My very little test program can call for example the SFSB-method 24 times. In the server log I can see such lines:

    2012-03-15 13:16:52,340 INFO  [STDOUT] (WorkerThread#0[192.168.7.3:2435]) -------> (86)ApplMeldMonitorBean.getCrossReferences ...

    2012-03-15 13:16:53,340 INFO  [STDOUT] (WorkerThread#0[192.168.7.3:2436]) -------> (87)ApplMeldMonitorBean.getCrossReferences ...

     

    After some calls I can get this:

    WorkerThread#1[192.168.7.3:2437] exception occurred during first invocation java.lang.reflect.InvocationTargetException

     

    For example with netstat I can see, that 2437 is a used port. I am wondering that I could recognize that this port is used by my testprogram istself.

    But at this time the program will be blocked for some time. For test I have activated another network card, because I hoped, that with special IP and only one jboss-app on this IP,

    there should be no port problem anymore. But there is exactly the same problem.

     

    So, in the example the port 2437 blocks, and it is used by the pid itself. I don't understand this at the moment.

    You wrote first, that it could be, that there can not be sent this header-information during the socket-port-creation.

    Such thing should be impossible, it's crazy. The server and client are running on the same machine, no firewall or anything between.

    Although the program is running further after the socket timeout exception. I can call the method again until the next exception.

    And anyway, this problem I have not on my development machine, and not on some test machines, but on three customer machines.

     

    Werner

  • 5. Re: WorkerThread exception occured .... InvocationTargetException / SocketTimeoutException
    Ron Sigal Master

    Hi Werner,

     

    re: "For example with netstat I can see, that 2437 is a used port. I am wondering that I could recognize that this port is used by my testprogram istself"

     

    It really wouldn't do any good.  When you make a call on an EJB, it filters down to Remoting, which, if it can't find a pooled connection to reuse, will create a new socket, leading to ServerSocket.accept() returning a socket on the server. 

     

    It seems like something is preventing the client from completing the initialization of the connection, but I can't imagine what it is.  You could use Wireshark to monitor what bytes, if any, get sent from the client to the server.

     

    -Ron

  • 6. Re: WorkerThread exception occured .... InvocationTargetException / SocketTimeoutException
    red Car Newbie

    Hallo,

     

    now we have tried to attach jboss to another network interface. We enabled a second network card with another ip. Then I started the jboss with -b <another IP>.

    I wondered, that this do not help. I thought, Ports are unique to a network-card-ip.

     

    Now I have installed the JBoss on another server where he can work alone. This works fine. But I'm looking for another solution.

     

    Is there any possibility, to reduce the number of request-ports?

    At the moment I am experimenting with pooled Invoker.

     

    In conf/standardjboss.xml I have changed the sections for stateless and statefull ejb:

     

    <invoker-proxy-binding>
      <name>stateful-pooled-invoker</name>
      <invoker-mbean>jboss:service=invoker,type=pooled</invoker-mbean>
      <proxy-factory>org.jboss.proxy.ejb.ProxyFactory</proxy-factory>
      <proxy-factory-config>
        <client-interceptors>
          <home>
            <interceptor>org.jboss.proxy.ejb.HomeInterceptor</interceptor>
            <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
            <interceptor>org.jboss.proxy.ejb.SecurityContextInterceptor</interceptor>
            <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
            <interceptor call-by-value="false">org.jboss.invocation.InvokerInterceptor</interceptor>
            <interceptor call-by-value="true">org.jboss.invocation.MarshallingInvokerInterceptor</interceptor>
          </home>
          <bean>
            <interceptor>org.jboss.proxy.ejb.StatefulSessionInterceptor</interceptor>
            <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
            <interceptor>org.jboss.proxy.ejb.SecurityContextInterceptor</interceptor>
            <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
            <interceptor call-by-value="false">org.jboss.invocation.InvokerInterceptor</interceptor>
            <interceptor call-by-value="true">org.jboss.invocation.MarshallingInvokerInterceptor</interceptor>
          </bean>
        </client-interceptors>
      </proxy-factory-config>
    </invoker-proxy-binding>

     

     

    <invoker-proxy-binding>
      <name>stateless-pooled-invoker</name>
      <invoker-mbean>jboss:service=invoker,type=pooled</invoker-mbean>
      <proxy-factory>org.jboss.proxy.ejb.ProxyFactory</proxy-factory>
      <proxy-factory-config>
        <client-interceptors>
          <home>
            <interceptor>org.jboss.proxy.ejb.HomeInterceptor</interceptor>
            <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
            <interceptor>org.jboss.proxy.ejb.SecurityContextInterceptor</interceptor>
            <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
            <interceptor call-by-value="false">org.jboss.invocation.InvokerInterceptor</interceptor>
            <interceptor call-by-value="true">org.jboss.invocation.MarshallingInvokerInterceptor</interceptor>
          </home>
          <bean>
            <interceptor>org.jboss.proxy.ejb.StatelessSessionInterceptor</interceptor>
            <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
            <interceptor>org.jboss.proxy.ejb.SecurityContextInterceptor</interceptor>
            <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
            <interceptor call-by-value="false">org.jboss.invocation.InvokerInterceptor</interceptor>
            <interceptor call-by-value="true">org.jboss.invocation.MarshallingInvokerInterceptor</interceptor>
          </bean>
        </client-interceptors>
      </proxy-factory-config>
    </invoker-proxy-binding>

     

     

     

    <container-configuration>
      <container-name>Standard Stateless SessionBean</container-name>
      <call-logging>false</call-logging>
      <invoker-proxy-binding-name>stateless-pooled-invoker</invoker-proxy-binding-name>
      <container-interceptors>
        <interceptor>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor</interceptor>
        <interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor>
        <interceptor>org.jboss.ejb.plugins.security.PreSecurityInterceptor</interceptor>
        <interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor>
        <!-- CMT -->
        <interceptor transaction="Container">org.jboss.ejb.plugins.TxInterceptorCMT</interceptor>
        <interceptor transaction="Container">org.jboss.ejb.plugins.CallValidationInterceptor</interceptor>
        <interceptor transaction="Container">org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor</interceptor>
        <!-- BMT -->
        <interceptor transaction="Bean">org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor</interceptor>
        <interceptor transaction="Bean">org.jboss.ejb.plugins.TxInterceptorBMT</interceptor>
        <interceptor transaction="Bean">org.jboss.ejb.plugins.CallValidationInterceptor</interceptor>
        <interceptor>org.jboss.resource.connectionmanager.CachedConnectionInterceptor</interceptor>
      </container-interceptors>
      <instance-pool>org.jboss.ejb.plugins.StatelessSessionInstancePool</instance-pool>
      <instance-cache></instance-cache>
      <persistence-manager></persistence-manager>
      <container-pool-conf>
        <MaximumSize>100</MaximumSize>
      </container-pool-conf>
    </container-configuration>

     

    and

     

    <container-configuration>
      <container-name>Standard Stateful SessionBean</container-name>
      <call-logging>false</call-logging>
      <!-- invoker-proxy-binding-name>stateful-unified-invoker</invoker-proxy-binding-name -->
      <invoker-proxy-binding-name>stateful-pooled-invoker</invoker-proxy-binding-name>
      <container-interceptors>
        <interceptor>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor</interceptor>
        <interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor>
        <interceptor>org.jboss.ejb.plugins.security.PreSecurityInterceptor</interceptor>
        <!-- CMT -->
        <interceptor transaction="Container">org.jboss.ejb.plugins.TxInterceptorCMT</interceptor>
        <interceptor transaction="Container">org.jboss.ejb.plugins.CallValidationInterceptor</interceptor>
        <interceptor transaction="Container">org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor</interceptor>
        <!-- BMT -->
        <interceptor transaction="Bean">org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor</interceptor>
        <interceptor transaction="Bean">org.jboss.ejb.plugins.TxInterceptorBMT</interceptor>
        <interceptor transaction="Bean">org.jboss.ejb.plugins.CallValidationInterceptor</interceptor>
        <interceptor>org.jboss.resource.connectionmanager.CachedConnectionInterceptor</interceptor>
        <interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor>
        <interceptor>org.jboss.ejb.plugins.StatefulSessionSecurityInterceptor</interceptor>
      </container-interceptors>
      <instance-cache>org.jboss.ejb.plugins.StatefulSessionInstanceCache</instance-cache>
      <persistence-manager>org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager</persistence-manager>
      <container-cache-conf>
        <cache-policy>org.jboss.ejb.plugins.LRUStatefulContextCachePolicy</cache-policy>
        <cache-policy-conf>
          <min-capacity>50</min-capacity>
          <max-capacity>1000000</max-capacity>
          <remover-period>1800</remover-period>
          <max-bean-life>1800</max-bean-life>
          <overager-period>300</overager-period>
          <max-bean-age>600</max-bean-age>
          <resizer-period>400</resizer-period>
          <max-cache-miss-period>60</max-cache-miss-period>
          <min-cache-miss-period>1</min-cache-miss-period>
          <cache-load-factor>0.75</cache-load-factor>
        </cache-policy-conf>
      </container-cache-conf>
      <container-pool-conf>
        <MaximumSize>100</MaximumSize>
      </container-pool-conf>
    </container-configuration>

     

    With this configuration change I hoped, that I get a pooled connection for ejb 3.0.

    But it seems, that there is something wrong because I still get information, that each request starts a new WorkerThread with a different port:

     

    2012-03-23 09:26:11,359 INFO  [STDOUT] (WorkerThread#1[192.168.1.24:2025]) sayHallo: + 90

    2012-03-23 09:26:11,374 INFO  [STDOUT] (WorkerThread#0[192.168.1.24:2026]) sayHallo: + 91

    2012-03-23 09:26:11,374 INFO  [STDOUT] (WorkerThread#1[192.168.1.24:2027]) sayHallo: + 92

    2012-03-23 09:26:11,374 INFO  [STDOUT] (WorkerThread#0[192.168.1.24:2028]) sayHallo: + 93

     

    Next notice was, that ~ port 4500 the client port is created from ~ 1000 to 4500 and so on.

    But after ~ 4000 fast calls to my test method I get a new exception:

     

    org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [socket://HELIOTROP:3873/?]

        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:776)

        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)

        at org.jboss.remoting.Client.invoke(Client.java:1724)

        at org.jboss.remoting.Client.invoke(Client.java:629)

        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)

        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)

        at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)

        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)

        at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)

        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)

        at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)

        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)

        at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)

        at $Proxy3.invoke(Unknown Source)

        at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)

        at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)

        at $Proxy2.sayHallo(Unknown Source)

     

    After this exception I can call my ejb.method again until the next exception.

    This exception I also will get, if I use the unchanged standardjboss.xml configuration.

     

    My question:

     

    Is something wrong with my pooled Invoker configuration?

    Is this CannotConnectException normal, that I have to expect, or is this only occuring with my special test?

    Where can I configure the parameter for the pooled Invoker? For example port and pool-size?

     

    Thank you,

    Werner

  • 7. Re: WorkerThread exception occured .... InvocationTargetException / SocketTimeoutException
    red Car Newbie

    Hallo,

     

    is it possible to configure JBoss, that he uses not so much worker-threads?

    Or that the worker-thread uses ports only in a short range?

     

    Thank you,

    Werner

  • 8. Re: WorkerThread exception occured .... InvocationTargetException / SocketTimeoutException
    Ron Sigal Master

    Hi Werner,

     

    Sorry for the delay.  Have you made any progress?

     

    1) The pooled invoker isn't part of Remoting, and I'm not very familiar with it.  I don't believe it is used by default in any Application Server subsystem.

     

    2) There is no way in Java to control the ports assigned by ServerSockets.  However, the range can be set at the operating system level.  For example, see http://http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html

     

    -Ron

  • 9. Re: WorkerThread exception occured .... InvocationTargetException / SocketTimeoutException
    red Car Newbie

    Hallo Ron,

     

    very interesting this ephemeral ports document.

    It could be a good help, because I have recognized, that on Windows 2008 server I have none problems with blocking.

    In Windows 2003 server there is only a range of ca. 3000 ports for uses with client socket ports.

    We want try to change this range.

     

    Thank you for help,

    Werner