Full_Name: Sebastien Bahloul Version: HEAD OS: Linux RHEL 5 URL: Submission from: (NULL) (109.197.176.10) Hi, I think there is a bug / limitation inside VLV implementation : it can not handle multiple search operation on a single connection. The first operation succeeds and next operations fail with the following message : LDAP: error code 51 - Other sort requests already in progress My first guess was to remove / comment the following condition in sssvlv.c:757 : vc->vc_context != so->so_vcontext But I think this issue is more global. This implementation seems to be able to only handle a single VLV context per connection. If I am right, this is related with the indexing method of sort_conns structure which seems to be based only on the connection id. I suggest to implement a double indexing array by connection id / VLV context id. Regards,
sebastien.bahloul@gmail.com wrote: > Full_Name: Sebastien Bahloul > Version: HEAD > OS: Linux RHEL 5 > URL: > Submission from: (NULL) (109.197.176.10) > > > Hi, > > I think there is a bug / limitation inside VLV implementation : it can not > handle multiple search operation on a single connection. The first operation > succeeds and next operations fail with the following message : > > LDAP: error code 51 - Other sort requests already in progress > But I think this issue is more global. This implementation seems to be able to > only handle a single VLV context per connection. Correct, that is by design. > If I am right, this is related with the indexing method of sort_conns structure > which seems to be based only on the connection id. I suggest to implement a > double indexing array by connection id / VLV context id. I have no interest in extending this. It would require much more overhead to protect the slapd from getting overloaded by too many such requests. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Hi Howard, Le mercredi 27 octobre 2010 15:03:36, Howard Chu a écrit : > sebastien.bahloul@gmail.com wrote: > > Full_Name: Sebastien Bahloul > > Version: HEAD > > OS: Linux RHEL 5 > > URL: > > Submission from: (NULL) (109.197.176.10) > > > > > > Hi, > > > > I think there is a bug / limitation inside VLV implementation : it can > > not handle multiple search operation on a single connection. The first > > operation succeeds and next operations fail with the following message : > > > > LDAP: error code 51 - Other sort requests already in progress > > > > But I think this issue is more global. This implementation seems to be > > able to only handle a single VLV context per connection. > > Correct, that is by design. > > > If I am right, this is related with the indexing method of sort_conns > > structure which seems to be based only on the connection id. I suggest > > to implement a double indexing array by connection id / VLV context id. > > I have no interest in extending this. It would require much more overhead > to protect the slapd from getting overloaded by too many such requests. In fact my suggestion was a question : I would like to contribute a patch to add support for this way of using VLV. Is this feature extension as a double indexed array an acceptable implementation from your point of vue ? To avoid encountering such performance issues, I would add a new sssvlv parameter that would authorize by default only a single VLV search request per connection. Regards, -- Sebastien Bahloul @: sebastien.bahloul@gmail.com
Sebastien Bahloul wrote: > Hi Howard, > > Le mercredi 27 octobre 2010 15:03:36, Howard Chu a écrit : >> sebastien.bahloul@gmail.com wrote: >>> Full_Name: Sebastien Bahloul >>> Version: HEAD >>> OS: Linux RHEL 5 >>> URL: >>> Submission from: (NULL) (109.197.176.10) >>> >>> >>> Hi, >>> >>> I think there is a bug / limitation inside VLV implementation : it can >>> not handle multiple search operation on a single connection. The first >>> operation succeeds and next operations fail with the following message : >>> >>> LDAP: error code 51 - Other sort requests already in progress >>> >>> But I think this issue is more global. This implementation seems to be >>> able to only handle a single VLV context per connection. >> >> Correct, that is by design. >> >>> If I am right, this is related with the indexing method of sort_conns >>> structure which seems to be based only on the connection id. I suggest >>> to implement a double indexing array by connection id / VLV context id. >> >> I have no interest in extending this. It would require much more overhead >> to protect the slapd from getting overloaded by too many such requests. > > In fact my suggestion was a question : I would like to contribute a patch to > add support for this way of using VLV. Is this feature extension as a double > indexed array an acceptable implementation from your point of vue ? To avoid > encountering such performance issues, I would add a new sssvlv parameter that > would authorize by default only a single VLV search request per connection. I guess as long as you observe the svi_max config parameter, there's no reason not to adopt your suggestion. Feel free to followup here with your patch for review. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Hi ! Le Ven 29 octobre 2010 11:12, hyc@symas.com a écrit : > I guess as long as you observe the svi_max config parameter, there's no > reason > not to adopt your suggestion. Feel free to followup here with your patch > for > review. Here is the patch: ftp://ftp.openldap.org/incoming/raphael-ouazana-101105-sssvlv-multiple-requests-per-conn.patch It applies to HEAD of today. If you need it, I can send you a patch for RE24 too. The patch includes the modification of the man page. Legal notice: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in this following patch were developed by Raphael Ouazana raphael.ouazana@linagora.com. These modifications are not subject to any license of Linagora. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Raphael Ouazana, Linagora Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. Regards, Raphaël Ouazana
Hi, Here is a new version of the patch: ftp://ftp.openldap.org/incoming/raphael-ouazana-101125-sssvlv-multiple-requests-per-conn.patch It fixes some segfaults that the previous patch introduced if you use pagedResults or sss instead of VLV. It also fixes a segfault in the original sssvlv code when making two successive requests on the same connexion (can be triggered by ldapsearch). Finally here is an update of the copyright notice too: Legal notice: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in this following patch were developed by Raphael Ouazana raphael.ouazana@linagora.com and Sebastien Bahloul sbahloul@linagora.com. These modifications are not subject to any license of Linagora. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Raphael Ouazana, Linagora Copyright 2010 Sebastien Bahloul, Linagora Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. Regards, Raphaël Ouazana
changed notes changed state Open to Test moved from Incoming to Software Enhancements
changed notes changed state Test to Release
changed notes changed state Release to Closed
added to HEAD added to RE24