Reinhard Nappert wrote: > Richard, > > Did you have a closer look at it and the test client. When you increases > the pause between the adds/deletes it takes a much longer time to occur > (even after days). It looks to me like some kind of memory leak. > > Should I open a bug for it? > Yes, please. > Let me know. > > Thanks, > -Reinhard > > -----Original Message----- > From: fedora-directory-users-bounces at redhat.com > [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Reinhard > Nappert > Sent: Thursday, September 06, 2007 12:35 PM > To: General discussion list for the Fedora Directory server project. > Subject: RE: MMR: Directory updates on same > object > > Richard, this is a java class, using jndi. > > The relevant methods are: > 1. > public InitialDirContext connect(String host, int port) throws > NamingException > { > InitialDirContext context = null; > Hashtable environment = new Hashtable(); > environment.put( Context.INITIAL_CONTEXT_FACTORY, > "com.sun.jndi.ldap.LdapCtxFactory" ); > environment.put( "java.naming.ldap.version", "3" ); > environment.put(Context.SECURITY_PRINCIPAL, "cn=Directory > Manager"); > environment.put(Context.SECURITY_CREDENTIALS, "xxxxxx"); > environment.put(Context.SECURITY_AUTHENTICATION, "simple"); > > // timeouts > environment.put( "com.sun.jndi.dns.timeout.initial", "2000" ); > environment.put( "com.sun.jndi.dns.timeout.retries", "3" ); > > environment.put( Context.PROVIDER_URL, "ldap://"; + host + ":" + > port+"/o=test" ); > > context = new InitialDirContext( environment); > System.out.println("Connected to " + host); > > return context; > > } > > 2. > public void addEntry(InitialDirContext ctx) { > > // Create attributes to be associated with the new context > Attributes attrs = new BasicAttributes(true); // case-ignore > Attribute objclass = new BasicAttribute("objectclass"); > objclass.add("top"); > objclass.add("organizationalUnit"); > attrs.put(objclass); > > // Create the context > Context result; > try { > result = ctx.createSubcontext("ou=test", attrs); > > result.close(); > } catch (NameAlreadyBoundException e) { > // ignore > // just logg it ....... > } catch (NamingException e) { > e.printStackTrace(); > this.destroy(); > } > } > > 3. > public void deleteEntry(InitialDirContext ctx) { > > try { > ctx.destroySubcontext("ou=test"); > //ctx.close(); > } catch (NameNotFoundException e) { > // ignore > // just logg it ....... > } > } catch (NamingException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > this.destroy(); > } > } > > 4. Start of the thread: > public void start() { > int counter = 0; > > for (int i = start; i < stop; i++) { > try { > addEntry(ctx); > //....some kind of logging > this.sleep(100); > deleteEntry(ctx); > //....some kind of logging > this.sleep(50); > } catch (Exception e) { > e.printStackTrace(); > } > > } > //close context; > try { > ctx.close(); > } catch (NamingException e) { > e.printStackTrace(); > } > } > > Then, I just call this thread for my two masters (MasterOne and > MasterTwo). > > Of course, when I pause for a longer time between the add and delete, it > takes longer that it happens. > > Hope, this helps. > -Reinhard > > > -----Original Message----- > From: fedora-directory-users-bounces at redhat.com > [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Richard > Megginson > Sent: Thursday, September 06, 2007 10:21 AM > To: General discussion list for the Fedora Directory server project. > Subject: Re: MMR: Directory updates on same > object > > Reinhard Nappert wrote: > >> Richard, >> >> I attached the entire access and error log file of one Master >> (MasterOne) and the error file of the other (MasterTwo). You see that >> the last update through the client was conn=50 op=424 on MasterOne. In >> > > >> errors, you see that it still processed the operation conn=50 op=650. >> >> This time the crash happened on MasterOne. >> >> > Thanks. This is a very interesting test. You are generating > replication conflicts: > [05/Sep/2007:13:15:40 -0400] conn=51 op=29 csn=46dee55f000200030000 - > Naming conflict ADD. Renamed existing entry to > nsuniqueid=99277847-1dd111b2-80dfcd7f-b7bc0000+ou=repltest > > It looks as though you are repeatedly adding and deleting the same entry > from both servers at the same time, which should be fine. Could you > post your script that you use to generate these entries? > > >> Hope, this helps >> -Reinhard >> >> -----Original Message----- >> From: fedora-directory-users-bounces at redhat.com >> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of >> Reinhard Nappert >> Sent: Wednesday, September 05, 2007 1:06 PM >> To: General discussion list for the Fedora Directory server project. >> Subject: RE: MMR: Directory updates on same >> object >> >> Actually, I did use log level 8192. I saw that at some point the >> access logs stopped generating entries for the updates, but errors >> still had about 150 operations logged. I do not have those logs >> anymore, but I can reproduce those in a while, when I am done with >> > some other tests. > >> I run those tests on a mixed environment (Solaris 9 and Linux) 32bit. >> This happens on both boxes. I also have seen it on a pure Linux >> environment. >> >> When I have the error logs, I will post them >> >> -Reinhard >> >> -----Original Message----- >> From: fedora-directory-users-bounces at redhat.com >> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of >> Richard Megginson >> Sent: Wednesday, September 05, 2007 12:56 PM >> To: General discussion list for the Fedora Directory server project. >> Subject: Re: MMR: Directory updates on same >> object >> >> Reinhard Nappert wrote: >> >> >>> I have a working Multi-Master Replication setup with two masters >>> (Fedora Directory Server 1.0.4). The setup works fine as long as I do >>> > > >>> not update the same object via both Masters. When the later happens >>> (application driven), one of the Master crashes. This server does not >>> > > >>> generate a core dump, nor can I find any unusual in the access and >>> error log files. I am pretty sure that it has to do something with >>> the >>> >>> >> >> >>> conflict resolution, but I am stuck now. >>> >>> Did anybody experience a similar behavior? >>> >>> >>> >> Can you reproduce the problem with the replication log level on? >> http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting >> >> What OS are you on? 32bit or 64bit? >> >> >>> Thanks, >>> -Reinhard >>> >>> --------------------------------------------------------------------- >>> - >>> -- >>> >>> -- >>> Fedora-directory-users mailing list >>> Fedora-directory-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> >>> >>> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> >> ---------------------------------------------------------------------- >> -- >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> >> > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20070907/152cdc18/attachment.bin
