Récemment, j’ai fait des tests sur la consommation de fichiers depuis un process OSB en passant par un FileAdapter. La consommation se déroule bien, en revanche, j’ai remarqué l’apparition de stuck threads sur le serveur …
Je vais commencer par faire un rapide tutorial décrivant la création du FileAdapter et l’utilisation au sein du processus OSB, ensuite un descriptif de l’erreur rencontrée et enfin comment résoudre ce problème.

Création du FileAdapter et utilisation

Comme tous les adaptateurs de ressources que l’on souhaite utiliser dans l’OSB, il est nécessaire de passer par une première étape de configuration de l’adaptateur sous JDeveloper avant d’importer les fichiers générés dans Eclipse.

La création de l’adaptateur est très intuitive sous JDeveloper, laissez-vous guider et suivez les différentes étapes.
Une fois l’adaptateur configuré, 2 fichiers sont alors générés :

• .jca : porte la configuration : répertoire de polling, intervalle, etc.
• .wsdl : description du Web Service généré

Copiez les 2 fichiers générés ainsi que le ou les schémas XML importés dans le WSDL et les coller dans votre projet Eclipse sous un répertoire Adapter :

 
A présent, le Proxy Service consommant les fichiers va pouvoir être généré de la façon suivante :

Le process OSB est donc prêt à être publié et à consommer les fichiers …

Erreur rencontrée

Bizarrement, suite au déploiement d’un tel process, j’ai constaté l’apparition de Stuck Threads sur le serveur OSB …
Je l’ai constaté dans un premier temps au travers de la console puis via les logs du serveur :

####<6 août 2010 15 h 12 CEST> <Error> <WebLogicServer> <s1237.gie.intra>
<osb_server1> <[ACTIVE] ExecuteThread: '21' for queue: 'weblogic.kernel.Default
(self-tuning)'>
<<WLS Kernel>> <> <cefb2b0b2d922bac:6fbad928:12a4778ff86:-7fef-00000000000003cb>
<BEA-000337> <[STUCK] ExecuteThread: '0' for queue:
'weblogic.kernel.Default (self-tuning)'
has been busy for "960" seconds working on the request
"weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl@100a294",
which is more than the configured time (StuckThreadMaxTime)
of "900" seconds. Stack trace:
java.lang.Object.wait(Native Method)
oracle.tip.adapter.file.inbound.FilesToProcess.dequeueToProcess
(FilesToProcess.java:101)
oracle.tip.adapter.file.inbound.ProcessWork.run(ProcessWork.java:269)
weblogic.work.ContextWrap.run(ContextWrap.java:41)
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run
(SelfTuningWorkManagerImpl.java:528)
weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

J’ai d’abord augmenté la propriété StuckThreadMaxTime mais rien n’a changé …

Correction de l’erreur

J’ai trouvé, dans une documentation Oracle, un cas similaire avec l’adaptateur de base de données. Dans cette documentation, Oracle propose une explication ainsi qu’un correctif permettant d’éviter l’apparition du Stuck Threads.
Documentation Oracle : http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/jcatransport/transport.html
L’explication est toute simple, l’adaptateur n’utilise par défaut qu’un seul thread consommant les fichiers. L’adaptateur ne libérant jamais ce thread, il est normal de voir apparaître ce genre d’erreurs dans les logs …
La solution est de configurer un Work Manager et de l’utiliser au niveau du proxy consommant les fichiers. Le Work Manager va permettre de définir des contraintes sur les threads exécutés par le serveur Weblogic.
Dans Environment > Work Managers, créez un nouveau Work Manager :

J’ai appelé le mien FilesPollingWorkManager.
Configurez ce Work Manager en cochant la case « Ignore Stuck Threads » et sauvegardez :

Le Work Manager est donc opérationnel et peut à présent être utilisé dans le proxy de consommation des fichiers.
Enfin, il faut spécifier dans le proxy l’utilisation du Work Manager :

Suite à la republication de ce process OSB de consommation de fichiers, je n’ai plus constaté d’erreurs de ce genre dans les logs du serveur.