It's a matter of what you want to say to the users:
(1) Putting it in the Javaspaces spec allows users to be (not entirely but
reasonably) confident of consistent behaviour across all implementations
such that their code will run on any one they choose with no change.
(2) Putting it in the Outrig
An old geek joke, related to the mad trademarking of just about anything
On 21 December 2010 00:28, MICHAEL MCGRADY wrote:
> Dan, what is "(TM)"?
>
> On Dec 20, 2010, at 1:13 PM, Dan Creswell wrote:
>
> > Blitz too has optional FIFO-ness via configuration though it's absolutely
> a
> > perfor
MICHAEL MCGRADY wrote:
What is the spec that is being potentially changed? Outrigger can
promise FIFO but this does not mean, I assume, that other
implementations of JavaSpaces have to deliver FIFO as well. Pulling
an implementation into the specs for JavaSpaces would, I think, be
counter-produ
I also agree.
MG
On Dec 20, 2010, at 2:22 PM, Gregg Wonderly wrote:
> On 12/20/2010 3:19 PM, Dan Creswell wrote:
>> If that's what is required, you'd best change the spec to reflect this
>> default. Failing to do this leaves developers open to nasty surprises like:
>>
>> (1) Develop code on jav
What is the spec that is being potentially changed? Outrigger can promise FIFO
but this does not mean, I assume, that other implementations of JavaSpaces have
to deliver FIFO as well. Pulling an implementation into the specs for
JavaSpaces would, I think, be counter-productive.
MG
On Dec 20,
Dan, what is "(TM)"?
On Dec 20, 2010, at 1:13 PM, Dan Creswell wrote:
> Blitz too has optional FIFO-ness via configuration though it's absolutely a
> performance killer for any decent concurrent load by virtue of the usual
> suspects such as lock contention and the high chance of scanning entry's
Seems to me that FIFO handling would be a bit of an illusion at the best
of times. What happens if you take an entry within a transaction, then
the transaction gets rolled back? The entry gets dropped back into the
space, in a different order than the original.
I've always assumed that if you w
On 12/20/2010 3:19 PM, Dan Creswell wrote:
If that's what is required, you'd best change the spec to reflect this
default. Failing to do this leaves developers open to nasty surprises like:
(1) Develop code on javaspace that supports FIFO by default.
(2) Pronounce code safe and debugged.
(3) Dep
If that's what is required, you'd best change the spec to reflect this
default. Failing to do this leaves developers open to nasty surprises like:
(1) Develop code on javaspace that supports FIFO by default.
(2) Pronounce code safe and debugged.
(3) Deploy code onto some other javaspace (e.g. a co
Blitz too has optional FIFO-ness via configuration though it's absolutely a
performance killer for any decent concurrent load by virtue of the usual
suspects such as lock contention and the high chance of scanning entry's
that have just been taken by a thread just ahead in the queue.
To be honest
On 12/20/2010 2:30 PM, Patricia Shanahan wrote:
Tom Hobbs wrote:
I know of at least one company which uses Outrigger specifically
because of it's fortuitous FIFO behaviour. I'm trying to encourage
them to move from the Jini 2.1 code to the River release and losing
the FIFO-ness might be an issue
Tom Hobbs wrote:
I know of at least one company which uses Outrigger specifically
because of it's fortuitous FIFO behaviour. I'm trying to encourage
them to move from the Jini 2.1 code to the River release and losing
the FIFO-ness might be an issue for them.
And yes I know, the spec doesn't spe
I know of at least one company which uses Outrigger specifically
because of it's fortuitous FIFO behaviour. I'm trying to encourage
them to move from the Jini 2.1 code to the River release and losing
the FIFO-ness might be an issue for them.
And yes I know, the spec doesn't specify FIFO, like I s
On 12/17/2010 8:00 AM, Gregg Wonderly wrote:
...
One of the primary issues with bandwidth through any system is latency.
While multiprocessor/multi-core and distributed computing can provide
huge bandwidth possibilities, the underlying issue is per transaction
latency.
If you look simply, at the
On 12/17/2010 10:22 AM, Gregg Wonderly wrote:
On 12/16/2010 9:35 PM, Patricia Shanahan wrote:
I would love to be able to base it on a ConcurrentMap, but I don't see
how it
would work.
As far as I can tell, there is no clean split between key and non-key
among the
entry's public fields. A templa
On 12/16/2010 9:35 PM, Patricia Shanahan wrote:
I would love to be able to base it on a ConcurrentMap, but I don't see how it
would work.
As far as I can tell, there is no clean split between key and non-key among the
entry's public fields. A template can specify values for any subset of the
fie
On 12/16/2010 3:02 PM, Wade Chandler wrote:
Now, the one place that doesn't seem a waste of time is using those unmarshalled
Entries and fields for lookup. Seems having those realized in memory already is
much faster. A way to speed up the overall effort would be to store the
serialized form alon
I concur.
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Dec 17, 2010, at 8:00 AM, Gregg Wonderly wrote:
> On 12/16/2010 8:09 AM, Sim IJskes - QCG wrote:
>> On 16-12-10 14:55, Patricia Sh
On 12/16/2010 8:09 AM, Sim IJskes - QCG wrote:
On 16-12-10 14:55, Patricia Shanahan wrote:
However, we should be able to do, say, hundreds of millions of
transactions in a day in real-time critical systems such as the FAA
or the stock market with data affinity and integrity and all the
other "il
If the system was linearly scalable and the result was fast enough, no. For
me, philosophy is dead and engineering lives. I don't care about definitions
and such, I care about results and that is what you mean. I agree
wholeheartedly.
MG
On Dec 16, 2010, at 7:58 PM, Patricia Shanahan wrote
On 12/16/2010 12:48 PM, MICHAEL MCGRADY wrote:
...
So, I think the non-functional requirements and related technologies,
e.g., clustering, in-memory access, etc., are primary. For example,
when scaling is at issue, it is not important that 300,000,000
transactions can be handled in 10 hours, say
On 12/16/2010 1:15 PM, Jeff Ramsdale wrote:
In response to Wade's HashMap comments...
I've wondered for a while if a JavaSpaces implementation could be
built on ConcurrentMap. If so, and if the implementation were
pluggable at runtime, one could provide Infinispan
(http://www.jboss.org/infinispa
I have no problem with this as a base for discussing the long term issues.
In the short term, there is another Jira I need to write - reporting a
bug in Outrigger. I got into this because of an intermittent QA test
failure on Hudson. That needs to be fixed, either by finding out what is
specif
Sim,
It is not any of these things. I think that both an in-memory system and a db
system are options and important to provision, and a lot of other alternatives
as well. I do not know how you get to the touching Entry conjecture.
We were talking about increased performance and about qualit
On 12/16/2010 09:48 PM, MICHAEL MCGRADY wrote:
mean we do not do databases. Of course we do. Doesn't everyone?
However, the primary data model and structures have to be in-memory
because we cannot tolerate the time database calls take (in-memory is
approximately 10,000 times faster). I think t
In response to Wade's HashMap comments...
I've wondered for a while if a JavaSpaces implementation could be
built on ConcurrentMap. If so, and if the implementation were
pluggable at runtime, one could provide Infinispan
(http://www.jboss.org/infinispan/) caches (which implement
ConcurrentMap) to
.org"
> Cc: "river-dev@incubator.apache.org"
> Sent: Thu, December 16, 2010 10:04:55 AM
> Subject: Re: datastructure classes
>
> Intense network systems like our clients cannot work with database calls.
>They are too slow and do not scale. They either reach
Just a few thoughts below, which are advanced to add to the conversation, not
detract from it.
On Dec 16, 2010, at 8:01 AM, Patricia Shanahan wrote:
> Mike McGrady wrote:
>> Intense network systems like our clients cannot work with database
>> calls. They are too slow and do not scale. They e
On 16-12-10 17:14, Mike McGrady wrote:
I didn't intend to be contentious. I have absolutely nothing against
databases and am only giving my experience, and Oracles experience,
in relation to this topic which I am greatly interested in. I think
I can convince the group/list this is not a good st
I've taken the liberty of creating a new Jira for the refactoring of
FastList in the Outrigger internals.
https://issues.apache.org/jira/browse/RIVER-386
Sorry is that's presumptuous or if the wording of ticket is wrong. I
thought it'd be good to start getting something a bit more structured
dow
I didn't intend to be contentious. I have absolutely nothing against databases
and am only giving my experience, and Oracles experience, in relation to this
topic which I am greatly interested in. I think I can convince the group/list
this is not a good start.
Everyones thoughts could be sta
Mike McGrady wrote:
Intense network systems like our clients cannot work with database
calls. They are too slow and do not scale. They either reach a cost
or a performance ceiling.
I feel we are mixing requirements and implementation. Response time,
throughput, ACID properties and the like a
On 16-12-10 16:11, Mike McGrady wrote:
The experience in the industry is that writing directly to a database
is too slow and reaches either a cost or a performance ceiling . The
prime candidates for a tuple-space application in the real world is
lost, I think, if you write to a database and not
I am not saying, however, that we don't do transactions. It is also critical
and so to with replication and partitioning.
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Dec 16, 2010, at 6
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Dec 16, 2010, at 6:09 AM, Sim IJskes - QCG wrote:
> On 16-12-10 14:55, Patricia Shanahan wrote:
>>> However, we should be able to do, say,
Intense network systems like our clients cannot work with database calls. They
are too slow and do not scale. They either reach a cost or a performance
ceiling.
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
On 16-12-10 14:55, Patricia Shanahan wrote:
However, we should be able to do, say, hundreds of millions of
transactions in a day in real-time critical systems such as the FAA
or the stock market with data affinity and integrity and all the
other "ilities". If Outrigger cannot do this, it is of no
MICHAEL MCGRADY wrote:
Patricia,
If you don't mind, I am going to argue for sticking to the machines,
but answer your question roughly at the end.
I don't mind machines, as long as they get somewhat quantified. It was
"machines a minute" that really gave me trouble. However, there are
machines
Patricia,
If you don't mind, I am going to argue for sticking to the machines, but answer
your question roughly at the end.
The questions about either memory use or connections or transactions are
stressors leading to the question and the urgency whether or not something must
scale, but they h
On 12/14/2010 3:40 PM, Patricia Shanahan wrote:
On 12/14/2010 8:37 AM, Gregg Wonderly wrote:
On 12/14/2010 1:36 AM, MICHAEL MCGRADY wrote:
I would say that in addition to just be a fast data structure the data
structure
> must be fast and accommodate synchronous and asynchronous backups,
parti
Please clarify "machines a minute". Can you express it e.g. in
transactions per minute?
Patricia
Mike McGrady wrote:
Linear - 7000 machines a minute, or more.
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
C
Patricia,
Here is an update from one of the authors of the PDF you cited.
Mr. McGrady,
In a paper on lock-free memory management
(http://www.research.ibm.com/people/m/michael/ieeetpds-2004.pdf) I describe a
variant of the lock-free algorithm in the PODC 1996, such that the memory used
by the n
Linear - 7000 machines a minute, or more.
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Dec 14, 2010, at 2:04 PM, Patricia Shanahan wrote:
> On 12/14/2010 1:49 PM, MICHAEL MCGRADY wrote:
On 12/14/2010 1:49 PM, MICHAEL MCGRADY wrote:
On Dec 14, 2010, at 1:40 PM, Patricia Shanahan wrote:
...
If we made a persistent version use a relational database to represent
the space,
This would not be usable for us. This is too slow and does not have the
correct QCC features, especially
On Dec 14, 2010, at 1:40 PM, Patricia Shanahan wrote:
> On 12/14/2010 8:37 AM, Gregg Wonderly wrote:
>> On 12/14/2010 1:36 AM, MICHAEL MCGRADY wrote:
>>> I would say that in addition to just be a fast data structure the data
>>> structure
>> > must be fast and accommodate synchronous and asynchro
On 12/14/2010 8:37 AM, Gregg Wonderly wrote:
On 12/14/2010 1:36 AM, MICHAEL MCGRADY wrote:
I would say that in addition to just be a fast data structure the data
structure
> must be fast and accommodate synchronous and asynchronous backups,
partitions,
> and transactions.
This is an importan
Understand, however scala also copy-on-write most of the time because
list is immutable -
http://www.artima.com/scalazine/articles/steps.html , I guess this may
not as expensive as it seem?
I don't really "selling" this api, however, I feel it would be
acceptable to give it a try, and see how it p
One of the primary types of data structures that I'm thinking about is a skip
list as defined by Bill Pugh's (http://www.cs.umd.edu/~pugh/) paper:
ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf
The upshot is that a skip list provides compartmentalization/segmentation of
data which might prov
On 12/14/2010 1:36 AM, MICHAEL MCGRADY wrote:
I would say that in addition to just be a fast data structure the data structure
> must be fast and accommodate synchronous and asynchronous backups, partitions,
> and transactions.
This is an important issue from the perspective that there are two
++ this is so important. The days of read mostly are gone.
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Dec 14, 2010, at 7:25 AM, Patricia Shanahan wrote:
> Carfield Yim wrote:
>> Hi
Carfield Yim wrote:
Hi, copyonwritearraylist is suitable for this case imho. But it don't sound
like an option to you. Would you share a bit more. I am interest to learn
about it.
My first feeling was that there is at least one workload that seems
plausible to me for which it would have poor pe
++
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Dec 14, 2010, at 3:33 AM, Peter wrote:
>
> - Original message -
>> On 12/13/2010 11:48 PM, Peter wrote:
>>> Pats, I think James
Note that multiple JVMs impact real-time constraints in ways that demand
farsighted planning.
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Dec 14, 2010, at 3:19 AM, Carfield Yim wrote:
++
And I would add in relation to the unique opportunities provided by the deep
architectural features of River including especially outrigger and rio.
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.7
For my part the "for the ages" implementation of this function is required. I
am thinking about Brewer's Theorem and other related "omitted" or
non-functional values or quality control criteria (QCC) in related to this
functionality. You have chosen your target well, I believe.
Sent from my i
- Original message -
> On 12/13/2010 11:48 PM, Peter wrote:
> > Pats, I think James is talking about my classes. James, thanks for the
> > links,
> > much appreciated, I hope you'll find time to participate more often.
> ...
>
> And I really should stop hijacking this thread.
I think yo
Hi, copyonwritearraylist is suitable for this case imho. But it don't sound
like an option to you. Would you share a bit more. I am interest to learn
about it.
On Dec 14, 2010 9:15 AM, "Patricia Shanahan" wrote:
>
> You make a good point that I should take a look around to see if I can
find anythi
On 12/13/2010 11:48 PM, Peter wrote:
Pats, I think James is talking about my classes. James, thanks for the links,
much appreciated, I hope you'll find time to participate more often.
...
And I really should stop hijacking this thread. Despite my preoccupation
with FastList, I do realize that
On 12/13/2010 11:48 PM, Peter wrote:
Pats, I think James is talking about my classes. James, thanks for
the links, much appreciated, I hope you'll find time to participate
more often.
I have the utmost faith in Pats ability.
Cheers,
Peter.
...
I've got some concurrent utilities in pepe you m
On 12/13/2010 11:36 PM, MICHAEL MCGRADY wrote:
I would say that in addition to just be a fast data structure the
data structure must be fast and accommodate synchronous and
asynchronous backups, partitions, and transactions.
How much of that should be in the bottom layer? As far as I can tell,
On 12/13/2010 11:32 PM, MICHAEL MCGRADY wrote:
Patricia
http://www.cse.lehigh.edu/~spear/
http://www.cs.rochester.edu/u/vmarathe/
http://www.cs.rice.edu/~wns1/
http://www.cs.rochester.edu/u/scott/papers/2003_FTDCS_IW.pdf
A few other sources that are not so antiquated, which is not a negative.
Pats, I think James is talking about my classes. James, thanks for the links,
much appreciated, I hope you'll find time to participate more often.
I have the utmost faith in Pats ability.
Cheers,
Peter.
- Original message -
> You make a good point that I should take a look around to s
I would say that in addition to just be a fast data structure the data
structure must be fast and accommodate synchronous and asynchronous backups,
partitions, and transactions.
On Dec 13, 2010, at 5:15 PM, Patricia Shanahan wrote:
> You make a good point that I should take a look around to see
Patricia
http://www.cse.lehigh.edu/~spear/
http://www.cs.rochester.edu/u/vmarathe/
http://www.cs.rice.edu/~wns1/
http://www.cs.rochester.edu/u/scott/papers/2003_FTDCS_IW.pdf
A few other sources that are not so antiquated, which is not a negative. I
have asked Prof Scott to share his latest rese
Nice! If you would like me to look at some sources, please do.
MG
On Dec 13, 2010, at 5:15 PM, Patricia Shanahan wrote:
> You make a good point that I should take a look around to see if I can find
> anything suitable that already exists, with appropriate licensing.
>
> That said, I believe t
You make a good point that I should take a look around to see if I can
find anything suitable that already exists, with appropriate licensing.
That said, I believe the requirements for an outrigger FastList are:
1. Highly scalable performance. In particular, iterating over the list
should be f
66 matches
Mail list logo
