Exécution d'une classe thread comme un démon

Question

Je suis en train d'écrire une solution multi-thread en Java pour connecter deux systèmes, A & B. Le système A est completly série, pas enfilée, et fournira des données à transmettre au système B. Le système B accepte les données provenant de sources multiples de manière asynchrone tous en même temps.

J'utilise ThreadPoolExecutor pour gérer les threads. J'utilise une instance singleton statique d'une classe, TP, qui s'enroule autour ThreadPoolExecutor (qui est aussi statique) parce que le système A ne peut pas créer de nouveaux objets, mais il peut faire des appels à des objets statiques.

Voici où je suis coincé. Je fais quelques tests très basique de l'installation avant que je parte tout. J'ai créé deux classes pour les tests, T1 et T2. Chacune de ces classes importe la classe TP (où le singleton est créé). T1 ajoute des objets dans la file d'TP puis T2 ajoute un peu plus.

Même si l'objet TP est déclarée comme statique, il semble qu'il y ait deux versions en cours d'exécution en parrallèle. Les objets soumis à la file d'attente en T2 sont exécutés avant que l'objet présenté par T1 ont tous été exécutés. En outre, étant donné que ni T1 ou T2 arrêt des appels () sur le ThreadPoolExector, ils ont tous deux suspendus et ne se terminent.

Comment puis-je créer une instance statique démon d'une bande de roulement qui se réveille au fond chaque fois que je vous envoie quelque chose à traiter, même de différentes executables Java?

Answer 1

Si vous utilisez deux processus distincts, vous avez deux types distincts et deux instances distinctes, peu importe que ce soit un singleton.

Si vous voulez deux processus différents pour communiquer entre eux, vous devrez répondre à cette question tout à fait séparément. Il y a beaucoup de différents mécanismes IPC disponibles -. Réseaux, les pipes nommés (difficiles de Java IIRC), la mémoire des fichiers mis en correspondance, un simple répertoire partagé où un processus place des tâches pour l'autre à traiter etc

Il est aussi ne sait pas exactement ce qui est suspendu, ou comment est configuré votre fil piscine. Si le problème est vraiment du côté filetage (plutôt que du côté IPC), alors s'il vous plaît envoyer un court mais complet programme qui illustre le problème.

Answer 2

Si la taille du pool de threads est supérieur à 1, il n'y a aucune garantie que tous les objets T1 seront traitées en priorité.

Answer 3

Il me semble que vous utilisez deux différentes classes « principaux » que chaque utilise cette même classe statique singleton. Dans ce cas, il y aura deux instances du singleton créé - un dans chaque machine virtuelle Java.

Je pense que ce que vous voulez faire est d'avoir le pool de threads encapsulé dans un autre processus qui fonctionne comme un service et expose un mécanisme pour IPC comme Skeet a commenté. Une façon courante de faire cela serait d'exposer une file d'attente JMS pour recevoir des demandes de différents producteurs et ont le consommateur (daemon) envoyer les demandes qu'il reçoit au pool de threads pour le traitement.

Pour l'exécution de ce service comme un démon, vous pouvez l'héberger dans un conteneur ou d'utiliser quelque chose comme Java service Wrapper si vous utilisez Windows.