Thread: java.net.SocketException: Broken pipe

java.net.SocketException: Broken pipe

From
Reynir Þór Hübner
Date:
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

Re: java.net.SocketException: Broken pipe

From
Dave Cramer
Date:
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


Re: java.net.SocketException: Broken pipe

From
Kris Jurka
Date:

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

patch for getUDT

From
Dave Cramer
Date:
Here's a patch for getUDT, I'll apply it if nobody complains..

--
Dave Cramer
519 939 0336
ICQ # 14675561

Attachment

Re: patch for getUDT

From
Kris Jurka
Date:

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


Re: patch for getUDT

From
Dave Cramer
Date:
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


Re: patch for getUDT

From
Kris Jurka
Date:

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


Re: patch for getUDT

From
Dave Cramer
Date:
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


Re: patch for getUDT #2

From
Dave Cramer
Date:
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

Re: patch for getUDT #3

From
Dave Cramer
Date:
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

Attachment