JDBC Driver issue

After upgrading our metadirectory engine to 4.7.1 we are having an issue with our jdbc driver connecting. We've updated the driver and remote loader to the latest versions. The error we are receiving is
Message: Code(-9005) The driver returned a "fatal" status indicating that the driver should be shut down. Detail from driver: Premature return from PublicationShim.start()<application>DirXML</application>
<module>ESD JDBC</module>

In the past I've seen this issue and putting all passwords back into the configuration via iManager or Designer has resolved this, however it is not the case this time, we're also seeing an issue where it says a file is locked. Anyone have this issue after upgrading?
  • Seeing the startup trace, level three (3) or higher), would probably be
    useful, specifically from the engine side so we can see if anything is odd
    prior to the Remote Loader (RL) connection.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • Since this site won't let me load the log file unless it's in pieces here is a link to the log.
    https://emory.box.com/v/jdbcdriver
  • That site wants me to sign in, but I am pretty sure I lack an account there.

    Could you paste the code to something like SUSE Paste, or Pastebin, or
    similar, and then provide the link from there to here?

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • This log is about 5mb, the forum here won't post the full log and those two sites mentioned have size limits as well. I'll cut it down and post it in sections here.
  • That seems a bit big just for a startup, particularly when the Remote
    Loader (RL) should not even be connecting.

    If you have old data, clear it out, then get JUST the startup until the
    -9005 error shows up, and that should be plenty, and I would not expect it
    to be many MiBs in size if you are at level three (3). If you are at a
    higher trace level, try just level three (3) for this particular attempt.


    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • Well thats the odd thing, if the remote loader isn't running the driver will come on and run, however once it connects to the remote loader it shuts down with one of two errors, one is a publication shim error and the other is a statefile error. I just did a clean restart of the driver without the remote loader running, the driver has started and is running. Logs to follow
  • Here's the paste of the driver start up without the remote loader running.
    https://pastebin.com/TfLzmXhs
  • Okay, at least things look like they are fine up until the Remote Loader
    (RL) connection. Do you have the next part, just from when it tries to go
    to the RL and the resulting -9005 coming back?

    Also, I've never seen anybody using LDAP like this, but I guess it is
    supported so long as the server side is okay with it; if this is not what
    you meant, then fix it since normally I would expect to see a database
    host, port, and DB name here instead:


    jdbc:oracle:thin:@ldap://oranamesrvr0.cc.dev1.edu/ESDIMD,cn=OracleContext,dc=dev1,dc=edu


    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • Hmmm..... well, something is weird about your trace; the timestamps are
    all lost, so I cannot tell as much as I would like. Was this written
    directly to a trace file configured within the driver configuration
    object, or was this gathered via something else like ndstrace or iMonitor?
    I'm guessing the latter, since that's the only way I know of to
    consistently lose timestamps. In the future, please send traces written
    directly from one driver object to a dedicated file, as it makes things
    much more reliable (ndstrace/iMonitor can lose data if the lines come in
    too fast, plus they mess up formatting, do not have good timestamps, etc.).

    Back to your issue, the trace seems to confirm that the driver object and
    Remote Loader (RL) passwords are fine, and immediately after that the
    engine sends the configuration data to the RL which, maybe quickly or
    maybe not (no timestamps), hangs up a bit.


    <allow-attr attr-name="PRAD_A_BSNS_FAX_FMTT"/>
    <allow-attr attr-name="PRSN_N_FULL_DTRY"/>
    <allow-attr attr-name="PRSN_N_FRST"/>
    <allow-attr attr-name="PRSN_N_INTL_MIDL"/>
    <allow-attr attr-name="Internet EMail Address"/>
    <allow-attr attr-name="PRSN_N_LAST_DTRY"/>
    <allow-attr attr-name="PRAD_A_BSNS_TLPH_FMTT"/>
    <allow-attr attr-name="PRSN_E_TITL_DTRY"/>
    </allow-class>
    </driver-filter>
    <publisher-options>
    <disable display-name="Disable the Publisher channel?">1</disable>
    <publication-mode display-name="Publication Mode(ignore if publisher
    disabled):">_</publication-mode>
    <log-table display-name="Event log table
    name:">NETIQAPO.NETIQ_PRSN_EMPTY</log-table>
    <delete-from-log display-name="Delete processed rows?">_</delete-from-log>
    <optimize-update display-name="Optimize updates?">_</optimize-update>
    <allow-loopback display-name="Allow loopback?">_</allow-loopback>
    <disable-locking display-name="Disable statement-level
    locking?">0</disable-locking>
    <startup-option display-name="Startup option:">_</startup-option>
    <handle-future-events display-name="Enable future event
    processing?">_</handle-future-events>
    <ignore8 display-name="Use custom timestamp statement?">0</ignore8>
    <current-timestamp-stmt display-name="Current timestamp
    statement:"></current-timestamp-stmt>
    <ignore9 display-name="Show polling-related parameters?">show</ignore9>
    <polling-interval display-name="Polling interval (in
    seconds):">3600</polling-interval>
    <time-of-day display-name="Polling time of day:"></time-of-day>
    <post-poll-stmt display-name="Post polling statements:"></post-poll-stmt>
    <batch-size display-name="Batch size:">_</batch-size>
    <query-limit display-name="Query Limit (default 10000):">100</query-limit>
    <pub-heartbeat-interval display-name="Heartbeat interval (in
    minutes):">60</pub-heartbeat-interval>
    </publisher-options>
    </init-params>
    </input>
    <ds>
    </publisher-init>
    </top>
    9.565:JDBC PT:Remote Interface Driver: Document sent.
    9.566:JDBC PT:Remote Interface Driver: Waiting for receive...
    ..101:JDBC ST:SubscriptionShim.execute() returned:
    ..101:JDBC ST:
    <nds dtdversion="4" ndsversion="8.x">
    <output>
    <status event-id="query-driver-ident" level="retry" type="remoteloader">No
    connection to remote loader</status>
    </output>



    Notice the XML is sent (that XML looks broken too, probably because of
    using ndstrace or else some cleanup you did after the fact) and the next
    thing we get is a "No connection to remote loader" message. Something
    about the XML sent is presumably bad. I suppose at this point the RL
    trace may be useful, and while level three (3) is the minimum we need, we
    may want to try level (5) just for fun. Higher levels are also available
    for the JDBC driver, but they are usually (in my experience anyway) not
    helpful for this type of issue. Still, whatever you want to send is fine.

    My wild guess at this point is something like the database name, or the
    table name, or rights to the table, or credentials for the Oracle DB
    itself, is wrong, though in most cases I would expect a better response.
    Maybe having the timestamps there properly will give us a clue; if there
    is a minute-long gap between when the XML is sent and when we get the
    error back, perhaps there is a connection issue between the RL and the
    database service.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.