Every inch of the system gets reviewed and redesigned all the time. We made some assumptions back then, one of them being that we needed a client side cache and I was thinking about it and trying to decided in my head as to whether I still believed it was necessary or not. I see it as just a part of the process of iterating on and potentially improving the system.
Anyway, while the logs are certainly a similar class of problem their is always the possibility that each has a solution that is best for each issue. Can't hurt to explore those avenues independently and then seeing if the ideas for each can be applied to the other. It's not like we have to go off and implement anything right away but why not think about these things with the assumption that solutions exist. We have solved many an impossible problem with that mindset in the past. Cheers, Steve On Mar 29, 2008, at 4:12 PM, Geert Bevin wrote: > I don't understand where this is going though, all these issues were > discussed at length during the design process. Why are we questioning > what we decided back then for a problem that has nothing to do with > CVT. The fact that log files have been unavailable for as long as I > can remember on clients that don't setup tc-config.xml when they run > on the same node, seems much more critical to me than the statistics > system not being available. If that problem is solved, the CVT can use > exactly the same approach. > > On Sat, Mar 29, 2008 at 7:07 PM, Geert Bevin <[EMAIL PROTECTED]> wrote: >> That entirely depends on how many statistics are being captured, what >> the sample size is and what the emission frequency is. >> >> >> >> On Sat, Mar 29, 2008 at 7:03 PM, Steven Harris <[EMAIL PROTECTED] >> > wrote: >>> That can't be done in memory? How much data are we talking about? >>> >>> >>> >>> On Mar 29, 2008, at 4:02 PM, Geert Bevin wrote: >>> >>>> We need the client side db as a buffer so that the stats >>>> capturing and >>>> storage can complete immediately and the stats emitter can be >>>> batched >>>> and done in the background. >>>> >>>> On Sat, Mar 29, 2008 at 6:58 PM, Steven Harris <[EMAIL PROTECTED] >>>>> wrote: >>>>> >>>>> Are we sure we even need the client side db? How big does this >>>>> thing get? >>>>> can it be optional? >>>>> >>>>> >>>>> >>>>> >>>>> On Mar 29, 2008, at 2:08 PM, Taylor Gautier wrote: >>>>> >>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > > > -- > 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
