db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6107) Investigate why setting a login timeout causes NativeAuthenticationServiceTest to fail when run in a suite
Date Mon, 24 Mar 2014 14:09:46 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945134#comment-13945134
] 

Knut Anders Hatlen commented on DERBY-6107:
-------------------------------------------

Hi Rick. Thanks for your comments. Here are my responses:

1) One does not have to use NATIVE authentication. It is enough to access a database on the
classpath with login timeouts enabled. This could result in threads not finding databases
that are in their context class loader, or threads being able to access databases that are
private to other threads. There could be other scenarios as well, but I'm not aware of any
other functionality that depends on the context class loader of the thread that calls getConnection().

2) Derby's current calls to getContextClassLoader() and setContextClassLoader() are wrapped
in try/catch blocks, and SecurityExceptions are silently ignored, so one wouldn't notice if
they failed. Those calls were added to fix DERBY-3745, which could cause class loader leaks
because Derby's daemon threads would hold on to the context class loader of the application
thread that happened to boot the engine. The SecurityExceptions are ignored for backwards
compatibility so that existing applications that don't suffer from the class loader leak aren't
affected.

3) They are mentioned in the Developer's Guide, Running Derby under a security manager, Granting
permissions to Derby, in the optional section: http://db.apache.org/derby/docs/10.10/devguide/cdevbabejgjd.html

4) The total number of threads at any given time will not be greater if the keep alive timeout
is set to 0. On the contrary, since idle threads are not kept around for a while in the pool,
the memory footprint will typically be smaller if the keep alive timeout is 0. With timeout
0, the number of threads in the pool will be equal to the number of callers currently waiting
for getConnection() to return. With the default, non-zero timeout, the number of threads in
the pool will be equal to the number of callers currently waiting for getConnection() to return
*plus* the number of idle threads that haven't yet timed out.

> Investigate why setting a login timeout causes NativeAuthenticationServiceTest to fail
when run in a suite
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-6107
>                 URL: https://issues.apache.org/jira/browse/DERBY-6107
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.10.1.1
>            Reporter: Rick Hillegas
>            Assignee: Knut Anders Hatlen
>
> See DERBY-6094 for the details of this problem.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message