Re: gcache imlementation ideas[long]

[Jason Dillon]

I will wait and see what you come up with first :-)

--jason


On Sep 15, 2006, at 2:25 AM, Jeff Genender wrote:

Jason Dillon wrote:

Aight... well, lets see the interfaces and the socket impl and I will

write the jms impl and see which fairs better with the most features :-P

Write it!  That would be awesome ;-)

As a side note, shall we race?  TCP vs JMS? ;-) j/k

--jason


On Sep 14, 2006, at 8:17 PM, Kevan Miller wrote:

I'm with Jeff on this one...

I've seen this done w/ JMS. However, there's so much JMS overhead that

you don't need (message formats, persistent messages, delivery
semantics, etc).

I recall Jeff was talking to Hiram about ActiveIO -- that's the more
appropriate way to go. Reuse common technology, but not all of AMQ.

--kevan

On Sep 14, 2006, at 6:26 PM, Jason Dillon wrote:

On Sep 14, 2006, at 7:56 AM, Jeff Genender wrote:

The JMS provider would be a pluggable comm strategy. For performance

reasons, I want to start with TCP communication.

Why do you think that AMQ will not perform well?

I definitely want to
have a JMS strategy...maybe next.  But initially I don't want any
dependencies on other servers or brokers.

With that said, after looking at openwire, the comm marshaller for
ActiveMQ, there is a lot to leverage there and will prevent a
rewrite of
the comm layer.  So, there will be some use of that code base
initially.

IMO, AMQ already provides a rich clustering environment, with

failover, master-slave, dynamic discovery, firewall-happy transports,

monitoring and a heck of a lot more.

Seems like it would be a waste to go and re-implement all of that.

It also seems that if you wanted to get something up sooner, that it would be much easier to design a AMQ strategy first, which means that

you only have to worry about the message passing to sync up and
invalidate state, rather than all of the details of who is in what
cluster, failing over, blah, blah...

And, I guess that if after that was implemented you still thought it

was not fast enough, then it might be better to get AMQ fixed to
perform better, though I don't think that the performance using AMQ
will differ all that much from a custom socket protocol to pass
messages.

I am a huge fan of AMQ and would really like to see G exploit its
network communications facilities as much as possible.

IMO, this is the best way to get the most features for clustering up

and running sooner, with less code to maintain.

--jason