deleting user and memory

> Norbert Hartl wrote:
>> Hi,
>> I did some tests installing seaside 3 in my image under different users. Most of them weren't successful so I deleted those users. If I'm not misled I could not see memory being freed by deleting just the user. Is there anything else to do to cleanup?
>> thanks,
>> Norbert
>
> Norbert,
>
> I would assume as you did that things would be cleaned up ... what kinds or objects are you seeing that are hanging around?
>

> On 20.07.2010, at 18:28, Dale Henrichs wrote:
>
>> Norbert Hartl wrote:
>>> Hi,
>>> I did some tests installing seaside 3 in my image under different users. Most of them weren't successful so I deleted those users. If I'm not misled I could not see memory being freed by deleting just the user. Is there anything else to do to cleanup?
>>> thanks,
>>> Norbert
>> Norbert,
>>
>> I would assume as you did that things would be cleaned up ... what kinds or objects are you seeing that are hanging around?
>>
> I just noticed the different object count the MFC gives. It went from 336xxxx live objects to 442xxxx while testing. Removing the user and MFC afterwards did not change the live objects count. That's why I am asking. I don't have detailled information about it.
>
> But you state that removing the user from AllUsers should be sufficient? Then I try to figure out anything ;)
>
> Norbert
>

> Norbert Hartl wrote:
>> On 20.07.2010, at 18:28, Dale Henrichs wrote:
>>> Norbert Hartl wrote:
>>>> Hi,
>>>> I did some tests installing seaside 3 in my image under different users. Most of them weren't successful so I deleted those users. If I'm not misled I could not see memory being freed by deleting just the user. Is there anything else to do to cleanup?
>>>> thanks,
>>>> Norbert
>>> Norbert,
>>>
>>> I would assume as you did that things would be cleaned up ... what kinds or objects are you seeing that are hanging around?
>>>
>> I just noticed the different object count the MFC gives. It went from 336xxxx live objects to 442xxxx while testing. Removing the user and MFC afterwards did not change the live objects count. That's why I am asking. I don't have detailled information about it. But you state that removing the user from AllUsers should be sufficient? Then I try to figure out anything ;) Norbert
>
> Norbert,
>
> I _assume_ that it should be sufficient ... I'm not completely familiar with the ins and outs of removing users, so there could be bugs or extra steps required.
>
> Dale

> Dale,
>
> I investigated it a bit further. My feelings were right the users are
> indeed still present. I looked at the code of creating a user and
> removing. To me it appears that if you delete a user from the
> AllUsers list the segment is not deleted as well. And the segment
> still holds a reference to user (owner). I scanned a lot of the
> classes but I couldn't find anything that lets me delete a segment. I
> think it is an action that should be taken carefully ;) Anyway the
> creation of one is inside a primitive. So I guess there is less I can
> do. Right?
>
> Norbert
>
>
> On 20.07.2010, at 19:00, Dale Henrichs wrote:
>
>> Norbert Hartl wrote:
>>> On 20.07.2010, at 18:28, Dale Henrichs wrote:
>>>> Norbert Hartl wrote:
>>>>> Hi, I did some tests installing seaside 3 in my image under
>>>>> different users. Most of them weren't successful so I deleted
>>>>> those users. If I'm not misled I could not see memory being
>>>>> freed by deleting just the user. Is there anything else to do
>>>>> to cleanup? thanks, Norbert
>>>> Norbert,
>>>>
>>>> I would assume as you did that things would be cleaned up ...
>>>> what kinds or objects are you seeing that are hanging around?
>>>>
>>> I just noticed the different object count the MFC gives. It went
>>> from 336xxxx live objects to 442xxxx while testing. Removing the
>>> user and MFC afterwards did not change the live objects count.
>>> That's why I am asking. I don't have detailled information about
>>> it. But you state that removing the user from AllUsers should be
>>> sufficient? Then I try to figure out anything ;) Norbert
>> Norbert,
>>
>> I _assume_ that it should be sufficient ... I'm not completely
>> familiar with the ins and outs of removing users, so there could be
>> bugs or extra steps required.
>>
>> Dale
>

> Norbert Hartl wrote:
>> Dale,
>>
>> I investigated it a bit further. My feelings were right the users are
>> indeed still present. I looked at the code of creating a user and
>> removing. To me it appears that if you delete a user from the
>> AllUsers list the segment is not deleted as well. And the segment
>> still holds a reference to user (owner). I scanned a lot of the
>> classes but I couldn't find anything that lets me delete a segment. I
>> think it is an action that should be taken carefully ;) Anyway the
>> creation of one is inside a primitive. So I guess there is less I can
>> do. Right?
>>
>> Norbert
>>
>>
>> On 20.07.2010, at 19:00, Dale Henrichs wrote:
>>
>>> Norbert Hartl wrote:
>>>> On 20.07.2010, at 18:28, Dale Henrichs wrote:
>>>>> Norbert Hartl wrote:
>>>>>> Hi, I did some tests installing seaside 3 in my image under
>>>>>> different users. Most of them weren't successful so I deleted
>>>>>> those users. If I'm not misled I could not see memory being
>>>>>> freed by deleting just the user. Is there anything else to do
>>>>>> to cleanup? thanks, Norbert
>>>>> Norbert,
>>>>>
>>>>> I would assume as you did that things would be cleaned up ...
>>>>> what kinds or objects are you seeing that are hanging around?
>>>>>
>>>> I just noticed the different object count the MFC gives. It went
>>>> from 336xxxx live objects to 442xxxx while testing. Removing the
>>>> user and MFC afterwards did not change the live objects count.
>>>> That's why I am asking. I don't have detailled information about
>>>> it. But you state that removing the user from AllUsers should be
>>>> sufficient? Then I try to figure out anything ;) Norbert
>>> Norbert,
>>>
>>> I _assume_ that it should be sufficient ... I'm not completely
>>> familiar with the ins and outs of removing users, so there could be
>>> bugs or extra steps required.
>>>
>>> Dale
>
> Norbert,
>
> I've submitted Issue 151
> (http://code.google.com/p/glassdb/issues/detail?id=151) to track the
> problem. I looked in the System Admin Guide and noted that there is not
> guidance for removing a user from topaz. There are instructions for
> using the GBS tool, but the details of what the GBS tools does during
> user removal isn't described...
>
> Dale

> Norbert,
>
> The GBS remove user algorithm, installs another user into the owner slot  of the segment, so you should be able to install DataCurator as the owner of the segment thereby freeing up all of the objects owned by that  user...
>
> Dale
>
> Dale Henrichs wrote:
>> Norbert Hartl wrote:
>>> Dale,
>>>
>>> I investigated it a bit further. My feelings were right the users are
>>> indeed still present. I looked at the code of creating a user and
>>> removing. To me it appears that if you delete a user from the
>>> AllUsers list the segment is not deleted as well. And the segment
>>> still holds a reference to user (owner). I scanned a lot of the
>>> classes but I couldn't find anything that lets me delete a segment. I
>>> think it is an action that should be taken carefully ;) Anyway the
>>> creation of one is inside a primitive. So I guess there is less I can
>>> do. Right?
>>>
>>> Norbert
>>>
>>>
>>> On 20.07.2010, at 19:00, Dale Henrichs wrote:
>>>
>>>> Norbert Hartl wrote:
>>>>> On 20.07.2010, at 18:28, Dale Henrichs wrote:
>>>>>> Norbert Hartl wrote:
>>>>>>> Hi, I did some tests installing seaside 3 in my image under
>>>>>>> different users. Most of them weren't successful so I deleted
>>>>>>> those users. If I'm not misled I could not see memory being
>>>>>>> freed by deleting just the user. Is there anything else to do
>>>>>>> to cleanup? thanks, Norbert
>>>>>> Norbert,
>>>>>>
>>>>>> I would assume as you did that things would be cleaned up ...
>>>>>> what kinds or objects are you seeing that are hanging around?
>>>>>>
>>>>> I just noticed the different object count the MFC gives. It went
>>>>> from 336xxxx live objects to 442xxxx while testing. Removing the
>>>>> user and MFC afterwards did not change the live objects count.
>>>>> That's why I am asking. I don't have detailled information about
>>>>> it. But you state that removing the user from AllUsers should be
>>>>> sufficient? Then I try to figure out anything ;) Norbert
>>>> Norbert,
>>>>
>>>> I _assume_ that it should be sufficient ... I'm not completely
>>>> familiar with the ins and outs of removing users, so there could be
>>>> bugs or extra steps required.
>>>>
>>>> Dale
>> Norbert,
>> I've submitted Issue 151 (http://code.google.com/p/glassdb/issues/detail?id=151) to track the problem. I looked in the System Admin Guide and noted that there is not guidance for removing a user from topaz. There are instructions for using the GBS tool, but the details of what the GBS tools does during user removal isn't described...
>> Dale
>

> Dale,
>
> does this mean you can only increase the number of segments? And a
> segment is not that much data? Is there a method the create a new
> user without creating a new segment? I could then install DataCurator
> first to free memory and reallocate the segment to a new user
> afterwards. Would that be possible?
>
> thanks,
>
> Norbert
>

> Norbert Hartl wrote:
>> Dale,
>> does this mean you can only increase the number of segments? And a
>> segment is not that much data? Is there a method the create a new
>> user without creating a new segment? I could then install DataCurator
>> first to free memory and reallocate the segment to a new user
>> afterwards. Would that be possible?
>> thanks,
>> Norbert
>
> Segments are a limited resource. It is possible to create a new user without allocating a segment for the new user (see the user creation protocol), but the default is to create a new segment when a new user is created.
>
> This came up in our discussion of the bug this morning ... the default _should_ be that no segment is created unless you explicitly want one ... I think that you should be able to reuse the segment as long as you realize that until the objects associated with the old segment owner will be accessible to the new segment owner until they are garbage collected...
>
> You can reuse/share a segment for a new user by passing in the segment as the defaultSegment arg.
>
> nil is a valid value for the defaultSegment. The nil segment is readable and writable by the world ...
>

> On 29.07.2010, at 21:48, Dale Henrichs wrote:
>
>> Norbert Hartl wrote:
>>> Dale,
>>> does this mean you can only increase the number of segments? And a
>>> segment is not that much data? Is there a method the create a new
>>> user without creating a new segment? I could then install DataCurator
>>> first to free memory and reallocate the segment to a new user
>>> afterwards. Would that be possible?
>>> thanks,
>>> Norbert
>> Segments are a limited resource. It is possible to create a new user without allocating a segment for the new user (see the user creation protocol), but the default is to create a new segment when a new user is created.
>>
>> This came up in our discussion of the bug this morning ... the default _should_ be that no segment is created unless you explicitly want one ... I think that you should be able to reuse the segment as long as you realize that until the objects associated with the old segment owner will be accessible to the new segment owner until they are garbage collected...
>>
>> You can reuse/share a segment for a new user by passing in the segment as the defaultSegment arg.
>>
>> nil is a valid value for the defaultSegment. The nil segment is readable and writable by the world ...
>>
> Ok, i resurrected a segment by doing
>
> | segment user |
> System abortTransaction.
> segment := Segment allInstances detect: [:each| each owner userId = 'oldUserId'].
> user := AllUsers addNewUserWithId: 'newUserId' password: 'xxx' defaultSegment: nil.
> segment owner: user.
> user defaultSegment: segment.
>
> Assigning the segment on creation time of the user does not work. I think gemstone ist complaining about the mismatch of the user created and the owner of the segment. Doing it in separate steps works ok.
>
> Norbert
>
>

> Norbert Hartl wrote:
>> On 29.07.2010, at 21:48, Dale Henrichs wrote:
>>> Norbert Hartl wrote:
>>>> Dale,
>>>> does this mean you can only increase the number of segments? And a
>>>> segment is not that much data? Is there a method the create a new
>>>> user without creating a new segment? I could then install DataCurator
>>>> first to free memory and reallocate the segment to a new user
>>>> afterwards. Would that be possible?
>>>> thanks,
>>>> Norbert
>>> Segments are a limited resource. It is possible to create a new user without allocating a segment for the new user (see the user creation protocol), but the default is to create a new segment when a new user is created.
>>>
>>> This came up in our discussion of the bug this morning ... the default _should_ be that no segment is created unless you explicitly want one ... I think that you should be able to reuse the segment as long as you realize that until the objects associated with the old segment owner will be accessible to the new segment owner until they are garbage collected...
>>>
>>> You can reuse/share a segment for a new user by passing in the segment as the defaultSegment arg.
>>>
>>> nil is a valid value for the defaultSegment. The nil segment is readable and writable by the world ...
>>>
>> Ok, i resurrected a segment by doing
>> | segment user |
>> System abortTransaction.
>> segment := Segment allInstances detect: [:each| each owner userId = 'oldUserId'].
>> user := AllUsers addNewUserWithId: 'newUserId' password: 'xxx' defaultSegment: nil.
>> segment owner: user.
>> user defaultSegment: segment.
>> Assigning the segment on creation time of the user does not work. I think gemstone ist complaining about the mismatch of the user created and the owner of the segment. Doing it in separate steps works ok.
>> Norbert
>
> Norbert,
>
> That's good to know ... as a result of your reports here, we'll be cleaning up our new user/remove user procedures without relying on the GBS implementation.
>