Ahh, right, I was referring to the demos, where we have a unique directory.
----- Original Message ----- From: "Geert Bevin" <[EMAIL PROTECTED]> To: [email protected] Cc: [email protected], [email protected] Sent: Saturday, March 29, 2008 1:53:54 PM (GMT-0800) America/Los_Angeles Subject: Re: [tc-dev] need to standardize on the system property names How do we solve it? Maybe something was committed over the past days that I missed, but if I correctly remember (can't really check atm), we print out a one line warning and don't log on any of the other clients on that node. The only difference with what the CVT buffer does is that for the CVT, instructions are printed out how to solve it. In the demos however, we timestamp the log dirs, this is also what CVT does in for the demos. On 29 Mar 2008, at 16:41, Taylor Gautier <[EMAIL PROTECTED]> wrote: > Right, > > And in that case, we already solve this problem, so we should be > piggybacking on that solution. > > ----- Original Message ----- > From: "Geert Bevin" <[EMAIL PROTECTED]> > To: [email protected] > Sent: Saturday, March 29, 2008 12:42:52 PM (GMT-0800) America/ > Los_Angeles > Subject: Re: [tc-dev] need to standardize on the system property names > > Another thing to factor in is that currently the exact same problem > exists for log files when several clients are launched on the same > node. > > On Sat, Mar 29, 2008 at 12:57 PM, Steven Harris > <[EMAIL PROTECTED]> wrote: > > I forgot the third option of not starting the db until stats are > > requested. > > - Downsides > > would either leave caches lieing around > > or would give the error message when stats are started. > > > > How big an issue is this based on the fact that stats are for > testing > > right now not for > > production? > > > > > > > > On Mar 29, 2008, at 9:01 AM, Steven Harris wrote: > > > > > The way I see it we have two choices: > > > > > > either we need something that can be created and then destroyed > on > > > exit aka the deleteOnExit file > > > -The only objection of heard to this so far is that H2 doesn't > support > > > it. Is their a reason that we can't > > > make H2 do it? or could we look at other disk cache options? > > > > > > or > > > > > > We could enforce a unique home directory for each client where > it's > > > data > > > is stored. > > > - is their a way to make this not a pain for users? > > > > > > Lets go into this assuming the problem can and will be solved. > > > > > > > > > On Mar 29, 2008, at 6:51 AM, Geert Bevin wrote: > > > > > >> We've had problems with sticking the db in a temp directory, > some > > >> files on Gary's machine that were needed for the db's proper > working > > >> were removed on Windows while the application was still running. > > >> That's one of the reasons his first demo failed. > > >> > > >> Apart from all that, this really is a product choice, as any > approach > > >> is of course possible and I'm just talking from my preference. I > > >> however have to say that I have a strong aversion against > > >> applications > > >> that create new files by default on every run in a non > predictable > > >> location. > > >> > > >> On Thu, Mar 27, 2008 at 6:50 PM, Steven Harris <[EMAIL PROTECTED] > > >>> wrote: > > >>> We can't hack H2 to do this? and stick everything in the > default tmp > > >>> directory for the os? > > >>> > > >>> > > >>> > > >>> On Mar 27, 2008, at 6:41 PM, Geert Bevin wrote: > > >>> > > >>>> Don't think so since the db files are created by H2 and not > by us > > >>>> and > > >>>> there can be any number of files created for indexes, temp > queries, > > >>>> etc etc. > > >>>> > > >>>> On Thu, Mar 27, 2008 at 6:19 PM, Steven Harris <[EMAIL PROTECTED] > > >>>>> wrote: > > >>>>> I disagree but I'll live with it. BTW, java has a kind of > file the > > >>>>> deletes on exit of the JVM doesn't it? Can > > >>>>> we adjust the db to use that and then use the unique names? > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Mar 27, 2008, at 6:16 PM, Geert Bevin wrote: > > >>>>> > > >>>>>> We can, but I prefer not because that would defer any > problems > > >>>>>> with > > >>>>>> creating the db until the time that people actually need to > > >>>>>> capture > > >>>>>> statistics. Usually when that is the case, you don't want to > > >>>>>> have to > > >>>>>> start restarted clients and such to make sure that the > database > > >>>>>> can be > > >>>>>> created. > > >>>>>> > > >>>>>> On Thu, Mar 27, 2008 at 5:45 PM, Steven Harris <[EMAIL PROTECTED] > > >>>>>>> wrote: > > >>>>>>> Just out of curiosity. When do we create the db. Can we > wait to > > >>>>>>> do it > > >>>>>>> until someone does snapshotting? > > >>>>>>> > > >>>>>>> > > >>>>>>> On Mar 27, 2008, at 5:40 PM, Geert Bevin wrote: > > >>>>>>> > > >>>>>>>> Since otherwise at each execution it creates a new > version of > > >>>>>>>> the > > >>>>>>>> embedded database structure. > > >>>>>>>> > > >>>>>>>> On Thu, Mar 27, 2008 at 4:58 PM, Taylor Gautier > > >>>>>>>> <[EMAIL PROTECTED]> wrote: > > >>>>>>>>> Why would it need to be repeatable? > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> ----- Original Message ----- > > >>>>>>>>> From: "Geert Bevin" <[EMAIL PROTECTED]> > > >>>>>>>>> To: [email protected] > > >>>>>>>>> Sent: Thursday, March 27, 2008 4:42:21 PM (GMT-0800) > America/ > > >>>>>>>>> Los_Angeles > > >>>>>>>>> Subject: Re: [tc-dev] need to standardize on the system > > >>>>>>>>> property > > >>>>>>>>> names > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> It's unique, but not repeatable. I think this is ok for > the > > >>>>>>>>> demos, > > >>>>>>>>> but > > >>>>>>>>> not ok for regular applications since it creates a new > > >>>>>>>>> directory at > > >>>>>>>>> each execution. > > >>>>>>>>> > > >>>>>>>>> On Thu, Mar 27, 2008 at 4:36 PM, Taylor Gautier <[EMAIL > > >>>>>>>>> PROTECTED] > > >>>>>>>>>> > > >>>>>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>> So just to add color to this issue - the samples use the > > >>>>>>>>>> following > > >>>>>>>>>> convention: > > >>>>>>>>>> > > >>>>>>>>>> <logs>%(user.home)/terracotta/client-logs/pojo/ > sharededitor/ > > >>>>>>>>>> %D</logs> > > >>>>>>>>>> > > >>>>>>>>>> %D is a unique value. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Geert Bevin wrote: > > >>>>>>>>>> > > >>>>>>>>>> I wasn't suggesting which property should be used. My > point > > >>>>>>>>>> is > > >>>>>>>>>> that it > > >>>>>>>>>> should be the same and I do agree that it would be > handy to > > >>>>>>>>>> have > > >>>>>>>>>> some > > >>>>>>>>>> > > >>>>>>>>>> I agree with that, I was just clarifying why I chose the > > >>>>>>>>>> tc.node- > > >>>>>>>>>> name > > >>>>>>>>>> syntax and not tc.nodeName. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> kind of node discovery in place instead of using system > > >>>>>>>>>> properties. > > >>>>>>>>>> BTW, Maven property been there for over half a year > and no > > >>>>>>>>>> one > > >>>>>>>>>> reporter this inconsistency. > > >>>>>>>>>> > > >>>>>>>>>> I don't know what you mean by setup differently, all I > see is > > >>>>>>>>>> that > > >>>>>>>>>> if > > >>>>>>>>>> I remove <statistics> elements from tc-config those > dirs are > > >>>>>>>>>> created in > > >>>>>>>>>> the current folder, at least when this stuff is run from > > >>>>>>>>>> Maven. > > >>>>>>>>>> > > >>>>>>>>>> I just tried this and it seems to behave like that for > the > > >>>>>>>>>> client > > >>>>>>>>>> log > > >>>>>>>>>> dirs too. So it seems that when the logs and statistics > > >>>>>>>>>> elements > > >>>>>>>>>> are > > >>>>>>>>>> removed, the default values in the xsd aren't being > applied. > > >>>>>>>>>> This > > >>>>>>>>>> needs some further investigation. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Also it is really odd, that even if I specify different > > >>>>>>>>>> locations > > >>>>>>>>>> for > > >>>>>>>>>> those stats folders I still see that huge warning about > > >>>>>>>>>> directory is > > >>>>>>>>>> already being used when launching L1 and L2 from Maven. > > >>>>>>>>>> > > >>>>>>>>>> I tried that with the distribution samples and when I > change > > >>>>>>>>>> the > > >>>>>>>>>> client and server statistics paths, they relocate > properly to > > >>>>>>>>>> what I > > >>>>>>>>>> set them to. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> _______________________________________________ > > >>>>>>>>>> tc-dev mailing list > > >>>>>>>>>> [email protected] > > >>>>>>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> -- > > >>>>>>>>> Geert Bevin > > >>>>>>>>> Terracotta - http://www.terracotta.org > > >>>>>>>>> Uwyn "Use what you need" - http://uwyn.com > > >>>>>>>>> RIFE Java application framework - http://rifers.org > > >>>>>>>>> Music and words - http://gbevin.com > > >>>>>>>>> _______________________________________________ > > >>>>>>>>> tc-dev mailing list > > >>>>>>>>> [email protected] > > >>>>>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev > > >>>>>>>>> > > >>>>>>>>> _______________________________________________ > > >>>>>>>>> tc-dev mailing list > > >>>>>>>>> [email protected] > > >>>>>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> -- > > >>>>>>>> Geert Bevin > > >>>>>>>> Terracotta - http://www.terracotta.org > > >>>>>>>> Uwyn "Use what you need" - http://uwyn.com > > >>>>>>>> RIFE Java application framework - http://rifers.org > > >>>>>>>> Music and words - http://gbevin.com > > >>>>>>>> _______________________________________________ > > >>>>>>>> tc-dev mailing list > > >>>>>>>> [email protected] > > >>>>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev > > >>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> tc-dev mailing list > > >>>>>>> [email protected] > > >>>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev > > >>>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> -- > > >>>>>> Geert Bevin > > >>>>>> Terracotta - http://www.terracotta.org > > >>>>>> Uwyn "Use what you need" - http://uwyn.com > > >>>>>> RIFE Java application framework - http://rifers.org > > >>>>>> Music and words - http://gbevin.com > > >>>>>> _______________________________________________ > > >>>>>> tc-dev mailing list > > >>>>>> [email protected] > > >>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev > > >>>>> > > >>>>> _______________________________________________ > > >>>>> tc-dev mailing list > > >>>>> [email protected] > > >>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev > > >>>>> > > >>>> > > >>>> > > >>>> > > >>>> -- > > >>>> Geert Bevin > > >>>> Terracotta - http://www.terracotta.org > > >>>> Uwyn "Use what you need" - http://uwyn.com > > >>>> RIFE Java application framework - http://rifers.org > > >>>> Music and words - http://gbevin.com > > >>>> _______________________________________________ > > >>>> tc-dev mailing list > > >>>> [email protected] > > >>>> http://lists.terracotta.org/mailman/listinfo/tc-dev > > >>> > > >>> _______________________________________________ > > >>> tc-dev mailing list > > >>> [email protected] > > >>> http://lists.terracotta.org/mailman/listinfo/tc-dev > > >>> > > >> > > >> > > >> > > >> -- > > >> Geert Bevin > > >> Terracotta - http://www.terracotta.org > > >> Uwyn "Use what you need" - http://uwyn.com > > >> RIFE Java application framework - http://rifers.org > > >> Music and words - http://gbevin.com > > >> _______________________________________________ > > >> tc-dev mailing list > > >> [email protected] > > >> http://lists.terracotta.org/mailman/listinfo/tc-dev > > > > > > _______________________________________________ > > > tc-dev mailing list > > > [email protected] > > > http://lists.terracotta.org/mailman/listinfo/tc-dev > > > > _______________________________________________ > > tc-dev mailing list > > [email protected] > > http://lists.terracotta.org/mailman/listinfo/tc-dev > > > > > > -- > Geert Bevin > Terracotta - http://www.terracotta.org > Uwyn "Use what you need" - http://uwyn.com > RIFE Java > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
