RE: Lateral TCP Cache config file

[Mitch Gorman <go...@sportsline.com>]

[apologies to youngho cho, for hijacking his thread!]

> Since the TCP server binds to a port, you'd have to bind to a 
> different port on the other instance.  

	well, yeah... but would anything be *received* on that port?  or
rather, would anything be *sent* on that port, for it to receive?

	actually, what *is* the TCPListenerPort for?  in 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...
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?

	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?

> 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.  (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.)  i
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?)

> 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?

 
-- 
Mitch Gorman
gorman@sportsline.com <ma...@sportsline.com> 


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.9.5/58 - Release Date: 7/25/2005
 

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

RE: Lateral TCP Cache config file

[Aaron Smuts <as...@yahoo.com>]

--- Mitch Gorman <go...@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
discovery.

in
> 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"!!)  
> 

Ha!

> 	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.

 i
> 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.

Aaron



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