Discussion :

[biozaxx]

Bonjour,

voici mon problème:
j'obtiens une erreur de type "java.net.SocketException: Broken pipe" sur une application serveur client.(stacktrace ci après)

Le serveur renvoie au client des objets plus ou moins volumineux (quelques 100aines de Ko jusqu'a 10Mo).
Le truc c'est que cela fonctionne sans problème lorsque l'application tourne sur le réseau local de l'entreprise.
Ca fonctionne également lorsqu'on contacte le serveur via un VPN.

Par contre j'obtiens l'erreur des que le serveur applicatif est déployé chez notre hébergeur ET que la taille des données dépasse les 6Mo !!!

L'application utilise le framework hibernate, C3P0 pour le pool de connexion et le serveur applicatif est un Tomcat 5.5
La configuration du tomcat est identique en locale et sur le serveur distant ainsi que la configuration du C3P0 (même timeout, max_size etc)
La seule différence est que, sur le serveur distant, un apache se trouve en frontal du tomcat (mod_jk) et qu'en local le serveur tourne sous Windows alors qu'en distant c'est un serveur linux (debian)


J'ai Googlé pas mal le sujet et les causes énumérées sont :
fermeture de la connexion par le client (mais j'aurai le problème à chaque fois non ?)
problème due au mod_jk
configuration du timeout du c3p0 (mais à configuration identique je n'ai pas le problème en local)

donc je ne sais plus trop où chercher : si vous avez des suggestions elles seront les bienvenues

merci

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
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
 
ClientAbortException:  java.net.SocketException: Broken pipe
	at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:366)
	at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:433)
	at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:348)
	at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:392)
	at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:381)
	at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:88)
	at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:161)
	at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:118)
	at java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:72)
	at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
	at java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
	at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1685)
	at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1594)
	at java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1173)
	at java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1127)
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
	at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1398)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:305)
	at com.aureus_pharma.aurquest.profiler.ProfilerServlet.doPost(ProfilerServlet.java)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at com.aureus_pharma.aurquest.SecurityFilter.doFilter(SecurityFilter.java)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
	at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)
	at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
	at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
	at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
	at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
	at java.lang.Thread.run(Thread.java:595)
Caused by: java.net.SocketException: Broken pipe
	at java.net.SocketOutputStream.socketWrite0(Native Method)
	at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
	at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
	at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:531)
	at org.apache.jk.common.JkInputStream.doWrite(JkInputStream.java:147)
	at org.apache.coyote.Response.doWrite(Response.java:559)
	at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:361)
	... 39 more
Sep 22, 2008 12:09:42 PM org.apache.jk.core.MsgContext action
WARNING: Error sending end packet
java.net.SocketException: Broken pipe
	at java.net.SocketOutputStream.socketWrite0(Native Method)
	at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
	at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
	at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:531)
	at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:112)
	at org.apache.jk.core.MsgContext.action(MsgContext.java:293)
	at org.apache.coyote.Response.action(Response.java:182)
	at org.apache.coyote.Response.finish(Response.java:304)
	at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:204)
	at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
	at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
	at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
	at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
	at java.lang.Thread.run(Thread.java:595)
Sep 22, 2008 12:09:42 PM org.apache.jk.common.ChannelSocket processConnection
WARNING: processCallbacks status 2

[tchize_]

quel est le temps nécessaire à ton application pour générer la réponse. Si modjk bufferise le résultat et que le résultat est long à envoyer par tomcat, le client peut s'impatienter et couper la connexion, incitant modjk à faire de même avec tomcat.

autre possibilité, modjk a une taille de travail max et coupe quand c'est trop gros.
autre possibilité, la version de modjk dans apache ne correspond pas à celle dans tomcat (çà peut poser des problèmes).

Y a-t-il des messages dans les logs d'apache, qui expliqueraient le comportement de modjk? Le client recoit-il une réponse partielle ou rien?

[biozaxx]

bonjour tchize_

merci pour ces réponses rapides.
Le serveur peut mettre plus d'une dizaine de minutes pour renvoyer la réponse (oui c'est beaucoup )

Au premier abord je dirai qu'il n'y a aucun retour coté client , meme partiel.
je vais essayé de récuperer les logs apache pour voir si il y a quelque chose ainsi que la configuration du modjk.

je te tiens au courant dès que j'ai les info.

encore merci

++

[tchize_]

Le serveur peut mettre plus d'une dizaine de minutes pour renvoyer la réponse (oui c'est beaucoup )

Quand même oO !

Je parierais pour un timeout dans apache. Mais tu peux vraiment pas accélérer le processus? Eventuellement faire des flush de la réponse régulièrement, histoire d'envoyer des cacahuete à manger à apache.

[biozaxx]

oui c'est une application scientifique qui demande de gros traitement

je suis toujours en attente des logs et de la configuration du mod_jk par notre hebergeur

[biozaxx]

tchize_ ,

quand tu parles de "taille de travail max" tu penses a quelle propriété ? max_packet_size ?
visiblement cette valeur n'est pas definie dans le worker.properties qui est utilisé (cf ci dessous)

la version du mod_jk est la 1.2.5

concernant les log il n'y a rien coté client (j'ai vérifié)
pour apache je n'ai toujours pas les logs.

dans quel fichier je peux trouver le parametre de timeout (s'il existe) pour apache ? et quel est son nom ?

en ce qui concerne la possiblilté de faire des flush regulierement c'est quel que chose qui est prevu dans les versions a venir mais qui necessite de revoir la "strategie" de l'application

merci pour ton aide

[tchize_]

par taille de travail, (malheureux terme de ma part), j'entendais (il était tard ^^) un temps de travail maximum, donc un timeout du script en quelque sorte. Je connais pas les détails de modjk, désolé.

[biozaxx]

bonjour,

j'ai enfin les log je les post ci dessous

dans le fichier work.properties rien ne conserne les timeout donc je suppose que c'est les valeurs par default qui sont utilisées (donc illimité ?)

Dans le mod_jk.log j'obtiens les erreurs suivantes :

Code :

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

1
2
3
4
5
 
[Tue Sep 30 15:19:04 2008]  [jk_ajp_common.c (1052)]: ERROR sending data to client. Connection aborted or network problems
[Tue Sep 30 15:19:04 2008]  [jk_ajp_common.c (1303)]: ERROR: Client connection aborted or network problems
[Tue Sep 30 15:19:04 2008]  [jk_ajp_common.c (1529)]: Into jk_endpoint_t::done, closing connection 0
[Tue Sep 30 15:19:04 2008]  [jk_ajp_common.c (605)]: In jk_endpoint_t::ajp_close_endpoint

Eb lisant ceci j'ai l'impression que c'est le client qui demande la fermeture mais pourtant j'ai des sessions equivalentes qui ne sont pas fermées quand je bypass apache en local

Coté client il n'y a rien du tout

Coté Tomcat

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
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
 
2008-09-30 15:19:04,032 ERROR TP-Processor7 ProfilerServlet:? - 
ClientAbortException:  java.net.SocketException: Broken pipe
	at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:366)
	at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:433)
	at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:348)
	at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:392)
	at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:381)
	at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:88)
	at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:161)
	at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:118)
	at java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:72)
	at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
	at java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
	at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1685)
	at java.io.ObjectOutputStream$BlockDataOutputStream.writeByte(ObjectOutputStream.java:1723)
	at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1397)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:305)
	at com.aureus_pharma.aurquest.profiler.ProfilerServlet.doPost(ProfilerServlet.java)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at com.aureus_pharma.aurquest.SecurityFilter.doFilter(SecurityFilter.java)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
	at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)
	at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
	at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
	at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
	at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
	at java.lang.Thread.run(Thread.java:595)
Caused by: java.net.SocketException: Broken pipe
	at java.net.SocketOutputStream.socketWrite0(Native Method)
	at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
	at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
	at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:531)
	at org.apache.jk.common.JkInputStream.doWrite(JkInputStream.java:147)
	at org.apache.coyote.Response.doWrite(Response.java:559)
	at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:361)
	... 35 more
Sep 30, 2008 3:19:04 PM org.apache.jk.core.MsgContext action
WARNING: Error sending end packet
java.net.SocketException: Broken pipe
	at java.net.SocketOutputStream.socketWrite0(Native Method)
	at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
	at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
	at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:531)
	at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:112)
	at org.apache.jk.core.MsgContext.action(MsgContext.java:293)
	at org.apache.coyote.Response.action(Response.java:182)
	at org.apache.coyote.Response.finish(Response.java:304)
	at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:204)
	at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
	at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
	at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
	at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
	at java.lang.Thread.run(Thread.java:595)
Sep 30, 2008 3:19:04 PM org.apache.jk.common.ChannelSocket processConnection
WARNING: processCallbacks status 2

merci pour votre aide

[elmor]

Il y a un peut-être un firewall entre les deux qui est configuré pour fermer les socket qui restent ouvertes trop longtemps.

Certains administrators n'aiment pas que des sockets restent longtemps ouvertes. Ca expliquerait pourquoi la socket est fermée qu'a partir d'une certaine taille et donc d'une certain temps...

[tchize_]

il faudrait voir si tu sais pas modifier le code pour envoyer des espaces régulièrement

Il faudrait utiliser un sniffer coté client, pour essayer de voir si des paquets transittent pendant le temps d'attente ou pas. Si c'est pas le cas, çà peut même carrément être un routeur faisant du NAT qui coupe :p

[superloulou]

Merci d'indiquer une solution si vous en avez trouvé une

[Bobsinglar]

Bonjour,

J'ai le même problème, mais en local, sans apache. Donc e pense que cette piste est mauvaise.


Ma config :
- Eclipse/Tomcat 6 sous Linux ubuntu
- appli struts2+Hibernate3+C3PO

Je pense que le souci viens de C3PO voire d'hibernate. Mais je sèche.

Avez-vous une idée ?

merci

[Bobsinglar]

D'après ce post : http://www.mikeschubert.com/archives...tsocketex.html

ce serait un problème de transaction hibernate non committé ou non rollbacké.

Je vais vérifier mon code.