2010-07-30 11 views
1

Est-il possible de garder bien rangé le même nom de fil lors d'un appel RMI? En ce moment, si j'ai un fil nommé qui fait un appel RMI, du côté du serveur de l'appel RMI, Thread.currentThread().getName() quelque chose déclarations non illuminant comme « connexion TCP RMI (4) -10.0.0.2 ». Bien sûr, je pourrais aller ajouter à toutes mes méthodes RMI un paramètre String callingThreadName et faire la première ligne de chaque implémentation de la méthode RMI Thread.currentThread().setName(callingThreadName), mais ce n'est pas la meilleure façon de le faire. Est-il possible d'obtenir au moins une partie de la signification derrière le nom de thread transféré sur la connexion RMI?Garder le même nom de fil sur RMI

+0

Puis-je vous demander pourquoi vous voulez faire cela? Pourquoi le nom du thread gérant la requête côté serveur est-il important? Vous pourriez essayer de résoudre un effet secondaire quel que soit votre vrai problème. –

+0

Comme Romain l'a supposé plus bas, il s'agit principalement de suivre les threads de manière cohérente dans différents fichiers journaux. Le système est un calcul réparti - chaque machine worker crée un objet contenant une méthode appelée par plusieurs threads du maître pour effectuer le calcul réel. En raison de la nature du calcul, les threads doivent aller et venir entre le maître et les travailleurs, donc démarrer les threads sur le travailleur me laisserait avec le même problème sur le maître. – Scott

Répondre

0

Java RMI spécification stipule expressément qu'il n'y a aucune garantie sur la façon dont les appels clients sont mis en correspondance avec des threads du serveur. Vous ne pouvez donc pas faire d'hypothèses à ce sujet. Plus précisément, vous ne devriez pas essayer d'utiliser un identifiant de thread pour corréler les clients.

1

Ce que vous tryig à faire est de corréler les actions dans les différents processus tout en regardant les fichiers journaux. La meilleure façon d'y parvenir est d'ajouter un unique transaction_id à votre RPC qui est utilisé uniquement à cette fin. Cela vous permet de suivre le flux à travers le système.

+0

Il existe un ID de transaction unique, mais basé en partie sur le nom du thread (et généré sur le serveur). Même si un élément distinct a été généré et ajouté aux éléments qui ont été transmis, comment cela pourrait-il améliorer la solution suggérée dans la question d'origine (sinon, ce serait un paramètre supplémentaire à glisser dans les méthodes subsidiaires alors qu'un nom de thread vient "gratuitement"). – Scott

+0

@Scott Les threads sont généralement regroupés et, en plus, si vous utilisez RMI, vous travaillez sur plusieurs processus. Il n'y a aucun moyen de garder les ThreadIDs en synchronisation, sauf si vous transmettez une valeur à l'appelé pour changer le nom de Thread. De plus, puisque vous travaillez dans un ThreadPool, vous devrez définir le nom de chaque invocation. Il n'y a aucun avantage à essayer de le faire de toute façon. Passez un identifiant de transaction avec vos appels et dans votre appelé puis définissez une variable ThreadLocal si vous le souhaitez et utilisez-la. oublier l'identifiant ou le nom du thread. –