Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Reload Java Collaboration Rule in Multi Mode eWay

Status
Not open for further replies.

cliffblob

Programmer
Aug 26, 2002
8
0
0
US
Hi, I do not think this can be done but I will ask anyway. We are in the process of converting some of our Monk eWays to Multi Mode Java (stceway.exe) eWays. One requirement of the project is that we support all of the functionality we supported in our Monk eWays, and one bit of functionality is the ability to reload a "subcollaboration" without having to stop and restart the eWay. We have hundreds of collaborations and they are frequently being modified for a variety of reasons and it is not possible for us to shut down the application every time we want to promote an updated collab.

In Monk it is very easy, the eWay accepts a specific message type which tells the eWay to reload the collab and the code looks like this:
;;Check if this is just a reload message
(if (string-begins-with? message-string "RELOAD")
(begin
;; Reload collab
(load (substring message-string 6 (string-length message-string)))
)
)

In a Java Collaboration Rule when you want to load a subcollaboration the code looks like this:
JSubCollabMapInfo mapForSubCollab = jCollabController.createSubCollabMapInfo(sCollabName, this);

Once the subcollaboration is loaded the JCollabController class apparently keeps a cached copy of the JSubCollabMapInfo class created in the above statement. So even though I remove all references to this class instance, the next time I call createSubCollabMapInfo I get the same instance loaded from the cache.

Does anyone know how I can force the JCollabController to reload a collaboration rule?
 
Cliffbob,

We think that you are in fact rebuilding the JSubCollabMapInfo instance, but that you may be doing it with the old 'version' of the collaboration rule. Can you verify that when you promote your collaboration rule that you want to load is that it is updating in the client directory of the participating host?

We think it may not be updating, and that you are still using the same class file from the client directory...

-DevIntProd
 
DevIntProd,

Your assessment was absolutely correct on one hand. The collaboration rule files specified in the rule's .ctl file get loaded from the registry to the client directory when the collaboration rule first loads. And as you suggested these files were not getting loaded in to the client directory when I promoted the new version of the collaboration rule.

So based on your input I tried manually copying the updated collaboration rule files from the registry to the client directory after I had promoted the new version of the collaboration rule, and prior to sending the reload command. Unfortunately the outcome was the same, the JCollabController apparently returned a cached instance of the JSubCollabMapInfo object which had been loaded from the previous version of the collab rule.

One piece of evidence that seems to suggest that the collab rule is not being reloaded is that the first time the main collab rule calls createSubCollabMapInfo() for a particular collab rule it takes approximately 10 seconds for the JSubCollabMapInfo instance to be returned. Subsequent calls to this method for a collab rule which had been loaded previously are virtually instantaneous.

Regardless of the outcome however your initial assessment was dead on. Thanks for your input.
 
Cliffbob,

There is a command you could have run in your main collaboration rule to retrieve the file from the registry every time before creating the new instance to work from. The control broker would go to the registry for the file, do a checksum campare, and if the file from the registry is different it would reload it into the client directory.

I don't know if you want to incur any performance cost that might result, but I think the command is:

retrieveRegistryFile(java.lang.String aFileName, java.lang.String aRegistryFilePath)

Retrieves a file from the e*Gate Registry to the client directory.

as taken from the javadocs (JCollabController).

Hope this helps, and glad the first post was correct.

-DevIntProd
 
Thanks DevIntProd, this unfortunately does not work either. This bit of functionality although it has been useful to us in our Monk eWays, we are willing to live without. Thanks for your posts, they have been very helpful.

-Ben
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top