Thread: java.net.SocketException: Broken pipe
I'm running an engine with 15 databases, with fair amount of load. Every 4-5 days I'm getting error like this from the java side and the application stops working (and wont come back unless I restart the webapplication): 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 java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:110) at java.io.FilterOutputStream.write(FilterOutputStream.java:80) at org.postgresql.PG_Stream.Send(PG_Stream.java:87) at org.postgresql.core.QueryExecutor.sendQuery(QueryExecutor.java:184) at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:71) at org.postgresql.jdbc1.AbstractJdbc1Connection.ExecSQL(AbstractJdbc1Connection.java:505) at org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Statement.java:360) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:48) at org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:176) at org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:163) at org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:162) at com.eplica.model.persistence.JDBCPersistenceHelper.findByUniqueSql(JDBCPersistenceHelper.java:704) Does anyone know what this is about ? I'm using Red hat Enterprise, and all the correct JDBC drivers etc, using Jakarta DHCP connection pooling, and standard sql sentences. thanx -reynir
Generally speaking this is an issue with a firewall dropping the connection, but given that you are using dbcp, I find this hard to believe. Do you have it setup to test for the connection, and to reap dead connections ? Dave On Thu, 2004-05-13 at 09:36, Reynir_Þór_Hübner wrote: > I'm running an engine with 15 databases, with fair amount of load. > > Every 4-5 days I'm getting error like this from the java side and the > application stops working (and wont come back unless I restart the > webapplication): > > > 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 java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66) > at java.io.BufferedOutputStream.write(BufferedOutputStream.java:110) > at java.io.FilterOutputStream.write(FilterOutputStream.java:80) > at org.postgresql.PG_Stream.Send(PG_Stream.java:87) > at org.postgresql.core.QueryExecutor.sendQuery(QueryExecutor.java:184) > at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:71) > at > org.postgresql.jdbc1.AbstractJdbc1Connection.ExecSQL(AbstractJdbc1Connection.java:505) > at > org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Statement.java:360) > at > org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:48) > at > org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:176) > at > org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:163) > at > org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:162) > at > com.eplica.model.persistence.JDBCPersistenceHelper.findByUniqueSql(JDBCPersistenceHelper.java:704) > > > > Does anyone know what this is about ? > I'm using Red hat Enterprise, and all the correct JDBC drivers etc, > using Jakarta DHCP connection pooling, and standard sql sentences. > > thanx > -reynir > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend > > > > !DSPAM:40a37c72108701489913165! > > -- Dave Cramer 519 939 0336 ICQ # 14675561
On Thu, 13 May 2004, [ISO-8859-1] Reynir ��r H�bner wrote: > I'm running an engine with 15 databases, with fair amount of load. > > Every 4-5 days I'm getting error like this from the java side and the > application stops working (and wont come back unless I restart the > webapplication): > > java.net.SocketException: Broken pipe What else is happening at this time? You shown the Java side of things, but is there anything of note in the postgresql server logs? Possibly a restart or crash occurs at this point? Kris Jurka
Here's a patch for getUDT, I'll apply it if nobody complains.. -- Dave Cramer 519 939 0336 ICQ # 14675561
Attachment
On Thu, 13 May 2004, Dave Cramer wrote: > Here's a patch for getUDT, I'll apply it if nobody complains.. > It seems to have some problems, most notably the fact that we don't support UDTs. Looking at the javadoc for this function you are returing NULL for both class_name and data_type which doesn't look like it's allowed as type_cat and type_schem explicitly state their ability to be null. Without class_name and data_type what information are we really returning? If you are really just returning plain type info, how is this different/better than getTypeInfo(). If you want to implement it for the sake of implementing it, the docs state, "Note: If the driver does not support UDTs, an empty result set is returned." I belive this is the correct thing to do. Kris Jurka
While we don't support JAVA_OBJECT we do support struct, and distinct. Dave On Mon, 2004-05-17 at 18:41, Kris Jurka wrote: > On Thu, 13 May 2004, Dave Cramer wrote: > > > Here's a patch for getUDT, I'll apply it if nobody complains.. > > > > It seems to have some problems, most notably the fact that we don't > support UDTs. Looking at the javadoc for this function you are returing > NULL for both class_name and data_type which doesn't look like it's > allowed as type_cat and type_schem explicitly state their ability to be > null. Without class_name and data_type what information are we really > returning? If you are really just returning plain type info, how is this > different/better than getTypeInfo(). > > If you want to implement it for the sake of implementing it, the docs > state, "Note: If the driver does not support UDTs, an empty result set is > returned." I belive this is the correct thing to do. > > Kris Jurka > > > > !DSPAM:40a945e1239445479435263! > > -- Dave Cramer 519 939 0336 ICQ # 14675561
On Mon, 17 May 2004, Dave Cramer wrote: > While we don't support JAVA_OBJECT we do support struct, and distinct. After doing some more reading I would agree that domains == distinct and complext types == struct, if that's what you're suggesting. The patch shows no signs of this though, it just blindly selects everything out of pg_type. To be worthy of applying it seems this patch should: 1) Only return domains and complex types, correctly setting data_type and base_type for domains. 2) Use pg_description to retrieve a comment for the remarks column. 3) Filter out toast entries by checking pg_namespace.nspname != 'pg_toast' instead of using a like expression on type name. 4) Use the escapeQuotes function to ensure that the schema and type patterns don't have single quotes in them. 5) Use the types[] parameter to filter out undesired data_type values. 6) Use ORDER BY to return the results in the order the spec says. 7) Use createMetaDataStatement() instead of createStatement() when returning the query results. This makes the produced ResultSet scrollable instead of the default forward only behavior. I would personally like to see a version of this that ran on a 7.2 server because the regression tests currently pass against a 7.2 server. It isn't within our stated goals of supporting the past two versions of the driver, but I think it's a reasonable thing to do. Kris Jurka
On Mon, 2004-05-17 at 20:20, Kris Jurka wrote: > On Mon, 17 May 2004, Dave Cramer wrote: > > > While we don't support JAVA_OBJECT we do support struct, and distinct. > > After doing some more reading I would agree that domains == distinct and > complext types == struct, if that's what you're suggesting. The patch > shows no signs of this though, it just blindly selects everything out of > pg_type. Yes > > To be worthy of applying it seems this patch should: > > 1) Only return domains and complex types, correctly setting data_type and > base_type for domains. > > 2) Use pg_description to retrieve a comment for the remarks column. > > 3) Filter out toast entries by checking pg_namespace.nspname != 'pg_toast' > instead of using a like expression on type name. this must remain, as there will be numerous pg_toast_... entries created by large columns > > 4) Use the escapeQuotes function to ensure that the schema and type > patterns don't have single quotes in them. > > 5) Use the types[] parameter to filter out undesired data_type values. > > 6) Use ORDER BY to return the results in the order the spec says. > > 7) Use createMetaDataStatement() instead of createStatement() when > returning the query results. This makes the produced ResultSet scrollable > instead of the default forward only behavior. > > I would personally like to see a version of this that ran on a 7.2 server > because the regression tests currently pass against a 7.2 server. It > isn't within our stated goals of supporting the past two versions of the > driver, but I think it's a reasonable thing to do. This probably makes things alot more difficult as schema's don't exist in 7.2 but... > > Kris Jurka > > > > !DSPAM:40a956df25291752513779! > > -- Dave Cramer 519 939 0336 ICQ # 14675561
Other than the hack of what do with undefined types, and one more little problem which is how to qualify user defined types. This is more difficult than first glance. It is possible to just say typowner != 1, but this doesn't solve the problem if I own the cluster. Here is round 2 On Tue, 2004-05-18 at 08:18, Dave Cramer wrote: > On Mon, 2004-05-17 at 20:20, Kris Jurka wrote: > > On Mon, 17 May 2004, Dave Cramer wrote: > > > > > While we don't support JAVA_OBJECT we do support struct, and distinct. > > > > After doing some more reading I would agree that domains == distinct and > > complext types == struct, if that's what you're suggesting. The patch > > shows no signs of this though, it just blindly selects everything out of > > pg_type. > > Yes > > > > To be worthy of applying it seems this patch should: > > > > 1) Only return domains and complex types, correctly setting data_type and > > base_type for domains. > > > > 2) Use pg_description to retrieve a comment for the remarks column. > > > > 3) Filter out toast entries by checking pg_namespace.nspname != 'pg_toast' > > instead of using a like expression on type name. > > this must remain, as there will be numerous pg_toast_... entries created > by large columns > > > > 4) Use the escapeQuotes function to ensure that the schema and type > > patterns don't have single quotes in them. > > > > 5) Use the types[] parameter to filter out undesired data_type values. > > > > 6) Use ORDER BY to return the results in the order the spec says. > > > > 7) Use createMetaDataStatement() instead of createStatement() when > > returning the query results. This makes the produced ResultSet scrollable > > instead of the default forward only behavior. > > > > I would personally like to see a version of this that ran on a 7.2 server > > because the regression tests currently pass against a 7.2 server. It > > isn't within our stated goals of supporting the past two versions of the > > driver, but I think it's a reasonable thing to do. > > This probably makes things alot more difficult as schema's don't exist > in 7.2 but... > > > > Kris Jurka > > > > > > > > > > > > -- Dave Cramer 519 939 0336 ICQ # 14675561
Attachment
Just added the check to make sure the type is not in pg_catalog schema. Dave On Tue, 2004-05-18 at 18:32, Dave Cramer wrote: > Other than the hack of what do with undefined types, and one more little > problem which is how to qualify user defined types. This is more > difficult than first glance. It is possible to just say typowner != 1, > but this doesn't solve the problem if I own the cluster. > > Here is round 2 > On Tue, 2004-05-18 at 08:18, Dave Cramer wrote: > > On Mon, 2004-05-17 at 20:20, Kris Jurka wrote: > > > On Mon, 17 May 2004, Dave Cramer wrote: > > > > > > > While we don't support JAVA_OBJECT we do support struct, and distinct. > > > > > > After doing some more reading I would agree that domains == distinct and > > > complext types == struct, if that's what you're suggesting. The patch > > > shows no signs of this though, it just blindly selects everything out of > > > pg_type. > > > > Yes > > > > > > To be worthy of applying it seems this patch should: > > > > > > 1) Only return domains and complex types, correctly setting data_type and > > > base_type for domains. > > > > > > 2) Use pg_description to retrieve a comment for the remarks column. > > > > > > 3) Filter out toast entries by checking pg_namespace.nspname != 'pg_toast' > > > instead of using a like expression on type name. > > > > this must remain, as there will be numerous pg_toast_... entries created > > by large columns > > > > > > 4) Use the escapeQuotes function to ensure that the schema and type > > > patterns don't have single quotes in them. > > > > > > 5) Use the types[] parameter to filter out undesired data_type values. > > > > > > 6) Use ORDER BY to return the results in the order the spec says. > > > > > > 7) Use createMetaDataStatement() instead of createStatement() when > > > returning the query results. This makes the produced ResultSet scrollable > > > instead of the default forward only behavior. > > > > > > I would personally like to see a version of this that ran on a 7.2 server > > > because the regression tests currently pass against a 7.2 server. It > > > isn't within our stated goals of supporting the past two versions of the > > > driver, but I think it's a reasonable thing to do. > > > > This probably makes things alot more difficult as schema's don't exist > > in 7.2 but... > > > > > > Kris Jurka > > > > > > > > > > > > > > > > > > -- Dave Cramer 519 939 0336 ICQ # 14675561