Peut-un long transfert de fichiers est géré par un cluster de serveurs (Tomcat) où si un serveur tombe en panne / accidents pendant le téléchargement, l'autre ramasse

Question

Qu'est-ce qui se passe lorsque Tomcat échoue au cours du processus de téléchargement. Est-ce simplement jeter une erreur de 50X. Est-il possible de gérer correctement la défaillance du serveur et en avant le reste de la requête à un autre serveur.

Answer 1

Je ne sais pas tomcat spécifiquement, mais c'est une connexion TCP. Si le téléchargement échoue, la connexion TCP baisserait. Le client cesse le téléchargement.

Si le client a une nouvelle tentative des capacités qui lui permettent de redémarrer un téléchargement à une position donnée dans le fichier, il pourrait être relancé avec un nouveau serveur. En général, ce n'est pas une capacité commune de clients Web, de nombreux sites avec des grands fichiers ont des clients flash qui intègrent la reprise de téléchargement.

Si vous voulez faire cela avec plus de transparence, alors vous pouvez avoir une interface web qui surveille les flux TCP et TCP maintient l'état. Si elle constate un échec, il pourrait transférer cet état vers un nouveau serveur, et passer le afflueront pour continuer le téléchargement comme si le flux TCP n'a jamais été cassé en premier lieu.

Il n'est pas trivial cependant, et n'introduit un nouveau point de défaillance. Le principal avantage est qu'il va travailler avec un client, tant que le client ne baisse pas la connexion (il ne peut résoudre les défaillances du serveur de votre côté, ne pas reprendre les téléchargements interrompus du côté client)

-Adam

Answer 2

On dirait que vous avez besoin d'une sorte d'un équilibreur de charge / basculement . Fondamentalement, une machine qui agit comme un front-end à plusieurs ordinateurs - il écoute le trafic de l'extérieur, et le transmet aux noeuds (Computes) à l'intérieur d'un cluster. Si un nœud échoue, il sait comment rediriger le trafic vers un autre ordinateur. Ce serait donc, exiger que tous les nœuds seraient synchronisés les uns avec les autres, de sorte que de telles transactions que les transmissions TCP peuvent se poursuivre sans sauter un battement.

Ceci est le plus souvent mis en œuvre dans le matériel plutôt que logiciel. Pas très trivial à mettre en œuvre, dans tous les cas.