Skip site navigation (1) Skip section navigation (2)

Re: Socket close exception

From: Maciek Sakrejda <msakrejda(at)truviso(dot)com>
To: Hernan Danielan <hernandanielan(at)gmail(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Socket close exception
Date: 2010-05-17 04:33:40
Message-ID: AANLkTimDWJEEuF7htIwtoZ8Eakv1pKBURdOdk_FMRZVf@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Hmm. I guess I'd grab something like Wireshark or tcpdump and look
directly at the FEBE (or even TCP) messages on the wire. Wireshark
understands the PostgreSQL FEBE protocol natively, so you should be
able to check whether the messages have the payload you expect with
only moderate effort.

Either that, or step through your client code (and into PostgreSQL
jdbc code) in a debugger and see if something causes the client so
silently wig out at some point.
---
Maciek Sakrejda | System Architect | Truviso

1065 E. Hillsdale Blvd., Suite 230
Foster City, CA 94404
(650) 242-3500 Main
(650) 242-3501 F
www.truviso.com



On Sat, May 15, 2010 at 9:46 AM, Hernan Danielan
<hernandanielan(at)gmail(dot)com> wrote:
> Yes, the most interesting thing is that the log says
> unexpected EOF on client connection or  could not send data to client:
> Broken pipe
> But this shouldn't be happening according to the code i sent because i do
> NOT close the socket. Moreover the transaction only takes up a few seconds.
> I read a person who had this problem and he fixed changing th cache size but
> I wasn't successful.
> Any ideas?
>
> On Fri, May 14, 2010 at 12:57 PM, Maciek Sakrejda <msakrejda(at)truviso(dot)com>
> wrote:
>>
>> Anything interesting in the postgres log when this happens?
>> ---
>> Maciek Sakrejda | System Architect | Truviso
>>
>> 1065 E. Hillsdale Blvd., Suite 230
>> Foster City, CA 94404
>> (650) 242-3500 Main
>> (650) 242-3501 F
>> www.truviso.com
>>
>>
>>
>> On Fri, May 14, 2010 at 8:09 AM, Hernan Danielan
>> <hernandanielan(at)gmail(dot)com> wrote:
>> > Hello! I am using postgress 8.4. I am trying to save to my DB a Large
>> > Binary
>> > Object, let's say 1.4MB. I read that LargeObjectAPI should be used.
>> > I have a problem that sometimes i can store the file and some others i
>> > get
>> > an exception of
>> >>>org.postgresql.util.PSQLException: An I/O error occured while sending
>> >>> to
>> >>> the backend.
>> >>>java.net.SocketException: Socket closed
>> > I try to create a connection for each object but the errors perssist
>> > with
>> > big files. For smaller files like 13KB this example works great. Does
>> > anybody have this problem??? I debug the applcation and I am getting the
>> > socket close exception during obj.write (....) here is a bit of the code
>> > mDbConnector.setAutoCommit(false);
>> > // Get the Large Object Manager to perform operations with
>> > LargeObjectManager lobj =
>> > ((org.postgresql.PGConnection)mDbConnector).getLargeObjectAPI();
>> > // Create a new large object
>> > int oid = lobj.create(LargeObjectManager.READ |
>> > LargeObjectManager.WRITE);
>> > // Open the large object for writing
>> > LargeObject obj = lobj.open(oid, LargeObjectManager.WRITE);
>> > byte []data = cont.getData();
>> > obj.write(data,0,data.length);
>> > obj.close();
>> > PreparedStatement statement = mDbConnector.prepareStatement("INSERT INTO
>> > publicitiescontent (IdPublicities,MimeType,FileName,Title,Data) VALUES
>> > (?,?,?,?,?)");
>> > statement.setBigDecimal(1, new BigDecimal(publicityId));
>> > statement.setString(2, cont.getMimeType());
>> > statement.setString(3, cont.getFileName());
>> > statement.setString(4, cont.getNombre());
>> > statement.setInt(5, oid);
>> > statement.execute();
>> > statement.close();
>> > mDbConnector.commit();
>> >
>> > Thanks in advance,
>> > Hernan
>
>

In response to

pgsql-jdbc by date

Next:From: Andre BurkovskiDate: 2010-05-17 17:41:02
Subject: 8.4 vs 8.1 AbstractJdbc2Array - Array retrieval
Previous:From: Oliver JowettDate: 2010-05-16 08:36:53
Subject: Re: Exception 'org.postgresql.util.PSQLException' could not be instantiated

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group