Ah, Cool, my bad. On Apr 15, 2008, at 5:28 AM, Geert Bevin wrote:
> It already streams the data during the capture session. The case where > everything is buffered up and streamed at capture stop is actually > currently not yet implemented. > > Added a comment to http://jira.terracotta.org/jira/browse/CDV-708 for > the in-memory H2 usage. > > On 15 Apr 2008, at 14:20, Steven Harris wrote: >> Sounds like a good idea, lets discuss whether this should be for >> stable 2 or 2.6.1. Can you create a Jira around >> the idea. We need to think about defaults, and how to best decide >> which mode to run in. We might need to implement >> a mechanism to stream the data to the server earlier than on capture >> stop. >> >> Cheers, >> Steve >> >> On Apr 14, 2008, at 11:21 PM, Geert Bevin wrote: >> >>> 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 >> >> _______________________________________________ >> 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
