Which original issue in particular are you talking about? tc.nodeName vs. tc.node-name ?
or https://jira.terracotta.org/jira/browse/CDV-584 ? The second one needs someone to put a little effort into tracking down why the default values aren't used, and fix it. The first one needs someone to decide upon TC system properties nomenclature. On one hand we have tc.node-name, tc.install-root, tc.base-dir, ... but there's also l2.cachemanager.leastCount, l2.cachemanager.percentageToEvict, ... It would be good to standardize them all, however changing tc.install-root is probably more invasive wrt. existing installations than changing the others. Anyway, the 'tc.node-name' I mention is just some text in the warning, it could be anything. There's no code that uses this at all. It really is, like Hung said, a suggestion and not a requirement. However, I did a search through the code and it seems that 'tc.node- name' is also being used in com.tc.management.ManagementResources for DSO client VMs to be able to override their hostname. So any way we standardize, either the Maven plugin has to change, either the convention for Terracotta management needs to change. It seems that this property name inconsistency dates from before the CVT warning text. ... Taylor? ... Steve? On 15 Apr 2008, at 19:11, Eugene Kuleshov wrote: > > This is all great, but what about the original subject and problem > that we still have? > > > 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. >>>> >>>> > > _______________________________________________ > 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
