Le passage de SAS© 9.4 ou de SAS© Viya™ 3.5 vers SAS© Viya™ 4 représente une révolution architecturale. En devenant "Cloud-Native", SAS© a abandonné le serveur monolithique traditionnel pour s'appuyer sur Kubernetes, un orchestrateur de conteneurs.
Dans ce nouvel écosystème, chaque action de l'utilisateur (comme l'ouverture d'une session ou l'exécution d'un programme) déclenche une cascade d'événements : le service de lancement sollicite Kubernetes pour créer un "Pod" de calcul, lequel doit être provisionné, démarré et mis en réseau avant que le code ne puisse réellement s'exécuter.
Cette architecture offre une flexibilité sans précédent. Cependant, elle introduit une nouvelle variable : le temps de latence opérationnelle. Contrairement à un serveur qui "tourne" déjà, un conteneur peut mettre plusieurs secondes à sortir de terre, surtout si le cluster doit ajouter de nouvelles ressources physiques (Auto-scaling).
C'est ici qu'intervient le mécanisme de Long Polling. Pour garantir une interface fluide, SAS© Studio maintient une communication constante avec ces micro-services. Mais si le dialogue entre l'interface web et le moteur de calcul prend un instant de trop, la connexion est rompue par sécurité. C'est précisément ce qui génère l'erreur que nous allons traiter.
Lors de l'exécution d'un programme ou de l'initialisation d'une session dans SAS© Studio (version 2024.x / 2025.x), le message suivant apparaît :
Pourquoi cette limite ?
Par défaut, SAS© Studio est configuré pour attendre une réponse du serveur de calcul pendant un maximum de 30 secondes. Si le Pod de calcul met 31 secondes à s'initialiser (à cause d'un réseau lent, d'un cluster chargé ou d'un script autoexec volumineux), l'interface web considère que la communication a échoué, même si le calcul finit par démarrer en arrière-plan.
Pour stabiliser l'environnement, la solution consiste à augmenter le seuil de tolérance de l'interface. Le paramètre technique dédié est le sas©.studio.longPollingHoldTimeSeconds.
Configuration : Cliquez sur l'icône Configuration (la clé à molette) dans le volet de gauche.
Bien qu'augmenter ce délai règle l'erreur immédiate, il est conseillé de surveiller les points suivants pour une performance optimale :
Vérifier l'Auto-scaling : Si vos nœuds mettent systématiquement plus de 60 secondes à démarrer, contactez votre administrateur Cloud pour ajuster la réactivité du cluster.
Optimiser l'Autoexec : Évitez de placer des assignations de bibliothèques lourdes (type accès bases de données distantes) dans le fichier de démarrage si elles ne sont pas nécessaires à chaque session.
Ressources Kubernetes : Assurez-vous que les "Resource Quotas" ne freinent pas le démarrage des Pods de calcul par manque de CPU.
L'erreur des 30 secondes n'est pas un bug du code SAS©, mais un réglage de synchronisation entre l'interface web et l'infrastructure moderne. En ajustant le Long Polling, vous offrez à votre infrastructure la souplesse nécessaire pour orchestrer ses ressources sans interrompre le travail des utilisateurs.
