Hi Sebb, I finally found some time to test all the changes, and so far, I found nothing wrong.
Everything works as expected and as wanted. THANKS!!! Although one can start a iscussion about all the information that is included in the answers, I think that there are good reasons for including this information (but off course, I myself invented it this way) The rootDN is in fact a JNDI invention, which is not existing in LDAP. So the real LDAP searchbase, which is built from a searchbase and a rootDN by JNDI, is different form the searchbase as you want to give to the sampler. That's the reason that I included this tag. The DN is always the full DN of an entry, and it is in LDAP the only real unique key for an entry, so I included this also. This is always needed for modification, delete, move or add operations. Thanks again for applying everything. Greetings, Dolf Dolf Smits Senior Consultant Identity Management Solutions 070 333 3654 070 333 2511 06 55844837 [EMAIL PROTECTED] Let op: Vrijdags heb ik ouderschapsverlof en wordt uw mail niet gelezen. Deze e-mail is uitsluitend bedoeld voor kennisneming door de geadresseerde(n), en mag niet aan anderen worden doorgestuurd of op andere wijze ter kennis worden gebracht. Indien u niet de geadresseerde bent, verzoek ik u om de afzender te waarschuwen en de e-mail direct te verwijderen/vernietigen. De afzender wijst elke aansprakelijkheid voor (de inhoud van) deze e-mail af. -----Original Message----- From: sebb [mailto:[EMAIL PROTECTED] Sent: zondag 11 maart 2007 23:49 To: JMeter Users List Subject: Re: JMeter LDAP extended request : issue with big response I've applied the patches from Bug 40103 and created another nightly build. Response parsing is now optional. [But it looks like the parsing time was not included in the sample response time]. Also the code no longer appends so many strings in order to create the response, so it should perform a bit better. It seems to work, as far as I can tell, but I don't have much experience in using LDAP, so it would be good it someone else could try it out. The XML response data should now be well-formed (even when Exceptions occur), but whether it is correctly formatted I don't know: For example, should the search results be nested in the <operation> tag? Also, the <searchbase> tag includes the rootDN which does not seem right, and the <dn> tag includes the name, the searchbase and the rootDN. Seems a bit wasteful to repeat this information, but maybe that is standard? On 22/01/07, Bruno Cosnefroy <[EMAIL PROTECTED]> wrote: > Hi, > > Thanks a lot Dolf for your answer. > The time response of my "big" request was measured from another > client. So I agree with you this should be a parsing problem in > Jmeter. > > If somebody knows where I can find a patch not to parse the response > (if it is not already included in Jmeter) and/or how to configure > Jmeter to do that, I am really interested. > > Thanks, > Bruno > > > On 1/20/07, Smits, Dolf <[EMAIL PROTECTED]> wrote: > > Hi, > > > > There might be a problem that all answers are parsed by Jmeter. > > > > I think that this was reported before, and a patch was made so you can > > choose to NOT parse the answer. This is specially done for these kind of > > cases. > > In fact you do need the answer, because that is what the server sends. > > So if the server really send the complete ansewer in less than one > > second you need to stop parsing. > > > > Unfortunatly, some patches for the LDAP part are still in bugzilla, but > > need to be applied to the source. > > > > One warning. > > If your server reports that the search request took less than one > > second, this does not necisarrily mean that the answer was received by > > the clinet within one second. > > Launching the same request over the network, and timing till the > > complete answer was received is the important time. > > If this really is less than a second, the problem is definitely within > > parsing the answer within Jmeter. > > If this also takes a long time, other issues might interfere. > > > > Hope this helps you a bit. > > > > Dolf > > > > > > Dolf Smits > > Senior Consultant Identity Management Solutions > > > > 070 333 3654 > > 070 333 2511 > > 06 55844837 > > [EMAIL PROTECTED] > > Let op: Vrijdags heb ik ouderschapsverlof en wordt uw mail niet gelezen. > > Deze e-mail is uitsluitend bedoeld voor kennisneming door de > > geadresseerde(n), en mag niet aan anderen worden doorgestuurd of op > > andere wijze ter kennis worden gebracht. Indien u niet de geadresseerde > > bent, verzoek ik u om de afzender te waarschuwen en de e-mail direct te > > verwijderen/vernietigen. De afzender wijst elke aansprakelijkheid voor > > (de inhoud van) deze e-mail af. > > > > > > > > > > -----Original Message----- > > From: Bruno Cosnefroy [mailto:[EMAIL PROTECTED] > > Sent: vrijdag 19 januari 2007 16:22 > > To: [email protected] > > Subject: JMeter LDAP extended request : issue with big response > > > > Hi, > > > > I use Jmeter to send LDAP extended request to my LDAP directory. > > It works fine for every request I have to send except for one. > > The request takes less than one second with ldapsearch. However, the > > response contains 4400 entries (29000 lines in ldif). > > I can't make this request work in Jmeter, even in csv and non-GUI mode. > > (I see the request in my ldap server logs but the jmeter client stop > > working and the following requests are not sent) > > Any idea of configuration? (I don't want the response data but only > > the response time). > > The CPU usage increases a lot when I try and I have to stop the process. > > > > Have anyone make tests with request receiving big response in Jmeter? > > > > > > Thanks in advance, > > Bruno > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
