Re: [Exist-development] Very weird and serious error in trunk!

[Adam R. <ad...@ex...>]

I guess its not so serious ;-)

As its running from the scheduler, and you see the value repeat itself
8 times, could we hazard a guess that your scheduled task has been
called 8 times?

The new BinaryValues stuff,if it is not cleaned up just results in a
memory-leak, it is safely re-useable. So you can re-read the same
InputStream multiple times!

I would guess that somehow, something is appended to a session
variable, and this is not being cleaned up.

If you could remove the ldap stuff, and create some sort of
reproducible test case I would be happy to look into this.

Also for eXist-db related issues, could I ask that you use my
ad...@ex... email address. And if you have eXist Solutions
enquiries, or are one of our customers then use my
ad...@ex... email address. It helps me to keep these
things organised.

Thanks Adam.

On 30 April 2011 00:55, Andrzej Jan Taramina <an...@ch...> wrote:
> Wolfgang:
>
> I've hit a very weird error in trunk, that could potentially be very serious.
>
> I have some code in a module that looks like this:
>
> declare function common:test()
> {
>    let $line := <property name="java.naming.security.credentials"
>                           value="{ util:binary-to-string( xs:base64Binary( 'dGVzdAoK' ) ) }"/>
>
>    let $debug2 := util:log-system-out( concat( "Credentials XML: ",
>                        util:serialize(  $line, "method=xml media-type=text/xml indent=yes" ) ) )
>
>    return $line
> };
>
> declare function common:get-ldap-connection()  as xs:integer
> {
>    let $test := common:test()
>
>    let $contextProps :=
>    <properties>
>       <property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
>       <property name="java.naming.provider.url"
>                 value="{ common:get-config()/config/ldap/url/text() }"/>
>       <property name="java.naming.security.authentication" value="simple"/>
>       <property name="java.naming.security.principal"
>                 value="{ common:get-config()/config/ldap/adminUser/text() }"/>
>       <property name="java.naming.security.credentials"
>                 value="{ util:binary-to-string( xs:base64Binary(
>                                common:get-config()/config/ldap/adminPswd/text() ) ) }"/>
>    </properties>
>
>    let $ctx := jndi:get-dir-context( $contextProps )
>
>    return $ctx
> };
>
> I then have a xquery that includes this module, and does something like this:
>
>        let $cnx := common:get-ldap-connection()
>
> All works fine if I call this from the sandbox and in the console log I will see the following line
> produced by the common:test() function:
>
> (Line: 494) Credentials XML: <property name="java.naming.security.credentials"
>                                       value="test&#xA;&#xA;"/>
>
>
> The problem I run into is that when I run this xquery from the scheduler (which is how it's intended
> to run...it's a batch reporting job), cause then I get the following output in the console log:
>
> (Line: 494) Credentials XML: <property name="java.naming.security.credentials" value="test&#xA;&#xA;
> test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA;
> test&#xA;&#xA;"/>
>
> I get 8 concatenated decoded values in the value attribute!!!!
>
> This should never happen!!!!  Of course, in that situation, I fail to get an LDAP connection since
> the password (the credentials) is a concatenation of 8 copies of the actual password, and so fails,
> if I remove the call to the test function.  If I leave in the call to the test function, then the
> correct (non-replicated) password is inserted into the credentials element of the $contextProps
> variable. If I remove the test function call, then I get the same replication in $contextProps.
>
> What is weird is that the error only shows in the one place and is sensitive to order. If I put the
> call to the test function after the construction of the $contextProps value, then $contextProps gets
> the repeated value and the test function returns a correct, unrepeated value.
>
> I've been trying to create a simple test case to replicate this, but have not yet been successful.
> It seems I need to run the big batch job, where the included module is 3600 lines long, and the
> actual xquery is very long and complex as well.
>
> But the code snippet that causes this bug is static code in the common:test() function, and should
> always return the correct result.
>
> I'm not sure what is causing this.  Could it be the new Binary Value caching/handling under weird
> conditions that only happen when running under a scheduled task?  I've never managed to reproduce
> this when calling xqueries directly (the ldap connection call is made all over the place in our web
> app for authentication purposes).  Maybe util:binary-to-string() is at fault, but that seems
> unlikely.  Maybe some of your path wrapper stuff?
>
> This exact same code runs just fine as a scheduled task in an older version of trunk (from late
> summer last year), so it's definitely something new in trunk that has manifested since then.
>
> Any ideas on what might cause something this strange?  I has me very worried since this is pretty
> basic stuff....and thus might cause other things like DB corruption, or incorrect values being
> written or wrong logic paths being followed.
>
> I'll keep trying to create a simple test case that illustrates this, but I think it may not be
> possible to do so.
>
> Help!
>
> Thanks!
>
> --
> Andrzej Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>



-- 
Adam Retter
Director, eXist Solutions GmbH

e: ad...@ex...
w: http://www.existsolutions.com
t: +44 20 3239 7236
m: +44 7714 330069
Skype: adam.retter

Company Registration: HRB 89454, Amtsgericht Darmstadt