Ce type de connexions “RMI Connexion TCP(inactif)” thread correspondent?

Je suis en train de travailler sur un système distribué qui est RMI base à l'aide de jdk1.6.

De temps en temps je peux voir ConcurrentModificationException erreurs sur ce thread qui se passe au sein du RMI de l'exécution si elle ne parvient pas à sérialiser des objets. Je peux reproduire cette exception facilement en même temps la mise à jour de l'objet retourné par méthode à distance.

Mais le problème est que je ne peux pas trouver la source de ces appels. RMI exception est écrit à stderr (capturé sur le côté de serveur au sein d'exécution de code après sa sortie de télécommande méthode de l'objet), mais il n'y a pas de correspondance exception dans les services à la clientèle (alors que si c'était légitime d'appel à distance, RemoteException avec une raison valable serait soulevée).

La seule autre chose à propos de ces exceptions, c'est qu'ils sont en train d'arriver sur le "RMI Connexion TCP(inactif)" thread et non sur un fil comme "RMI Connexion TCP(<nombre de connexions>)-<client endpoint info>".

Des indices sur ce que sont ces "inactif" threads dans le RMI? Je n'ai pas réussi à trouver dans le cadre de l'openjdk sources.

Upd: je suis en ajoutant une trace de pile d'exception tel qu'il est reproduit, qui est ce que vous voyez habituellement dans la situation décrite.

Côté serveur de la console affiche:

Exception dispatching call to [-3534448f:12f54948b7f:-7fff, 349678755005857493] in thread "RMI TCP Connection(6)-x.x.x.x" at Thu Apr 14 16:15:13 BST 2011:
java.util.ConcurrentModificationException
at java.util.ArrayList.writeObject(ArrayList.java:573)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:274)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:315)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

Client la taille de l'exception levée de l'appelant:

java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
java.io.EOFException
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:173)
at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:178)
at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:132)
at $Proxy0.getData(Unknown Source)
at Clnt.main(Clnt.java:11)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:115)
Caused by: java.io.EOFException
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553)
at java.io.ObjectInputStream.skipCustomData(ObjectInputStream.java:1899)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1873)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:306)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:155)
... 9 more
Si RMI obtient une exception d'exécution lors de la sérialisation de la valeur de retour, il est déjà trop tard dans le protocole de sérialiser l'exception au lieu de cela, il est avalé. Vous pouvez poster une trace de la pile?
J'ai mis à jour le post avec les traces de pile sur les deux côtés. L'exception est avalé, mais côté client ne peut toujours pas désérialiser les résultats de la méthode de sorte qu'il jette une sous-classe de RÉ qui doit être vu quelque part dans les journaux du client.

OriginalL'auteur aliher | 2012-06-06

  1. 4

    De création de Threads RMI du pool de connexions avec le nom " RMI Connexion TCP(inactif)'. Lorsque l'un d'eux est utilisé, l'exécutable, il est utilisé pour exécuter renomme le fil de RMI Connexion TCP(n)' où n est le nombre de connexion traitées (un numéro séquentiel), et la renomme de retour à la "inactif" dans l'exécutable du bloc finally. De sorte que toute trace de l'étiquette d '"RMI Connexion TCP(inactif)" doit venir avant l'exécutable renomme un thread de connexion, ou après qu'il a été renommé en.

    Ne me demandez pas comment c'est possible. La véritable réponse à votre problème, si ce n'est de votre question, c'est de ne pas modifier les objets lorsqu'ils sont simultanément en cours de retour 😉

    Ouch! Comment ai-je négligé le renommage peu. Maintenant le nommage sens, mais semble encore plus étrange, car il ne devrait pas gérer les messages dans un état inactif. Je voudrais savoir quel objet est mutable, parce que nous ne défensive de la copie pour potentiellement mutables résultats pour l'en empêcher. J'espérais obtenir quelques indices en identifiant quels sont les points de terminaison de ce bavardage.
    J'ai trouvé comment faire des exceptions d'exécution pourrait s'infiltrer dans le pool de thread et a ajouté l'explication comme une réponse. Cela explique pourquoi le thread est inactif et pourquoi le point de terminaison de l'information est perdue en ce moment. Je dois donc attendre pour l'une des connexions client à l'échec et au journal. Peut-être un jconsole l'interrogation de haricots va donc jamais finir dans les journaux.

    OriginalL'auteur user207421

  2. 1

    J'ai au fond de lui. Le problème se produit dans deux cas:

    1. Quand marshaling une valeur de retour, déclenche une exception et l'exception à son tour contient un objet sujettes à des modifications concurrentes. UnicastServerRef essaie d'écrire la cause dans la (déjà corrompu) flux retour et les causes ConcurrentModificationException.
    2. Lorsque la méthode lève une exception et cette exception ne parvient pas à sérialiser avec ConcurrentModificationException (ou toute autre exception runtime).

      Cette exception va tout le chemin jusqu'à la pile et il est capturé et enregistré par le pool de thread, pas de RMI runtime (c'est pourquoi il n'y a pas de Exception dispatching call to ligne au début). Qui explique le nom du thread d'inactivité, car il est déjà retourné à la piscine de RMI point de vue.

    Voici la vraie exception qui est en fait un peu différent de ce que reproduit exception des spectacles dans des conditions de première ligne et d'appel de trace:

    Exception in thread "RMI TCP Connection(idle)" java.util.ConcurrentModificationException
at java.util.ArrayList.writeObject(ArrayList.java:573)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:343)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

    Il ne donne pas beaucoup d'indices pour le problème d'origine, donc je vais devoir attendre pour un client d'exception pour montrer jusqu'à un certain point pour résoudre ce problème.

    Si ce genre d'exception se produit lors de la lecture d'attribut JMX par jconsole, ça va pas montrer stacktrace, mais la valeur de l'attribut n'est pas disponible.

    OriginalL'auteur aliher