jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Smuts <asm...@yahoo.com>
Subject RE: Lateral TCP Cache config file
Date Thu, 28 Jul 2005 01:09:34 GMT

--- Mitch Gorman <gorman@sportsline.com> wrote:

> 	actually, what *is* the TCPListenerPort for?  

The listener port is the port on which a socket server
will listen.  Each TCP lateral will create a socket
server used by all regions that are configured to use
it.  It in turn creates connections with all other
servers in the server list or those found through

> the non-discovery
> config, you're specifying the explicit hosts *and*
> ports to connect to...
> and in the discovery version, the discovery is done
> via the UDP multicast...

Yes.  That's just a discovery address and port.  No
data is sent to that address, only messages about
where certain laterals are located.

> so what's actually coming across TCPListenerPort? 
> is that where the gets &
> puts from other servers are received?  that's gotta
> be it, 'cuz i can't see
> the need to explicitly specify (and "publish" it in
> the config file) for
> any other purpose.  correct?

Yes.  Discovery is just the location of
servers--addresses and ports.  

We could add a port range.  The lateral would then try
various ports until it found one open.  This would
allow you to use the same config file for multiple
instances.  This wouldn't be too hard.

> 	assuming that's the case, how do other server
> instances know to push
> data out on that particular port?  is that info
> exchanged during the
> discovery?

Yep.  If discovery is enabled, the cache will both
listen and broadcast.  It listens to a udp address for
messages broadcasted by others.  If it gets a message
from another server and port, it will try to create a
conenction to that server.

The connections are monitored and a restore process is
in place in case of failure. . . .

> > The easiest way is to have a different config file
> for the 
> > second server.  You could put the port in jndi,
> pull
> > it out of jndi in a startup servlet, load the
> cache.ccf properties,
> > change the port value, and then initialize the
> cache using the
> > Properties that you have modified.  
> 	so that's what you call "easiest", is it?  ;)  (i
> shudder to think
> what you'd consider "complex"!!)  


> 	at the moment, i'm not employing servlets at all...
> this is purely a
> java application server app and java application
> client app. 

Ok.  That will work too.  

 (well, the
> client *may* move to a web interface, considering
> how google has
> demonstrated what kind of cool stuff javascript can
> be used to do.) 

Yes.  Google is incredible.

> actually was trying to wend my way thru the
> javadocs, and see if, from a JCS
> object, there was a way to gain access to a
> LateralCacheAttributes object
> (so that i could explicitly call
> setTcpListenerPort(), but couldn't see how
> to connect those dots.  (it's nice that all you
> really *need *to do is
> instantiate a JCS object, but it'd be pretty handy
> to be able to get to
> those underpinnings programmatically when needed,
> don't you think?)

Yes.  It is difficult to do this.  I'm been planning
some ways to get hooks into the cache.  For now, it is
done at config time.  If you will programatically
change it, you might as well programatically change it
at config time.  As such, there has been no pressing
need for this feature.  Any ideas are appreciated. . .

About all you have now is in the get stats methods. 
This get information from all of the auxiliaries. 

> > This would allow you to use the same
> > config file, and only have different server
> configurations, which you
> > will have to have anyway.
> 	hmm... as far as i can see, the TCPListenerPort
> setting is the only
> thing that needs to be distinct, per instance.  what
> else is there that you
> feel would require different config files?

If you use a disk cache, then you need to set the
directory to be relative, but if it is absolute, it
has to be different per instance.  That's all.


To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org

View raw message