I was wondering if we could use ClientID (assinged to each client by
DSO server) as a unique folder name for the clients' logs. If users
specify the paths in tc-config.xml then we'll use those. If not, dump
all logs and statistics files to workingdir/terracotta/$ClientID
Hung-
Steven Harris wrote:
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
|
