directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Ldap clients
Date Tue, 01 Feb 2005 23:22:19 GMT
Emmanuel Lecharny wrote:

>The point is that those clients are pretty minimalist actually. The
>question is : do we need them or not? 
>  
>
The clients may still come in handy for simple manned tests.  My 
thinking here is sometimes users need simple command line clients the 
same way they get OpenLDAP clients.  It's expected and the clients are 
thin so it completes the picture.

>Talking about performance and protocol tests, that are two different
>subject:
>1) performance : JMeter is - IMHO - a perfect tool to test the server.
>I've used it a few years ago, and it gives good results. I don't like to
>re-invent the wheel (well, from time to time, that could be an
>option ;-), so I would +1 for it against writing specific load test
>tool.
>  
>
Cool I agree if we can use it we should. However I always thought it was 
an http based tool.  The ldap-common library pretty much can be used to 
teach JMeter LDAP if we need to do that at all.  This is going to be 
cool if we can make it work with all the protocols in our stack.  This 
way we can tune the heck out of MINA.  Also we can really see if SEDA 
does pay off at a certain level of load. 

>2) protocol tests : client are really good to start with, but they need
>some add-ons (automatic tests cases, and so on). But there are others
>options : using a Ldap browser to test EVE, for instance, in combinaison
>with Ethereal, or ldapXXXX scripts, wich can be automated.
>  
>
Right I use a combination of Ethereal and LDAP browsers like JExplorer, 
GQ and sometimes just plain old code that uses the SUN JNDI LDAP 
provider et cetera. 

>On the other side, it could be cool to deliver a whole package : EVE +
>JNDI providers + direct clients. Sure, clients script could be wrote
>using a JNDI LDAP provider, but is it necessary? And what about querying
>other servers (replication/synchronisation in mind)?
>  
>
Right the clients give us a clean room where we can test specific 
features like controls without asking if something is wrong with the SUN 
LDAP JNDI provider.  It's on less ? to deal with.  Also there are things 
you just can't do with the SUN LDAP JNDI provider that can be added to 
these clients.  However this is not that much of a big deal.

>So actually, I've finished with ldap.clients (except standalone, which
>could be put aside), and it compiles. It does not work, because of the
>digester/encoder/decoder problem, but this is NOT a regression. 
>
Hmmm so if I understand you the bug did exist before? I still need to 
get a fix in for this I guess.  Why don't you do this - tar up the code 
and don't bother with the diff.  The code is tiny and we can just flat 
out replace what is there. 

>valon is no more needed.
>
>  
>
Great!

>So the next step could be the encoder/decoder stuff, with those steps :
>1) eradicate the bugs
>2) rethinking the encoder/decoder things (keeping the actuals one for
>the moment, because it exists !)
>  
>
Want me to create a branch to work in just for us? 

>3) rewrite it.
>  
>
This might even be better.  However we can still do this in a branch.   
We just start refactoring code and taking what we can use.  Then we can 
just swap out the trunk for the branch rather than attempt a merge.  
However I think external interfaces will also change too.  This IMO is 
ok nothing here is 1.0 and we can change the code that depends on these 
codec APIs.

>And maybe improve the clients to accept the same syntax and options than
>OpendLdap scripts.
>  
>
Yeah good call.  We should stick to using all the same switches for sure.

>What do you think?
>
>  
>
This is good, very good.  I just need to start looking at the code.  It 
might have been good to do a few of the clients at a time but no worries.

>btw, do I push the client code through Jira? A svn diff is 3036 lines
>long...
>  
>
Just tarball it up and put it into an attachment.  I have the feeling 
the actual classes themselves rather than the diff will be smaller so I 
can just overlay them rather than patch em.

>NB : bloody Babel tower! It takes me so looooong to write what I have in
>mind in english (and, for sure, a trully bad english :( 
>  
>
Nahhh your just fine and thanks for the hard work.

>Le mardi 01 février 2005 à 16:33 -0500, Alex Karasulu a écrit :
>  
>
>>Emmanuel Lecharny wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>is there any functionnal difference between :
>>>org.apache.ldap.clients.standalone 
>>>and
>>>org.apache.ldap.clients
>>>?
>>>
>>>Does some unit tests exist for those classes? I don't think so, but I
>>>may be wrong.
>>>
>>>What about org.apache.ldap.clients.ldaptest : is it a kind of UI to test
>>>Ldap clients operations? I've launched it after having crafted a minimal
>>>XML configuration file, but I can't Add tests cases. Any clue?
>>>
>>> 
>>>
>>>      
>>>
>>Emmanuel, your guess is as good as mine.  It's been over a year and a 
>>half since I looked at the client code. 
>>
>>Jeff Machols (primary guy who was working client code) and I started 
>>talking about building an LDAP test suite for both performance and for 
>>protocol testing.  We were going to use it to collect information about 
>>how well ApacheDS performs in relation to other servers.  I think some 
>>of the XML work was to design test cases around client requests for this 
>>purpose.  Perhaps if Jeff is listening he can shed some light on this.
>>
>>The stuff in client top pkg look almost exactly the same as the 
>>standalone stuff.  I have no idea why Jeff may have structured it this 
>>way.  Perhaps he was going to do some refactoring but descided not to 
>>after copying stuff into a new package.  That too does not make sense 
>>since he would have copied the trunk to branches.
>>
>>Here's my recommendation to you.  If you want to totally revamp this go 
>>right ahead.  Take what ever you can use from it and we'll just replace 
>>the trunk with new code (granted if it passes review which I think it 
>>will).
>>
>>Is this preferrable for you?
>>
>>Cheers,
>>Alex
>>
>>
>>
>>    
>>
>
>
>
>  
>


Mime
View raw message