3

I am developing application which is embedded within the cluster environment in Websphere AS. I am using several nodes and sometimes I would like to change configuration settings on the fly and propagate it to all nodes within the cluster. I don't want to hold the config in the db or at least I would like to cache it on the node level and trigger config refresh action which forces each node to refresh the config from some common ground (i.e. db or net drive) to avoid constant round-trips to the config storage.

More over some configuration can't be stored in db i.e. log level needs to be applied on the logger object in each node separately.

I was thinking about using JMS Topics and publish/subscribe approach to achive that goal. The idea is that each node could subscribe to each Topic and no matter which nodes initate the config change modification would be propagated to all nodes within the cluster.

Has anyone ever tried to do that in WAS and whether there are any obstacles with this approach. If there are or if you have any other suggestion on how to solve that problem I would be very greatfull for your help.

Tx in advance, Marcin

Has QUIT--Anony-Mousse
  • 76,138
  • 12
  • 138
  • 194
Marcin Michalski
  • 1,266
  • 13
  • 17

2 Answers2

1

Here are a few options to consider as alternatives to JMS -

  • Use Java EE environment entries. These are scoped to the application, and WAS will automatically propagate any changes to all servers against which the application is deployed. This is a good approach since it is the standard Java EE approach to application configuration, if it is robust enough to meet your use case.

  • Use a WebSphere Shared Library. This allows you to link your applications to static files external to your application (i.e. on the filesystem), such that they are available on your classpath. Although these files are located on the node file systems, there is a way that you can place these files in WebSphere's centralized configuration repository such that they are automatically propagated to all WAS nodes. For more details on this, see this answer.

Both of these options are optimized for static configuration; in other words, configuration settings that are intended to be set at assembly-time, deployment-time, or to be changed by system administrators, but they are not typically used for values that change frequently, nor are they generally changed programmatically at runtime. WAS does allow your applications to pick these configuration settings in a rolling fashion, such that no application downtime is required though.

Community
  • 1
  • 1
shelley
  • 7,206
  • 4
  • 36
  • 63
  • Hi Shelley. Tx for your answer although this is not what I'm really looking for. For that kind of configuration I may use DB instead. The thing is that I would like to modify configuration on the fly. the other side effect of this approach is that it requires 3rd party participation (WAS administration) which additionally delays quick reconfiguration (especially when there is lots of corporate bureaucracy related with any WAS reconfiguration that I would like to avoid). What I really need is to be able to propagate configuration right away without any help from the WAS team. – Marcin Michalski Nov 27 '11 at 19:07
  • @MarcinMichalski I think it's quite a sound answer, don't expect people to know about what WAS GOT 2ND can or can't do. Besides, with your JMS topic solution you'd have to go ask them for reconfiguring, too. – MaDa Nov 28 '11 at 19:35
  • Yes true but I would ask WAS team only once not each time when it would require reconfiguration. And I'm not saying that topic approach is the right one that is why I have asked this question first. What I'm only saying is that the solution with env-entries is not sufficient in this case first of all because it requires additional help and application moderator cannot change that on the fly and additionally some reconfiguration cannot be performed using env-entries i.e. changing log level. – Marcin Michalski Dec 01 '11 at 21:33
0

Currently we solved the problem with maybe not the most pretty approach but with the most simple one. Since we are using only 2 nodes we have possibility to enter web interface of specific node where we modify settings per each node. Maybe it is not very pretty but for now it is the easiest way. The config is stored in DB and we are planning to trigger config reload in each node and change the log level per node as well.

Marcin Michalski
  • 1,266
  • 13
  • 17