| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Stuck session help
Hi Dan...
Ok... I ran into an issue on 8.1.7 last year that sounded similar to what you encountered... The end result was an bug in the JDBC driver... Even if you're on a newer release, I'd give this situation a look if you are using JDBC... If you're not using Now, on to the problem...
Ok... The problem is JDBC sends a null packet to the server... The server expects that the client will send more information (hence the more data from client) while the application is waiting on a return from the server... Hence the hang... Both sides are waiting on the other one... It's somewhat unpredictable since the packet has to be "just right" in size for this to happen...
Bug number 1956339 has a nice summary of the situation... This bug discusses a special situation with a Japanese characterset but it can happen in other situations... I included the internal discussion of bug 1956339 below... The interesting bit is:
"This null packet received by the server makes the server to go back and read the next packet (NOTE: Null packet had is used for getting server info, this is not what JDBC is intending to do). Since JDBC is also done with the write it waits for read from the server and server waits for read from JDBC leading to a hang (deadlock)."
Cool uh? Another bug that discussing something similar is 1483556... It was a 7.3.4 bug listed as fixed in 9 and backported to 8.1.7.1... This talks about how to track it down with a sql*net trace...
"How to determine rediscovery:
The key here is that the thin driver was sending null SQL*Net packets to
the server.
This can be seen in the SQL*Net trace file by looking for lines similar
to the following: .
nsprecv: 10 bytes from transport nsprecv: tlen=10, plen=10, type=6 nsprecv:packet dump nsprecv:00 0A 00 00 06 00 00 00 |........| nsprecv:00 00 00 00 00 00 00 00 |........| nsprecv: normal exit nsrdr: got NSPTDA packet
]]Executing batch operations against a 7.3.4 server that have a large
amount
]]of bind variables, and include some NULL values, could hang when using
the
]]thin driver."
FYI.. In case you're curious, here is the full text of the internal description of bug 1956339
Internal Description:
In a few places we have 'outBuffer.write(tmpBuffer, 0, bytes);' where
tmpBuffer is a byte array and 0 is the offset and bytes is number of bytes
to be written. When the number of bytes to be written is 0 we need not
write anything to the lower layer to avoid roundtrips. Thus avoiding null
packets to be written.
.
Consider the scenario when the number of bytes in the buffer (DataPacket)
is 2047 and marshallSB2 is called,
+ 2 bytes are allocated
+ The two bytes are passed to value2Buffer for splitting the value into a
byte array, and for any conversion if needed (i.e LSB)
In the UNIVERSAL case, it adds the number of data bytes to the buffer,
before the actual value.
+ here if the value which is sent to value2Buffer is UNIVERSAL an extra
byte is written into the buffer making the full (isBufferFull = true)
+ After this when write is called with the number of bytes to be written
as 0, the null packet is sent across.
.
This null packet received by the server makes the server to go back and
read the next packet (NOTE: Null packet had is used for getting server
info, this is not what JDBC is intending to do). Since JDBC is also done
with the write it waits for read from the server and server waits for read
from JDBC leading to a hang (deadlock).
.
As you might have already realised the problem lies both in JDBC and
JavaNet which are as follows,
JavaNet:=
Update the status of isBufferFilled, even if the number of bytes to be
written is 0 (in putDataInBuffer). Since putDataInBuffer is not invoked
everytime the write is called thus leading to stale isBufferFilled (which
is wrong).
JDBC:= Do not make a roundtrip to JavaNet when the number of bytes to be written
is 0.
.
The JDBC fix does fix the bug but I will be filing a new bug against
JavaNet to make sure that the bug in their code is also fixed.
.
The filed JavaNet bug number is bug 2069280.
.
Resolution:
Do not write null packets or do not invoke write on JavaNet when you have
0 bytes to write.
HTH
Tim
Daniel Fink wrote:
>We've got an application that is having problems with the
>processing becoming 'stuck'. I'm now stuck trying to figure out
>why. The process is a series of inserts into several tables.
>Quite a few of the inserts succeed, eventually one of them
>sticks.
>
>It sticks before the execute phase of the insert. It is not
>waiting on a lock (but blocking others). There is plenty of free
>space in the datafile.
>
>Any clues? Ideas?
>
>
>
>
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Wed Apr 07 2004 - 18:07:32 CDT
 |
 |