[
https://issues.apache.org/jira/browse/DERBY-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464863
]
Bryan Pendleton commented on DERBY-2166:
----------------------------------------
I'm having a bit of trouble understanding why this is related to
derby.drda.timeSlice. Are you saying that the *only* time we will get this
exception is if derby.drda.timeSlice was set?
Also, regarding the change to DRDAConnThread.java, why do you have to catch all
DRDAProtocolException and then test to see if you got a
DRDASocketTimeoutException? Can you not just specifically catch
DRDASocketTimeoutException?
I guess I find it somewhat confusing to make this new exception be a subclass
of DRDAProtocolException. It seems like DRDAProtocolException occurrences
generally indicate severe bugs in the code, and this new exception seems like
it would be a normal occurrence when time slicing.
> Implement proper handling of SocketTimeoutException in DRDAConnThread
> ---------------------------------------------------------------------
>
> Key: DERBY-2166
> URL: https://issues.apache.org/jira/browse/DERBY-2166
> Project: Derby
> Issue Type: Improvement
> Components: Network Server
> Reporter: Bernt M. Johnsen
> Assigned To: Bernt M. Johnsen
> Attachments: derby-2166.diff, derby-2166.stat
>
>
> A timeout is set on the session socket (ClientThread) but the
> SocketTimeoutException is not taken care of. Connections is therefore closed
> down if derby.drda.timeSlice is set and the client idles longer then the
> timeslice. See DERBY-1856 for more details.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
