[jira] Assigned: (DIRSHARED-72) DnNode does not handle move and rename operations
[ https://issues.apache.org/jira/browse/DIRSHARED-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kiran Ayyagari reassigned DIRSHARED-72: --- Assignee: Kiran Ayyagari DnNode does not handle move and rename operations - Key: DIRSHARED-72 URL: https://issues.apache.org/jira/browse/DIRSHARED-72 Project: Directory Shared Issue Type: Bug Affects Versions: 0.9.19 Reporter: Emmanuel Lecharny Assignee: Kiran Ayyagari Priority: Critical Fix For: 1.0.0-RC1 Currently the DnNode data structure does not handle a move or a rename operation. That means we can only remove a branch, and add all its elements. The problem is that the DnNode structure is used for : - partitions (it will never change) - referrals (a move or rename will break referrals handling) - AP chaches ( we have 4 of them) One more thing to do if we add a move( newDn ) and a rename (newRdn ) operation is to update all the children's DN recursively -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRSHARED-72) DnNode does not handle move and rename operations
[ https://issues.apache.org/jira/browse/DIRSHARED-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12976640#action_12976640 ] Kiran Ayyagari commented on DIRSHARED-72: - Added rename operation. http://svn.apache.org/viewvc?rev=1054545view=rev DnNode does not handle move and rename operations - Key: DIRSHARED-72 URL: https://issues.apache.org/jira/browse/DIRSHARED-72 Project: Directory Shared Issue Type: Bug Affects Versions: 0.9.19 Reporter: Emmanuel Lecharny Assignee: Kiran Ayyagari Priority: Critical Fix For: 1.0.0-RC1 Currently the DnNode data structure does not handle a move or a rename operation. That means we can only remove a branch, and add all its elements. The problem is that the DnNode structure is used for : - partitions (it will never change) - referrals (a move or rename will break referrals handling) - AP chaches ( we have 4 of them) One more thing to do if we add a move( newDn ) and a rename (newRdn ) operation is to update all the children's DN recursively -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Subentry cache : one step further
On 1/3/11 2:39 AM, Alex Karasulu wrote: What's giving me an icky feeling inside is that #2 is making a read operation induce writes (although DSA driven maintenance operations) and hence causing us to consider one offs with the way a change log works. It's also something to be considered for replication as a change to be ignored. Changelogs works the exact same way. The current tests I wrote (add/del/lookups) prefectly reverts even if a write is done when reading infos. The very same for replication. Consider that the server sees no difference if the write is done because someone has read some info. They are atomic modifications anyway. My whole religious issue with approach #2 is that it's essential an optimization for an administrative operation that is forcing us to settle for this path because of a lack of solid atomicity based on local transactions in the server. Not only. It's mainly a way to avoid a huge penalty caused by a massive change on a million entries server, making the users paying a small price once when reading info instead of blocking the whole server until all the entries are updated. We're shifting many ideals we all believe in if I am not mistaken to optimize a seldom performed operation that usually occurs during outage times. Again, I explained in some previous mail that it's not a trade. If an admin want to have the entries being updated immediately, then he has the possibility to do a full read. Or we can, as I suggested, implement option #3 and make the server update the entries immediately. Option #1 is a one way road with no escape... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Creation of a second Subentry cache
On Mon, Jan 3, 2011 at 2:27 AM, Alex Karasulu akaras...@apache.org wrote: Not referring to the SchemaUI bundle. In studio we have all of ApacheDS available in the embedded ApacheDS plugin bundle. This however is not visible outside because it's an OSGi bundle, however there's no reason why the DnNode class cannot be accessed in a similar fashion through the AP UI plugin bundle by having a dependency on core-api. Essentially studio already uses the entire server in the ApacheDS plugin. It's not visible because the ApacheDS JARs are not added to the bundle classpath. Instead the ApacheDS plugin just extracts the entire server to the file system and starts a new java process. What's the big deal in having another bundle depend on core-api for managing APs? Pierre-Arnaud already added this (and other) ApacheDS artifacts, so they are available as OSGi bundles. Kind Regards, Stefan
DnNode class (was :Re: Creation of a second Subentry cache)
(Renamed the thread for clarity) On 1/3/11 9:40 AM, Stefan Seelmann wrote: On Mon, Jan 3, 2011 at 2:27 AM, Alex Karasuluakaras...@apache.org wrote: Not referring to the SchemaUI bundle. In studio we have all of ApacheDS available in the embedded ApacheDS plugin bundle. This however is not visible outside because it's an OSGi bundle, however there's no reason why the DnNode class cannot be accessed in a similar fashion through the AP UI plugin bundle by having a dependency on core-api. Essentially studio already uses the entire server in the ApacheDS plugin. It's not visible because the ApacheDS JARs are not added to the bundle classpath. Instead the ApacheDS plugin just extracts the entire server to the file system and starts a new java process. What's the big deal in having another bundle depend on core-api for managing APs? Pierre-Arnaud already added this (and other) ApacheDS artifacts, so they are available as OSGi bundles. I have no problem moving DnNode class to core-API, except that it's probably not the right timing to do so. What bugs me is that this class was added in shared way before the core-api module was created. May be we forgot to move it back then. I do feel we may use it for other purposes than just the server, not forcing a potential user to add core-api in its dependencies, but anyway, it's not a big deal. Bottom line, I don't really care, as soon as such moves are done when the current work done on AP are completed, in order to ease the merge back to trunk (other wise it will be a nightmare), plus as soon as we check the impact of such moves on studio (and here, i'm not talking about DnNode, but about other potential changes we will have to do in shared before the release). The best would be to create a JIRA suggesting moving DnNode, so that we can track such moves and impacts. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Creation of a second Subentry cache
On Mon, Jan 3, 2011 at 10:40 AM, Stefan Seelmann seelm...@apache.orgwrote: On Mon, Jan 3, 2011 at 2:27 AM, Alex Karasulu akaras...@apache.org wrote: Not referring to the SchemaUI bundle. In studio we have all of ApacheDS available in the embedded ApacheDS plugin bundle. This however is not visible outside because it's an OSGi bundle, however there's no reason why Note I say not visible outside here. the DnNode class cannot be accessed in a similar fashion through the AP UI plugin bundle by having a dependency on core-api. Essentially studio already uses the entire server in the ApacheDS plugin. It's not visible because the ApacheDS JARs are not added to the bundle classpath. See above. Instead the ApacheDS plugin just extracts the entire server to the file system and starts a new java process. Right. What's the big deal in having another bundle depend on core-api for managing APs? Pierre-Arnaud already added this (and other) ApacheDS artifacts, so they are available as OSGi bundles. Cool thanks Stefan. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: DnNode class (was :Re: Creation of a second Subentry cache)
On Mon, Jan 3, 2011 at 10:55 AM, Emmanuel Lecharny elecha...@gmail.comwrote: (Renamed the thread for clarity) On 1/3/11 9:40 AM, Stefan Seelmann wrote: On Mon, Jan 3, 2011 at 2:27 AM, Alex Karasuluakaras...@apache.org wrote: Not referring to the SchemaUI bundle. In studio we have all of ApacheDS available in the embedded ApacheDS plugin bundle. This however is not visible outside because it's an OSGi bundle, however there's no reason why the DnNode class cannot be accessed in a similar fashion through the AP UI plugin bundle by having a dependency on core-api. Essentially studio already uses the entire server in the ApacheDS plugin. It's not visible because the ApacheDS JARs are not added to the bundle classpath. Instead the ApacheDS plugin just extracts the entire server to the file system and starts a new java process. What's the big deal in having another bundle depend on core-api for managing APs? Pierre-Arnaud already added this (and other) ApacheDS artifacts, so they are available as OSGi bundles. I have no problem moving DnNode class to core-API, except that it's probably not the right timing to do so. Well you've been incredibly reticent especially while I provided valid strong points for the move. So saying no problem seems very contradictory. Plus I'm not using my feelings, opinions or saying probably here. I sited some valid technical arguments and that's how we operate here in Apache. What bugs me is that this class was added in shared way before the core-api module was created. May be we forgot to move it back then. I do feel we may use it for other purposes than just the server, not forcing a potential user to add core-api in its dependencies, but anyway, it's not a big deal. Again what bugs, and what you feel are not how we operate. Bottom line, I don't really care, as soon as such moves are done when the current work done on AP are completed, in order to ease the merge back to trunk (other wise it will be a nightmare), plus as soon as we check the impact of such moves on studio (and here, i'm not talking about DnNode, but about other potential changes we will have to do in shared before the release). SVN allows you to merge code and work in parallel in a branch. No one has to wait for someone else to continue their work and merge. If you merge in first, I myself will deal with the cleanup involved on the merge back after your AP changes. The best would be to create a JIRA suggesting moving DnNode, so that we can track such moves and impacts. This is a simple 2 second class move in my branch which tracks the change. No need to clutter up JIRA with every little infinitesimal code change. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: DnNode class (was :Re: Creation of a second Subentry cache)
On 1/3/11 12:27 PM, Alex Karasulu wrote: On Mon, Jan 3, 2011 at 10:55 AM, Emmanuel Lecharnyelecha...@gmail.comwrote: (Renamed the thread for clarity) On 1/3/11 9:40 AM, Stefan Seelmann wrote: On Mon, Jan 3, 2011 at 2:27 AM, Alex Karasuluakaras...@apache.org wrote: Not referring to the SchemaUI bundle. In studio we have all of ApacheDS available in the embedded ApacheDS plugin bundle. This however is not visible outside because it's an OSGi bundle, however there's no reason why the DnNode class cannot be accessed in a similar fashion through the AP UI plugin bundle by having a dependency on core-api. Essentially studio already uses the entire server in the ApacheDS plugin. It's not visible because the ApacheDS JARs are not added to the bundle classpath. Instead the ApacheDS plugin just extracts the entire server to the file system and starts a new java process. What's the big deal in having another bundle depend on core-api for managing APs? Pierre-Arnaud already added this (and other) ApacheDS artifacts, so they are available as OSGi bundles. I have no problem moving DnNode class to core-API, except that it's probably not the right timing to do so. Well you've been incredibly reticent especially while I provided valid strong points for the move. So saying no problem seems very contradictory. I still believe that there is no valid technical reason for this move. I still believe that we will need this class on the client side, without having to depend on core-api. I just have no problem getting this class moved around as soon as it's present somewhere. If we have to move it back to shared later, so be it. I won't block anything in this area because it's not relevant. As you said, my personal feelings are not important. Plus I'm not using my feelings, opinions or saying probably here. I sited some valid technical arguments and that's how we operate here in Apache. Please, I don't need you to lecture me here. Bottom line, I don't really care, as soon as such moves are done when the current work done on AP are completed, in order to ease the merge back to trunk (other wise it will be a nightmare), plus as soon as we check the impact of such moves on studio (and here, i'm not talking about DnNode, but about other potential changes we will have to do in shared before the release). SVN allows you to merge code and work in parallel in a branch. No one has to wait for someone else to continue their work and merge. No one has to make it painful for other, as you now perfectly well that tree conflicts are a PITA to handle. More than that, we already discussed this point earlier : changing shared is anything but urgent atm. There is no serious issues in it, and once the last blocking issue in the server, namely the AP handling, is fixed, then as I said, we can start and cleanup shared. If you want to help us to fix this AP thing, you are more than welcome. If you merge in first, I myself will deal with the cleanup involved on the merge back after your AP changes. This is why I told you it was not urgent. People are working on trunk, I do merge back the fixes that are injected into trunk tothe AP branch in order to avoid such conflicts later. Shared modifications you are currently doing are not entering this area because it's not urgent. We already had a discussion back in october about Shared refactoring, a lot of modifications have been made back then, and I don't remember having seen any objection from you back then. I find it a bit strange to see you pushing as much as you can for minor modifications that are not urgent not necessary. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
[jira] Created: (DIRSTUDIO-718) Update Eclipse dependencies to version 3.6.1
Update Eclipse dependencies to version 3.6.1 Key: DIRSTUDIO-718 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-718 Project: Directory Studio Issue Type: Task Reporter: Pierre-Arnaud Marcelot Assignee: Pierre-Arnaud Marcelot Fix For: 1.5.4, 2.0.0 We should move to the latest Eclipse dependencies, version 3.6.1 (Helios). Doing this, we will probably need to have two versions for each architecture: - Mac OS X 32 Bit and 64 Bit - Linux 32 Bit and 64 Bit - Windows 32 Bit and 64 Bit -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DIRSTUDIO-717) Add application for Windows 64 Bit
[ https://issues.apache.org/jira/browse/DIRSTUDIO-717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12976712#action_12976712 ] Pierre-Arnaud Marcelot edited comment on DIRSTUDIO-717 at 1/3/11 9:05 AM: -- This issue depends on DIRSTUDIO-718 (Update Eclipse dependencies to version 3.6.1). We will create the 64 Bit version of Studio when migrating to the latest Eclipse dependencies. was (Author: pamarcelot): This issue dependencies on DIRSTUDIO-718 (Update Eclipse dependencies to version 3.6.1). We will create the 64 Bit version of Studio when migrating to the latest Eclipse dependencies. Add application for Windows 64 Bit -- Key: DIRSTUDIO-717 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-717 Project: Directory Studio Issue Type: Improvement Reporter: Stefan Seelmann Fix For: 2.0.0 It would be nice to have an additional RCP application for Windows 64 Bit. Since Eclispe Helios a 64-Bit Windows executable and SWT plugin exists. Today a user needs to install a 32 JVM on Windows 64-Bit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: DnNode class (was :Re: Creation of a second Subentry cache)
On Mon, Jan 3, 2011 at 2:07 PM, Emmanuel Lécharny elecha...@apache.orgwrote: On 1/3/11 12:27 PM, Alex Karasulu wrote: On Mon, Jan 3, 2011 at 10:55 AM, Emmanuel Lecharnyelecha...@gmail.com wrote: (Renamed the thread for clarity) On 1/3/11 9:40 AM, Stefan Seelmann wrote: On Mon, Jan 3, 2011 at 2:27 AM, Alex Karasuluakaras...@apache.org wrote: Not referring to the SchemaUI bundle. In studio we have all of ApacheDS available in the embedded ApacheDS plugin bundle. This however is not visible outside because it's an OSGi bundle, however there's no reason why the DnNode class cannot be accessed in a similar fashion through the AP UI plugin bundle by having a dependency on core-api. Essentially studio already uses the entire server in the ApacheDS plugin. It's not visible because the ApacheDS JARs are not added to the bundle classpath. Instead the ApacheDS plugin just extracts the entire server to the file system and starts a new java process. What's the big deal in having another bundle depend on core-api for managing APs? Pierre-Arnaud already added this (and other) ApacheDS artifacts, so they are available as OSGi bundles. I have no problem moving DnNode class to core-API, except that it's probably not the right timing to do so. Well you've been incredibly reticent especially while I provided valid strong points for the move. So saying no problem seems very contradictory. I still believe that there is no valid technical reason for this move. I still believe that we will need this class on the client side, without having to depend on core-api. Beliefs are not good enough, you need to support your points with technical facts. I was going to make this move in my branch but I thought I'd discuss it with the community. My doing so is a matter of respect and congeniality towards the community. I can if you like supply the technical points once again and we can review each one. This is not a pissing contest for me it's PURELY technical. It's about properly managing the shared API and releasing a 1.0 so we can then get to work on ApacheDS 2.0. I just have no problem getting this class moved around as soon as it's present somewhere. If we have to move it back to shared later, so be it. I won't block anything in this area because it's not relevant. As you said, my personal feelings are not important. If I did not respect your feelings I would not have opened this up for discussion even though the technical reasoning behind the move is valid. If I did not care I would have just moved it. This drawn out conversation is just a pure waste of time but you're the one pushing it and I am politely listening and supplying the technical information needed to make the right choice. I will never loose patience with you but please stick to the facts. The truth and the technical facts will always lead to resolution. Plus I'm not using my feelings, opinions or saying probably here. I sited some valid technical arguments and that's how we operate here in Apache. Please, I don't need you to lecture me here. You brought it upon yourself. Stick to the technical facts and stop filibustering with feelings, beliefs and opinions. If you stopped pushing back with comments that have no way to be rationally discussed and stuck to technical points I would not have to point out your not supplying technical points. You leave me with no other option but to point out what a person is doing when someone tells me, but I feel this is better, repeatedly without supplying technical reasons or challenging the ones I have presented? If you give me other options I will gladly and respectfully consider them. Let's not waste our time. Bottom line, I don't really care, as soon as such moves are done when the current work done on AP are completed, in order to ease the merge back to trunk (other wise it will be a nightmare), plus as soon as we check the impact of such moves on studio (and here, i'm not talking about DnNode, but about other potential changes we will have to do in shared before the release). SVN allows you to merge code and work in parallel in a branch. No one has to wait for someone else to continue their work and merge. No one has to make it painful for other, as you now perfectly well that tree conflicts are a PITA to handle. There's no reason why I have to stop my activity to facilitate yours. We should be able to work in parallel. But most important of all there are no by laws stating this in the foundation. However if you don't want to handle a merge I can see about waiting for you and deal with the conflict resolution myself. That is if you don't take too long. More than that, we already discussed this point earlier : changing shared is anything but urgent atm. Urgent or not this is your characterization and opinion. I'm a member of an open source community working on a project and code base I love and started working on over 10
AP handling heads up
Hi, the lookup operation is now fully implemented, with tests for APs, Subentries and normal entries. The Add and Delete operation are also fully tested. After this week modifications in the data structure, we can now move forward. I'm starting implementing the search operation, which is close to the lookup operation. I will also update the algorithms I posted 2 weeks ago and the data structure I had to modify to reflect the current status of the developement. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
