2011-11-11 5 views
0

Nous avons un appel RMI qui doit terminer ou échouer en quelques secondes. Vous pouvez modifier le Socket utilisé pendant l'appel lui-même (y compris les délais d'attente de connexion et de lecture), mais l'appel Naming.lookup semble utiliser ses propres paramètres.Définir un sun.rmi.transport.tcp.handshakeTimeout pour un seul thread?

Réduire sun.rmi.transport.tcp.handshakeTimeout résout le problème, mais j'aimerais vraiment le faire d'une manière qui n'affecte pas la machine virtuelle entière. Pouvez-vous définir la propriété en tant que thread local?

La propriété et d'autres propriétés du RMI sont documentées que je trouve à http://download.oracle.com/javase/1.4.2/docs/guide/rmi/sunrmiproperties.html

+0

Le délai d'attente de prise de contact ne couvre pas l'appel etire, seul l'échange de protocole initial, la mise en sorte qu'il ne peut pas « résoudre le problème '. Il existe une propriété timeout de réponse non documentée, mais elle ne peut pas être définie par thread. Naming.lookup() ne fait rien de spécial à cet égard. – EJP

Répondre

0

D'accord, d'une façon laide d'y arriver. Le lookup est effectué en utilisant un Socket à partir d'un RMIClientSocketFactory que vous pouvez passer. L'usine renvoie un Socket avec votre configuration.

Malheureusement, cela ne vous fait pas beaucoup de bien, puisque la classe TCPChannel utilisé dans certains de RMI remplace votre configuration, y compris l'appel Socket.setSoTimeout(..) avec la valeur de handshakeTimeout.

Cependant, rien ne vous empêche de modifier l'usine pour retourner une sous-classe de Socket qui (en réécrivant setSoTimeout de ne rien faire par exemple.) Ne permet pas chaning soTimeout.

Avoir la source disponible pour la classe TCPChannel avéré très utile: http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Modules-sun/rmi/sun/rmi/transport/tcp/TCPChannel.java.htm

Questions connexes