[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12366813 ]
Kathey Marsden commented on DERBY-614:
--
Deepa said
I had checked all the DRDAResultSet states get initialized when
re-used. If they are not in close, they get
Bryan Pendleton (JIRA) wrote:
[snip good explanation for removal of finalizeChain]
Are there flaws in my reasoning here?
Sounds reasonable
Additional test cases I should try?
Don't know of any off hand. In the past, server chaining issues have
shown up most reliably on ODBC on Linux. I
One thing I did notice that deserves followup and may be related to the
intermittent hangs you have seen, is that there was a finalizeChain() call in
the old file on line 6139 that seems to be missing from the new version, line
6278.
This might be the source of the hang you reported for one
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12360015 ]
Kathey Marsden commented on DERBY-614:
--
I committed this patch
Date: Fri Dec 9 17:51:26 2005
New Revision: 355689
URL: http://svn.apache.org/viewcvs?rev=355689view=rev
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12358655 ]
Kathey Marsden commented on DERBY-614:
--
The change looks good to me. A couple small points and a request
For the assertion There was no data to split, it would be
Kathey Marsden (JIRA) wrote:
The change looks good to me. A couple small points and a request
Thanks Kathey, this is very helpful.
I'll pursue these points, but I don't think it will be until next
weekend; I'll let you know how it turns out.
thanks,
bryan
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12358557 ]
Bryan Pendleton commented on DERBY-614:
---
After stepping through the current code carefully in the debugger, and trying
several failed attempts at changes, I learned
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12358565 ]
Bryan Pendleton commented on DERBY-614:
---
Ugh. There's always 1 last detail. My new test case in lang/big.sql fails, but
only:
- if run with the db2jcc.jar driver
- AND
Bryan Pendleton (JIRA) wrote:
[snip a bunch of stuff that sounds right]
I'm still not really sure I understand this business about a statement having
multiple current result sets
A statement may have multiple result sets but only one of them is current.
A stored procedure can return multiple
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12358465 ]
Bryan Pendleton commented on DERBY-614:
---
I've coded up a new implementation, which has some new behaviors. The client
likes some of those new behaviors, but doesn't like
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12357583 ]
Kathey Marsden commented on DERBY-614:
--
I wanted to check in on this issue. I wanted to make sure that my comment that
it would be good to get input wasn't stalling your
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12357630 ]
Francois Orsini commented on DERBY-614:
---
I have done a bit of reading on the subject (which was a great learning
exercise btw) and I find Brian's approach with 1) and 2)
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12355828 ]
Kathey Marsden commented on DERBY-614:
--
I hear you about the DRDA specs. They are pretty hard. That's why I am making
you do the research #:) This research by the way
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12355871 ]
Bryan Pendleton commented on DERBY-614:
---
Could you try to change your test case and see if we might get some other
request from the client before we get the CNTQRY or
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12355877 ]
Kathey Marsden commented on DERBY-614:
--
Your steps 1 and 2 sound like a good approach to me. It would be good to get
input from others. I know Oyvind, Rick and
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12355666 ]
Kathey Marsden commented on DERBY-614:
--
I think the parseCNTQRY in splitQRYDTA is wrong. The client should be able to
send any command after receiving a respose to its
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12355684 ]
Bryan Pendleton commented on DERBY-614:
---
Does the server need to associate the data with the result set and wait for
the next CNTQRY, or can it send another block in a
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12332735 ]
Bryan Pendleton commented on DERBY-614:
---
YAY! I think I've found a reproducible test case! I'll attach a zip file with
the details. Please let me know if you can
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12332240 ]
A B commented on DERBY-614:
---
It looks to me like the problem is that, in the splitQRYDTA method that
Kathey mentioned, the server reads a codepoint and _assumes_ it's a CNTQRY
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12332261 ]
Kathey Marsden commented on DERBY-614:
--
I agree that the CLSQRY is perfectly valid, and perhaps many other commands
would be perfectly valid at this point too, maybe
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12332271 ]
Bryan Pendleton commented on DERBY-614:
---
Bryan, do you have a reproducible case that you can attach to the Jira issue?
Unfortunately, no. After your very clear
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12332071 ]
Kathey Marsden commented on DERBY-614:
--
The server side tracing information is on the Wiki page as weel.
Looking briefly at your trace and at the splitQRYDTA code it
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12332076 ]
Bryan Pendleton commented on DERBY-614:
---
It occurred to me that it would probably be most useful to have a matching set
of client-side and server-side tracing. So I've
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12332082 ]
Bryan Pendleton commented on DERBY-614:
---
Kathey says: it looks like splitQRYDTA assumes it is going to get a CNTQRY
after sending each block of data, but in fact in this
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12332046 ]
Bryan Pendleton commented on DERBY-614:
---
I believe I have lucked into a reproducible test case! Below are two queries.
The first query does *NOT* exhibit the problem,
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12332048 ]
Bryan Pendleton commented on DERBY-614:
---
Furthermore, this query works, too! All I do here is add one more condition
into the where clause.
select tf.*,i.name as
[
http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12332055 ]
Kathey Marsden commented on DERBY-614:
--
I posted a few tips on debugging protocol errors on the Wiki.
http://wiki.apache.org/db-derby/ProtocolDebuggingTips
So maybe the
27 matches
Mail list logo
