Cette section répertorie les bogues corrigés dans Directory Proxy Server version 6.3.1.
Si une source JDBC n'est pas disponible, la recherche échoue lorsque vous utilisez une vue de type JOIN (LDAP + JDBC), même si le système ne requiert aucune donnée provenant de cette source JDBC.
L'exécution de ldapsearch sur cn=monitor renvoie l'entrée de nœud terminal avant l'entrée parent, condition qui peut provoquer l'échec de certains outils.
Les modifications apportées via une vue de jointure de LDAP et JDBC peuvent déclencher une exception de pointeur NULL.
Si aucun attribut secondaire n'est nécessaire, les requêtes portant sur des sources de données secondaires ne doivent avoir aucun impact sur les performances.
Les tentatives d'application de deux modifications dans le cadre d'une même transaction LDAP peuvent n'avoir qu'un succès partiel si un attribut est absent.
Lorsque vous utilisez une vue de jointure de LDAP et JDBC, l'attribut objectclass ne peut pas être stocké dans la vue secondaire.
Lorsque vous effectuez une recherche via une vue de jointure, cette recherche doit être menée en premier sur la vue secondaire, dans le cas où aucun attribut issu de la vue principale ne figure dans le filtre de recherche (et ce, même si plusieurs entrées sont renvoyées depuis la vue secondaire).
Une charge de recherche trop élevée peut provoquer une exception de pointeur NULL.
Lors d'une recherche avec une vue de jointure de LDAP et JDBC, il est impossible de renvoyer une entrée si l'utilisateur de liaison n'a pas de droit d'accès sur les attributs secondaires requis.
Une recherche à forte charge peut déclencher des exceptions ArrayIndexOutOfBounds ou NegativeArraySizeException
L'ajout d'une entrée via une vue de jointure échoue si l'attribut uid contient des majuscules.
Lorsque vous ajoutez une entrée via une vue de jointure de LDAP et JDBC, cette entrée est ajoutée à la vue JDBC même si aucun attribut JDBC secondaire n'est inclus dans la requête d'ajout.
Lorsque vous ajoutez ou remplacez un attribut via une vue de jointure de LDAP et JDBC, la valeur est tronquée si elle est trop longue pour la base de données SQL.
Lorsque vous ajoutez une entrée via une vue de jointure de LDAP et JDBC, la taille de colonne n'est pas vérifiée avant la mise à jour ou l'ajout d'une valeur de chaîne (varchar ) provoquant une erreur de base de données.
Les tests à fort taux de recherches provoquent des erreurs inattendues, en raison d'une condition de compétitivité dans FailoverLoadBalancingAlgorithm.
Les recherches persistantes sur SSL ne renvoient pas de données.
La stratégie de gestion de la mémoire dans DPS provoque la déconnexion des connexions existantes au moment du déclenchement de GC (si la mémoire est faible).
Lorsque vous ajoutez une entrée, les valeurs de DN ne sont pas toujours converties en minuscules.
Lorsque vous supprimez un attribut partagé (qui existe dans deux sources de données) via une vue de jointure de LDAP et JDBC, une erreur est renvoyée si l'attribut n'existe pas dans l'une des deux vues.
La JVM peut s'arrêter brutalement en mode 64 bits avec JDK 1.6 si la charge de recherche est trop importante.
Lorsque la source JDBC traite ses valeurs de colonne avec respect de la casse (en DB2, notamment), la tentative de suppression d'une valeur d'attribut JDBC peut échouer.
Les sockets peuvent être bloqués à l'état CLOSE_WAIT, ce qui empêche le serveur de répondre.
Si les connexions au serveur sont trop souvent ouvertes et fermées, le serveur peut cesser de répondre après un moment, jusqu'à ce que vous le redémarriez.
Sous Linux AMD64, le serveur ne peut pas démarrer en mode 32 bits.
En cas de charge importante, le serveur peut connaître des problèmes de délai d'attente, qui obligent à retenter les opérations portant sur le serveur d'annuaire.
Lorsque vous utilisez une base mappée virtuellement dans un filtre de recherche, aucun résultat n'est renvoyé dans certaines circonstances.
Avec une vue de jointure, les modifications destinées à la vue de données secondaires peuvent être incorrectement routées vers la vue de données principale.
Si vous ne configurez pas de règle de jointure lorsque vous définissez une vue de jointure incluant une vue JDBC, une exception StringIndexOutOfBoundsException peut se produire.
Certains filtres de recherche spécifiques peuvent provoquer la génération d'erreurs de décodage par le serveur.
Lorsque vous utilisez une vue de jointure contenant une vue JDBC, toute tentative de suppression d'un attribut dans une entrée qui existe uniquement dans le service d'annuaire échoue.
La commande dpadm -V ne détecte pas la version de la JVM.
Le serveur peut laisser les connexions au serveur d'annuaire à l'état CLOSE_WAIT, ce qui empêche le serveur d'annuaire de répondre.
Un filtre de recherche contenant un attribut qui n'est pas de type chaîne (virgule flottante ou date, par exemple) risque de ne pas pouvoir extraire les résultats depuis la vue JDBC.
Les threads de travail internes peuvent être interbloqués, ce qui empêche le serveur de répondre.
Des pics de forte consommation de l'UC peuvent se produire sur le serveur, ce qui empêche tous les services de la machine de répondre.
Des améliorations ont été apportées à la gestion des connexions liées, afin de réduire le temps d'attente de fermeture.
ldapsearch peut renvoyer une valeur d'attribut vide pour une entrée issue du moteur de traitement JDBC MySQL, Derby ou DB2. Avec un moteur de traitement JDBC ORACLE, aucune valeur d'attribut vide n'est renvoyée.