[Glass] Git based repositories (package-cache) problem when moving extent to another stone
Mariano Martinez Peck via Glass
glass at lists.gemtalksystems.com
Tue Oct 27 11:56:01 PDT 2015
On Tue, Oct 27, 2015 at 3:22 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:
>
>
> On 10/27/2015 10:50 AM, Mariano Martinez Peck wrote:
>
> Dale,
>
> While that more robust #exists does help in the sense that the user gets a
> much better error message, I think it's not enough. So now I get this
> message:
>
> ...RETRY->BaselineOfSeaside3
> ...RETRY->BaselineOfSeaside3
> gofer repository error: 'GoferRepositoryError: UserDefinedError: Disk
> error: for path:
> /opt/gemstoneAdditions/GsDevKit_home/server/stones/gs_329/logs/github-cache/GsDevKit/Seaside31/v3.1.4.2-gs/GsDevKit-Seaside31-55f1bac/repository'...ignoring
> ...FAILED->BaselineOfSeaside3
>
> Right, but aren't we trying to figure out why the load works when you
> remove the offending directory
>
Yes, my load works when we remove the offending directory.
> but does not work when you explicitly set the cache directory to nil:
>
> MCGitHubRepository cacheDirectory: nil
>
Yes, this does not fix the problem. What I found out is that besides that,
I could do:
MCRepositoryGroup default repositoriesDo: [:rep | rep flushCache ].
That WOULD have fixed my problem. However #flushCache fails too because of
the same error. So we are not even able to #flushCahe with current code.
>
> ... when an extent is copied to a different stone directory there are
> potentially a number of places that need to be fixed ... basically anywhere
> that is going to look for things on disk ... the Smalltalk code that gets
> executed by $GS_HOME/bin/newExtent currently cleans up the tODE directory
> dependencies and it should also reset the github-cache directory (whether
> or not errors are going to be thrown because of permission errors)...
>
> The $GS_HOME/sys/{default|local}/client/tode-scripts/rebuildSys script is
> intended to clean up these directory/stone dependencies for tODE and GLASS
> and you are expected to override with application-specific clean up code
> ....
>
> Soooo is the above error happening before or after you have cleared
> MCGitHubRepository class>>cacheDirectory?
>
>
After. It has no effect for me running such code.
> I am under the impression that:
>
> MCGitHubRepository cacheDirectory: nil
>
> isn't working for you ... am I missing something?
>
You are not missing anything. That is not working for me and I don't
understand why it would. I am under the impression that I would also need:
MCRepositoryGroup default repositoriesDo: [:rep | rep flushCache ].
No?
>
>
> But my code still fail to load. There are a couple of places that should
> be changed. Search for the string "*MCFileTreeFileUtils current
> directoryExists:*"
> And you will find
>
> --------------------
> MCGitHubRepository class>>resetCacheDirectoryIfInvalid
> MCGitBasedNetworkRepository>>directory
> MCGitBasedNetworkRepository class>>resetCacheDirectoryIfInvalid
> MCFileTreeRepository>>flushCache
>
> I think those guys should handle the error and on error, the flush or
> reset anyway. To avoid this (adding error handling in all those places), I
> suggested adding:
>
> MCFileTreeFileDirectoryUtils class >> directoryExistsAndValid: aDirectory
> ^ aDirectory exists on: Error do: [ false ]
>
> And so, the above 4 methods should actually send #directoryExistsAndValid:
> rather than #directoryExists
>
> I'm not sure that I want to try to bullet-proof this chunk of code ... I
> am worried about what happens if you don't have write permission in the
> first place or the disk is full or ???? there are too many possible error
> conditions that will either continue to fail or may mask the original
> problem if we just handle the errors ...
>
> Besides it seems to me that the problem here is that
> MCGitBasedNetworkRepository class>>resetCacheDirectoryIfInvalid (which sets
> the cacheDirectory nil) won't work because if I understand things correctly
> `MCGitHubRepository cacheDirectory: nil` doesn't work ... or am I missing
> something here ....
>
Problem is that even if I do `MCGitHubRepository cacheDirectory: nil` the
MCGitHubRepository instances still have the offending directory as part of
the instvar 'directory' and so the MC load fails. That's why I think I need
this code:
MCRepositoryGroup default repositoriesDo: [:rep | rep flushCache ].
Which effectively clears the 'directory' from
the MCGitHubRepository instances. But..guess what? I cannot flush, because:
*MCGitBasedNetworkRepository >> flushCache*
"the directory acts like a cache since we download the directory from a
git-based repository (github, bitbucket, etc.)"
* super flushCache.*
self class flushDownloadCache.
* directory := nil*
that method calls super and so this is executed:
*MCFileTreeRepository >> flushCache*
"force properties to be reread ... if the directory exists, otherwise let
nature
take it's course"
super flushCache.
directory
ifNotNil: [
* (MCFileTreeFileUtils current directoryExists: directory) ->>> this
will throw error now*
ifTrue: [
repositoryProperties := nil.
self repositoryProperties ] ]
So...to conclude, THIS piece of code does seem to workaround my problem:
*MCGitHubRepository cacheDirectory: nil.*
*System commit. *
*MCGitBasedNetworkRepository allSubInstances do: [ :rep | *
* " cannot send #directory: becaue it really expects a directory
instance. *
* By puttin a nil in 'directory' we are able to run #flushCache.
See MCFileTreeRepository >> flushCache. for more details "*
* rep instVarNamed: 'directory' put: nil.*
* rep flushCache ].*
*System commit. *
Let me know if I made my problem clear. If you think any of this could be
included and added somewhere, let me know.
Cheers,
--
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151027/eec11d33/attachment-0001.html>
More information about the Glass
mailing list