With all the new changes to the watchdog process to make it more  
secure (which is a good thing), I have come across behavior that is  

I have two config files, one for the web tier and one for the backend  
app tiers.  The configuration is fairly similar to how the  
documentation states.

1) the resin-web.conf (for the web tier) has its own set of  
configuration settings.  However, in order for the Load Balancing  
Servlet to see the app tier clusters and servers, I need to include  
minimal <cluster> config inside resin-web.conf:

<cluster id='abc'>
   <server id='abc' port='6800' .../>

This is the minimal that will allow the load balancing servlet to  
understand where to dispatch the requests in the rewrite section.

2) I then have resin.conf file that contains all the app tier config  
settings for all clusters.

This configuration worked well even in 3.1.5 snapshots, but when I  
upgraded to 3.1.5, I started seeing "duplicate server id" exceptions  
thrown by the watchdog process.

 From what I can gather, I believe that the watchdog process is tying  
configuration filenames to the settings now.  So in this case, if I  
start up the web tier cluster on the same machine as the app tier and  
then start up one of the app tier cluster servers, watchdog will think  
that it's trying to register a duplicate server id.

By putting all the resin-web.conf configuration info into resin.conf,  
watchdog process doesn't complain any longer.

Given the new watchdog process monitoring, I'm thinking that the Load  
Balancer Servlet can be enhanced to work with the new watchdog  
process.  Here's what I'm proposing:

1) Watchdog process contains all the cluster names and server ids.
2) web tier's load balancer servlet only needs to know the cluster  
name and doesn't require any additional <cluster> configurations in  
the CONF file.  It will then query the cluster information from the  
watchdog process in some way to determine where to redirect the  
request to.

Or is there perhaps another way to configure the watchdog process so  
that it won't think that the web tier config is trying to register new  
clusters?  Or possibly I need to create three config files, one for  
web tier, one for app tier, and one shared conf file that contains all  
the cluster configurations that will be resin:import'ed into the web  
and app tier?


resin-interest mailing list

Reply via email to