oracle rdbms connector

[Roderick Grau]

Scott,

I removed the container manager connection from idp2.xml and altered the data connector to be an application managed connection.

Here is what I now have in attribute-resolver.xml

<resolver:DataConnector
   id="SUNYCARDDB"
   xsi:type="RelationalDatabase"
   xmlns="urn:mace:shibboleth:2.0:resolver:dc">

   <resolver:Dependency ref="UALDAP" />
   <resolver:FailoverDataConnector ref="STATICMAGSTRIPE" />

   <ApplicationManagedConnection
    jdbcDriver="oracle.jdbc.OracleDriver"
    jdbcURL="jdbc:oracle:thin:@dbservername.albany.edu:1521:GOLDDEVL"
    jdbcUserName="SHIB_INTERFACE"
    jdbcPassword="password"
    poolMinSize="1"
    poolMaxSize="5"
    poolBreakAfterAcquireFailure="false" />

   <QueryTemplate>
     <![CDATA[
       SELECT diebold.local_patron_flat_view.magstripe AS suny_magstripe
       FROM diebold.local_patron_flat_view
       WHERE diebold.local_patron_flat_view.primarykey='$employeeNumber.get(0)'
     ]]>
   </QueryTemplate>
 </resolver:DataConnector>

 <resolver:DataConnector
   id="STATICMAGSTRIPE"
   xsi:type="Static"
   xmlns="urn:mace:shibboleth:2.0:resolver:dc">

   <Attribute id="SUNY_MAGSTRIPE">
     <Value>0</Value>
   </Attribute>
 </resolver:DataConnector>

The idea is to failover to the static connector during DB reboots/patching and then have the primary data connector come back once the DB is back.  This is a very low usage SP so the lack of sending data via the static connector is not an issue.

I tested the config by having the DBAs down the DB, but the IDP is still trying to connect to the primary connector and not failing over.

Is the poolBreakAfterAcquireFailure="true" making the failover not happen or am I missing something?

-Rod

On May 21, 2013, at 3:08 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>> To summarize in case I did not explain it well enough.  The IDP is working and
>> answering requests.  A DB connector goes offline and the IDP stops
>> answering requests while it waits for the DB connector to come back.  Once
>> the DB connector comes back the IDP again starts answering requests.
> 
> Well, eventually all the threads will hit the connector logic and wait for the database, that's why it's hung. You have to guarantee the behavior of the connectors you configure. Any timeouts involved have to be set on that driver, they don't come from Shibboleth.
> 
> The IdP cannot be hung otherwise unless your container is badly broken. If there were request threads available, it should still respond to requests that don't hit the connector like the old status handler that just returns "ok".
> 
>> My comment about maxActive="0" was in reference to setting the pool to 0
>> and only initiating a DB connect when one was needed.  The tomcat/dbcp
>> documentation say that "0" means no limit and not none.
> 
> Well, this problem lies with that layer, not here. I would suggest you find out what the error message from Oracle means and maybe start with that. Then you might ask somebody that supports DBCP or Tomcat to address what would be used to get around whatever causes that error condition. 
> 
> -- Scott
> 
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>