| Author |
Message
|
| jharringa |
 Posted: Thu Feb 28, 2008 3:03 pm Post subject: storing MbElement objects across many flow transactions |
 |
|
Acolyte
Joined: 24 Aug 2007
Posts: 70
|
I'm fully open to any other strategies for doing the following but here goes...
We'd like to be able to read in an xml property file and keep the data until the file has changed (I have a thread that monitors the file's modified date). My original thought was to have the broker parse the xml file and then I'd store the tree in a Hashtable so that the flow can easily consume the data without taking a parsing penalty each time the flow executes.
I've got almost everything working except for the fact that it only works the first time. Then after the first time the MbElements in the Hashtable lose everything under {Root}. I've also tried this with MbMessages.
My suspicion is that all Mb{obj} are cleared out and that is why I'm seeing this. I guess one alternative (I think) would be to store the properties in Hashmaps under the Hashtable and then recreate the tree every time but that seems a little inefficient.
Any suggestions? Maybe I'm just doing a bunch of no-nos. I wouldn't think that this would be too big of a deal since log4j seems to be prevalant in Broker installs from what I hear and the FileWatchdog is doing the same thing as my FileMonitor.
BTW, the database option has been taken out of my palette as the project doesn't have a lot of money to spend on already consumed Data Analysts (don't ask...  ). |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Feb 29, 2008 5:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
A) Store your java code that builds your HashTable in a jar file in shared-classes, rather than in the flow bar file.
B) Do you really need MbElements? Wouldn't a standard Java DOM tree be just as good?
C) Double-check the parts of your JCN that you *didn't* create, but be wary of creating long-running memory leaks.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jharringa |
| Posted: Tue Mar 04, 2008 1:41 pm Post subject: |
|
|
Acolyte
Joined: 24 Aug 2007
Posts: 70
|
For A, I'm assuming that it must be bad practice to have this type of code in a flow bar file. Is that correct?
Is that why I am seeing that my Java code does not get updated upon a new deployment (possibly because the class is still loaded and in an active thread)?
B) Yeah, I was probably tying myself to try and use the broker too much. I've eliminated that. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 04, 2008 2:04 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No, it's not bad practice to have the jar in your bar.
Putting it in shared-classes just changes what classloader loads it, so that shared data stays shared, rather than getting erased when you redeploy.
It may be bad practice to try and retain MbElements between invocations of the flow that created them.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JLRowe |
| Posted: Wed Mar 05, 2008 8:05 am Post subject: Re: storing MbElement objects across many flow transactions |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
| jharringa wrote: |
I'm fully open to any other strategies for doing the following but here goes...
We'd like to be able to read in an xml property file and keep the data until the file has changed (I have a thread that monitors the file's modified date). My original thought was to have the broker parse the xml file and then I'd store the tree in a Hashtable so that the flow can easily consume the data without taking a parsing penalty each time the flow executes.
I've got almost everything working except for the fact that it only works the first time. Then after the first time the MbElements in the Hashtable lose everything under {Root}. I've also tried this with MbMessages.
My suspicion is that all Mb{obj} are cleared out and that is why I'm seeing this. I guess one alternative (I think) would be to store the properties in Hashmaps under the Hashtable and then recreate the tree every time but that seems a little inefficient.
Any suggestions? Maybe I'm just doing a bunch of no-nos. I wouldn't think that this would be too big of a deal since log4j seems to be prevalant in Broker installs from what I hear and the FileWatchdog is doing the same thing as my FileMonitor.
BTW, the database option has been taken out of my palette as the project doesn't have a lot of money to spend on already consumed Data Analysts (don't ask... ). |
MbElement and MbMessage have native methods, which means the content is proabably stored in the broker heap (not the JVM heap), this would explain why the contents are lost as the broker frees them up.
Try to use a java.util.Collection class with Strings, or use a DOM tree or whatever you feel comfortable with. |
|
| Back to top |
|
|
| jharringa |
| Posted: Wed Mar 05, 2008 8:14 am Post subject: |
|
|
Acolyte
Joined: 24 Aug 2007
Posts: 70
|
| Makes sense. I'm now using java Document and custom written classes to store the information. This seems to be working well. Thanks for the info and assistance. |
|
| Back to top |
|
|
|
|
