I just thought of a very unintrusive 'fix' that would allow both in-memory and on-disk statistics buffering to be possible with the current implementation. H2 can be run in memory-only mode where nothing is written to disc, this is merely a change to the JDBC connection URL. I'd also have to remove the additional file locking that I added around the entire database installation, but besides that it should be no effort.
On Sun, Mar 30, 2008 at 1:03 AM, 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 _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
