Author |
Message
|
fitzcaraldo |
Posted: Tue May 09, 2006 3:00 am Post subject: Cache Node IA91 questions |
|
|
Voyager
Joined: 05 May 2003 Posts: 98
|
I would like to use the cache node functionality without using the cache nodes themselves - ie just make the Java calls.
There is a statement in the doco Known Limitations to the effect that cleaning up of memory only occurs when the cache node is entered. I assume from this that if the Java methods are called rather than embedding the nodes in the flow then cleanup of memory will not occur.
In light of this I have some questions:
Does the expiry (rather than the clean up) of data in the cache still occur if using the Java calls?
If an expired key is subsequently readded to the cache, does it get reallocated in the same place or is new memory allocated?
Are there any plans to provide a callable cleanup method?
Thanks |
|
Back to top |
|
 |
wschutz |
Posted: Tue May 09, 2006 5:08 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
If you call the java program directly (or via ESQL calls), only the keys you specify are checked to see if they should be physically removed (assuming the expiry has expired). The only way to cleanup the entire cache (ie, release expired elements) is to use the plug-in nodes.
I'm not aware of any plans, but you should ask Tony Hays directly via e-mail. _________________ -wayne |
|
Back to top |
|
 |
fitzcaraldo |
Posted: Tue May 09, 2006 10:08 pm Post subject: |
|
|
Voyager
Joined: 05 May 2003 Posts: 98
|
Thanks for that.
Could you please PM me Tony's email address?
The putIntoNamedCache() and getFromNamedCache() ESQL wrappers also allows me to specify that I want to use Broker Level caching.
If I deploy a RealTimeOptimised flow to a single execution group without changing the default port can I still get away without using actual Cache Nodes in the flows?
I'm asking these questions because we have many flows already deployed that use a simple caching mechanism called via a procedure. I am investigating if I can change the procedure to call the CacheNode java class without changing the flows themselves.
Thanks |
|
Back to top |
|
 |
tfhays |
Posted: Wed May 10, 2006 8:59 am Post subject: Cache node IA91 answers |
|
|
Newbie
Joined: 18 Jan 2006 Posts: 8
|
Hi, this is Tony Hays, the current maintainer of IA91.
First, the RealTime flow has nothing to do with caching itself; it exists solely to do the communications between the cache code in different EGs and/or brokers. So if you're not using cross-EG/Broker sharing, you don't need this flow.
You don't need to use the nodes to use the caching via ESQL functions, but, as you pointed out, there is a limitation where the clean-up functionality is not implemented *except* in the nodes. Wayne is right that as each item is accessed (whether from a node or ESQL), it will be checked to see if it expired and if so, it is removed, but there is no mass clean-up available to ESQL. So an item never again referenced will never clean-up if only ESQL is used.
Now, you do have two options that I can think of right now to do this. First, you can put a "dummy" get in your existing flows, perhaps *after* everything else. (This can get a dummy key as well.) This would invoke the clean-up code as desired. Or, you can also use a cleanup flow on some kind of timed basis to invoke it as well. This just needs a dummy Get/Put/Replay as well. This approach doesn't require any add'l changes to your existing flows then, but would require a new flow and some way to run it periodically.
I can try a few options for making this clean-up available without using nodes and this is probably not a bad idea. First, I could just use some defaults and do this for every ESQL access in the same manner that the nodes do. I could make a function specifically for this purpose that someone can explicitly call to do the cleanup. I could also convert this to a background task that is removed from both ESQL and nodes. I see pros and cons to all 3 approaches, so I'd be interested to know how you had intended to trigger this for some input.
The cache is really just a Java Hashtable, so however the JVM manages that object is how the memory is handled. I do not currently try to downsize a cache, so I suspect as the cache grows, some part of the memory is never released. I do see that this is a limitation of the implementation and have it on my list to try to improve in the future.
T. |
|
Back to top |
|
 |
wschutz |
Posted: Wed May 10, 2006 9:03 am Post subject: Re: Cache node IA91 answers |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
tfhays wrote: |
This approach doesn't require any add'l changes to your existing flows then, but would require a new flow and some way to run it periodically. |
Of course, in Broker V6, that would be a TimeoutNotification node set on automatic. _________________ -wayne |
|
Back to top |
|
 |
fitzcaraldo |
Posted: Wed May 10, 2006 3:50 pm Post subject: |
|
|
Voyager
Joined: 05 May 2003 Posts: 98
|
Thanks very much for the response guys.
A bit of background. We have many flows that have a requirement for database driven field mapping. This can be very quite significant with possibly many hundreds of mappings per message! We have implemented a simple caching technique using the Environment tree which itself has had a big impact because many of the values are repeated within a message. So for any given message, once we have hit the database for a particular key value, we store it in the cache.
I now want to extend this caching ability between message instances and if possible between execution groups. As I mentioned these caching calls are in simple procedures like putToCache and getFromCache and I would like to modify these to use the IA91 Java classes. It is not really a possibility to modify the flow and add the nodes at this stage (we have only recently migrated to V5). (Without knowing the detail, I understand that in V6 that there is another technique to share data between instances that also does not involve nodes)
Regarding memory clean up, I was thinking about maintaining an iteration count (in the cache) and on every nth iteration run a cleanup routine to release expired memory. We have relatively static data and only about 3000 values so this may not be such an issue. (But then again if it works well I can see lots of other possibilities to use it.) The other thing to consider is that the brokers are currently bounced every night but I would rather not rely on that for cache memory management.
I would also like to use the cache between execution groups. My understanding of this is that each EG would require a RealTimeOptimised flow using a different port (is that correct?). If this is the case, the ability to pass this port number as a parameter to GetFromNamedCache and PutToNamedCache (and so not need a CacheConfig flow) would be nice!
(Could this be achieved with a simple flow that contained just a RealTimeOptimised and CacheConfig flow per EG? Does a message have to flow through the CacheConfig node for it to set the port?)
Brian |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed May 10, 2006 4:23 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
You only need one single flow on one single execution group on one single broker that has the RealTimeOptimized flow node.
This does not have to be in the same flow as anything else.
You then configure all of the rest of the *Cache* nodes to point to the server and port that that RTO flow node is listening on.
Tony's suggestion was that you code all your procedures exactly the way you want.
Then, somewhere, on some execution group, you deploy one flow that uses a Cache node and have it manage the cleanup for you. Again, this is a unique flow that does nothing else. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
fitzcaraldo |
Posted: Wed May 10, 2006 5:55 pm Post subject: |
|
|
Voyager
Joined: 05 May 2003 Posts: 98
|
So if I have 10 execution groups running on a single broker, in just ONE of them I need a single RTF set to listen on the default port 1506.
Then in all the other flows (which do not use any cache nodes - and so I cannot change the default port) in all the other EGs, I can make ESQL calls to getFromNamedCache() and putToNamedCache() with the BrokerLevel parameter set to 'TRUE' and it will work? |
|
Back to top |
|
 |
fitzcaraldo |
Posted: Wed May 10, 2006 9:02 pm Post subject: |
|
|
Voyager
Joined: 05 May 2003 Posts: 98
|
Thinking about using the cache across EGs further...
Can someone tell me if this is implemented as a synchronisation function (ie each EG maintains it's own copy of everything in the cache) or as a single central repository held across all EGs?
If it is the former then it may be of limited value to us anyway. |
|
Back to top |
|
 |
|