Cette section décrit les problèmes connus de gestion du cycle de vie et les solutions associées.
Après avoir défini minimum-delivery-interval de la propriété ejb-timer-service sur 9000, la tentative de définition de redelivery-interval-in-mills sur 7000 pour ejb-timer-service entraîne l'échec de la commande set avec l'erreur suivante :
[echo] Doing admin task set [exec] [Attribute(id=redelivery-interval-internal-in-millis) : Redelivery-Interval (7,000) should be greater than or equal to Minimum-delivery-interval- in-millis (9,000)] [exec] CLI137 Command set failed. |
minimum-delivery-interval correspond à l'intervalle de temps minimal entre chaque distribution d'une même horloge.
redelivery-interval-in-mills indique le délai pendant lequel le service d'horloge attend avant d'effectuer une nouvelle tentative de distribution suite à l'expiration de la valeur ejbTimeout.
La relation entre la propriété de l'intervalle de redistribution et celle de l'intervalle de livraison minimal n'étant pas logique, il vous est impossible d'utiliser l'interface graphique (IG) ou l'interface de ligne de commande (CLI) pour définir un intervalle de livraison minimal supérieur à celui de redistribution.
minimum-delivery-interval-in-millis doit toujours être égal ou supérieur à redelivery-interval-in-millis pour la propriété ejb-timer-service. Cependant, un contrôle de validité erroné s'effectue dans Application Server pour vérifier que la valeur de redelivery-interval-in-millis est supérieure à la valeur de minimum-delivery-interval-in-millis.
Utilisez les valeurs par défaut suivantes :
minimum-delivery-interval(default)=7000 redelivery-interval-in-millis(default)=5000 |
Toute autre valeur provoquera une erreur.
Si vous essayez d'afficher les destinations physiques JMS à l'aide de default-config, un message d'erreur apparaîtra.
Ce comportement est normal. Dans serveur d'application 9.1 Update 1, default-config est un modèle d'informations de configuration, par conséquent, les opérations JMS (telles quelist et create) ne peuvent pas être exécutées pour default-config. En revanche, ces opérations peuvent être exécutées pour la configuration de vos instances autonomes ou clusterisées.
(Windows 2003 uniquement) Des fuites de mémoire se produisent sur les systèmes Windows 2003 lors de l'exécution de fonctions richaccess. Ce problème est dû à la croissance continue du pool non paginé Win32, qui peut provoquer une panne de la pile TCP/IP complète. Une fois l'erreur générée, la pile TCP/IP demeure dans un état récupérable, et la seule manière de la restaurer est de redémarrer le système Windows 2003.
Il existe deux solutions à ce problème.
Utilisez le mode de blocage Grizzly en configurant l'attribut http-listener de domain.xml , blocking-enabled="true" ou ajoutez la propriété http-listener suivante :
<property name="blocking" value="true"/> |
Utilisez Windows Vista ou Windows XP.