Discussion :

[polysil]

Bonjour,

Je recherche des personnes qui auraient réussi à faire fonctionner une application ASP .NET 4.5 chez OVH avec leur offre mutualisé Windows + base de données MySQL.

En effet depuis plusieurs mois j'ai des problèmes déconnexion entre l'application web et le serveur MySQL mais le support OVH ne m'aide pas vraiment à diagnostiquer ce qui ne va pas (pour eux tout est ok).

Ils ont réalisé une analyse de mon code (très basique) et n'ont rien trouvé d'incorrect.

J'utilise VS2010, connecteur .NET MySQL.
Je déploie tout ça (fichier .asp et répertoire bin) dans le dossier www de l'hébergement et bien sur dans le web.config, je mets à jour les informations de connexion telles que préconisées par OVH.

Tout semble fonctionner mais régulièrement, le serveur MySQL me déconnecte ce qui me provoque des exceptions lors du parcours des données issues d'une requête.

Bref, je recherche qqu'un qui aurait réussi à faire fonctionner ça chez OVH pour "comparer" les paramètres et éventuellement identifier ce qui ne va pas.

Merci par avance pour votre aide.

P.

[Immobilis]

Salut,

Difficile à dire avec si peu de détails. As-tu les messages d'erreur?

Tu peux essayer la plateforme Azure: http://www.windowsazure.com/fr-fr/

A+

[youtpout978]

Salut,
à quel moment ça merde ? en plein milieu de la requête ?
je suis chez ovh aussi sauf que j'ai une base SQL-server et aucun problème, sinon peut être un problème avec la dll qui gère MySQL ?

[polysil]

Bonjour,

Le problème survient généralement en plein parcours du "DataReader".
En effet MySQL clos la connexion côté serveur et du coup mon application plante car le connexion réseau est interrompue.

Selon le support OVH, quelque chose ne va pas du côté de mon code ou de ma connectionString mais je n'arrive pas à identifier quoi.

J'aimerais bien un exemple de code qui fonctionne pour identifier où sont les écarts.

A+

[Immobilis]

Le problème survient généralement en plein parcours du "DataReader".

On pourrait avoir le bout de code?

[polysil]

Voici un extrait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
 MySqlConnection conn = new MySqlConnection();
 conn.ConnectionString = m_connectionString;
 MySqlCommand cmd = new MySqlCommand();
 
 conn.Open();
 cmd.Connection = conn;
 
 cmd.CommandText = "MyStoredProcedure";
 cmd.CommandType = CommandType.StoredProcedure;
 
 MySqlDataReader myReader = cmd.ExecuteReader();
 while (myReader.Read())
 {
      // Lecture des informations
      string x = myReader.GetString(1);
      [...]
      --> Ca plante généralement pendant le traitement du while
  }
 
  myReader.Close();
  conn.Close();

Je précise juste que des fois ça fonctionne parfaitement et de fois non.
OVH m'a informé que le serveur coupait la connexion au bout de 60 sec ce qui correspond bien au problème.

Le hic c'est que à chaque appel de la procédure stockée, je crée normalement une nouvelle connexion. Donc je ne devrais pas avoir de timeout.

Chez OVH, je déploie mon propre connecteur .NET pour MySQL (issu du site MySQL) mais je pense que c'est pas la bonne approche.

A+

[Immobilis]

le serveur coupait la connexion au bout de 60 sec ce qui correspond bien au problème

Pas très sympa surtout si tu es en train de récupérer des donnée. Toutefois 60s c'est déjà pas mal. Comment peux-tu avoir une requête qui prend autant de temps? Ne devrais-tu pas diminuer ce délais plutôt?

[polysil]

En fait ma requête ne prend pas 60 sec. Elle est extrêmement basique et donc rapide. Mais elle est appelée plusieurs fois.
Et donc au bout de 60 sec, la n-ème requête va planter.
Les n-1 vont fonctionner mais la n-ème va échouer.
D'où mon soucis.

Le hic, comme je le disais, c'est qu'à chaque appel, je recrée une connexion je fais le boulot et je ferme la connexion donc je devrais avoir un délais de 60 sec à chaque appel mais ça n'est pas le cas. C'est ça le problème.

A+

[DotNetMatt]

Est-ce qu'on peut avoir le message d'erreur exact ?

[polysil]

C'est du genre :

MySql.Data.MySqlClient.MySqlException
(0x80004005): Fatal error encountered during command execution. ---> MySql.Data.MySqlClient.MySqlException (0x80004005): Fatal error encountered attempting to read the resultset. ---> MySql.Data.MySqlClient.MySqlException (0x80004005): Reading from the stream has failed. ---> System.IO.EndOfStreamException: Attempted to read past the end of the stream.

ou bien

System.ArgumentNullException: Value cannot be null.
Parameter name: dataReader
at System.Data.Common.DataAdapter.Fill(DataTable[] dataTables, IDataReader dataReader, Int32 startRecord, Int32 maxRecords)
at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
at System.Data.Common.DbDataAdapter.Fill(DataTable[] dataTables, Int32 startRecord, Int32 maxRecords, IDbCommand command, CommandBehavior behavior)
at System.Data.Common.DbDataAdapter.Fill(DataTable dataTable)
at
MySql.Data.MySqlClient.ISSchemaProvider.GetTable(String sql)
at
MySql.Data.MySqlClient.ISSchemaProvider.GetProcedures(String[] restrictions)
at
MySql.Data.MySqlClient.SchemaProvider.GetSchema(String collection, String[] restrictions)
at
MySql.Data.MySqlClient.MySqlConnection.GetSchema(String
collectionName, String[] restrictionValues)
at
MySql.Data.MySqlClient.ProcedureCache.GetProcData(MySqlConnection connection, String spName)
at
MySql.Data.MySqlClient.ProcedureCache.AddNew(MySqlConnection connection, String spName)
at
MySql.Data.MySqlClient.ProcedureCache.GetProcedure(MySqlCo
nnection conn, String spName, String cacheKey)
at
MySql.Data.MySqlClient.StoredProcedure.GetParameters(String procName, DataTable& proceduresTable, DataTable& parametersTable)
at
MySql.Data.MySqlClient.StoredProcedure.CheckParameters(String spName)
at
MySql.Data.MySqlClient.StoredProcedure.Resolve(Boolean preparing)
at
MySql.Data.MySqlClient.MySqlCommand.ExecuteReader(CommandBehavior behavior)

[DotNetMatt]

Merci ! Quelques questions :
- Est-ce que tu ouvres ta connexion puis la ferme à chaque fois ? Ou bien est-ce que tu l'ouvres pour qu'elle reste ouverte longtemps ?

- Est-ce que ton objet MySqlConnection est utilisé par plusieurs objets MySqlCommand ? Ou bien est-ce que chaque objet MySqlCommand a son propre objet MySqlConnection ?

- Quelle version du connecteur utilises-tu ?

[polysil]

La connexion est ouverte puis fermée à chaque appel de la procédure stockée.
Dans l'extrait de code que j'ai posté, je n'ai que des variables locales donc il n'y a pas de "persistance" de l'objet MySqlConnection et cet objet n'est pas partagé entre plusieurs appels à la base de donnée.

J'ai testé plusieurs versions du connecteur MySQL et le problème est identique quel que soit la version du connecteur (6.4.x -> 6.6.x).

Je dois quand même préciser que j'utilise chez OVH l'offre hébergement mutualisé windows et donc que je n'ai pas mon propre serveur MySQL.

A+

[Immobilis]

J'ai vaguement l'impression que l'exécution de la procedure stockée ne renvoit pas d'enregistrement tout simplement.

Considérant l'usage de ressources externes disposable il faut être prudent. Peux-tu ré-écrire ta fonction en l'implémentant avec des using? Voir la FAQ: http://dotnet.developpez.com/faq/asp...#adonet_select

C'est une bonne pratique qui te garanti que tu libères bien tes objets de la mémoire. Tu n'es pas obligé d'utiliser la fabrique est les interfaces mais au moins sers-toi des using comme indiqué.

[DotNetMatt]

Je suis tout à fait d'accord avec Immobilis, il ne faut surtout pas hésiter à utiliser ce mot clef.

En furetant sur Google, je m'apperçois que ce bug semble connu, car il y a des tickets ouverts auprès de MySQL à ce sujet.

Essaie de personnaliser le paramètre next_xxx_timeout :

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
using (var cmd = new MySqlCommand("set net_write_timeout=99999; set net_read_timeout=99999", con ))
{
}

(A défaut de faire une commande juste pour ça, il faut rajouter les deux instructions set avant ta requête. Je pense que si tu les met au début de ta procédure stockée, ça marche aussi).


Deux autres questions en passant
- Combien de lignes es-tu censé récupérer ?
- Y'a-t-il un firewall entre toi et le serveur MySQL ?

[polysil]

La première approche était bien d'utiliser les directives "using" mais suite à ce problème nous avons modifié de nombreuses fois le code jusqu'à l'amener à un niveau plus "simple".

Je vais essayer de remettre ça en place avec "set net_write_timeout=99999; set net_read_timeout=99999"

Dans la base de donnée, il y a seulement une centaine de lignes contenant 4 int et 5 chaines de moins de 64 caractères. Donc c'est vraiment très faible en volume.

Il n'y a aucun firewall entre moi et le serveur web et normalement aucun proxy entre le serveur web et le serveur MySQL (mais là, tout est chez OVH donc je n'ai aucune visibilité).

A+

[Immobilis]

Ce message

System.IO.EndOfStreamException: Attempted to read past the end of the stream

indique que tu essaye de lire les données alors que tu es arrivé au bout du flux. Un reader ne revient pas au début, il est en avant seulement.
Ce message

System.ArgumentNullException: Value cannot be null.
Parameter name: dataReader
at System.Data.Common.DataAdapter.Fill(DataTable[] dataTables, IDataReader dataReader, Int32 startRecord, Int32 maxRecords)

indique que tu essayes d'utiliser le datareader dans un dataadapter. Peut-être que tu le fais au mauvais moment.

[polysil]

J'ai simplifié le cas d'erreur. J'ai une simple page asp qui possède un timer et qui va déclencher 60x une requête.
Résultat : Ca va planter de façon aléatoire (jamais sur le même nombre d'itération).
Le problème ne vient pas des données ni de la façon dont l'appel à la base est effectué puisque :

• A chaque appel on va créer une nouvelle connexion, faire la requête, lire les résultats
• Cela fonctionne de façon unitaire
• Cela fonctionne plusieurs fois de suite
• Ca plante dès que le serveur met fin à la connexion

Je pense que c'est l'accès à la base de donnée qui pose soucis.

[Immobilis]

une requête

Toujours la même?

[polysil]

Oui c'est toujours la même.
Rien ne change entre les différents appels.

[Immobilis]

Le problème ne vient pas des données ni de la façon dont l'appel à la base est effectué

On peut quand même voir la totalité de la méthode Insert?