My company has assigned me to do the inital testing of XMLBlaster as a potential MOM solution for a project we recently received. The main need in this project is to handle point to point messages in a secure and reliable way, as well as handle persistance of messages and high availability. Additionally, large files (currently up to about 4MB) need to be able to be handled fairly efficiently, though most of the traffic would be much smaller (less than 20k). We alos have the restriction of needing to implement this solution under Windows (both server and client side). Clients will probably need to be written in C++. Does this sound like a reasonable fit for XMLBlaster? I've uncovered a lot of positive things through testing, but have hit what seems a big snag in handling largish (a little over 2MB) messages. I modified the Ptpsend and PtpReceive examples to take a -file parameter to send and receive arbitrary files. After moving 2MB files in point to point mode several times in a row I would generally get a "java.lang.OutOfMemoryError". I tried this using a modified version of the XMLBlasterClient.pl and Server.pl perl scripts and got similar results (though they seemed to hit the problem sooner). Is this a problem with how XMLBlaster was initiated? (from the .bat file which has: java -jar lib\xmlBlaster.jar) Or from how I modified the java files, or from a limitation of java or XMLBlaster under Windows? or...? I'm attaching the modified java files (hope this isn't too much, but it may be useful for someone else). Also, here are the command lines I used to initiate the Sender and server java classes: ======================= PtpSendInput (modified from PtpSend) java PtpSendInput -client.protocol XML-RPC -numSend 1 -delay 0010 -forceQueuing true -file <file name> -xmlrpc.hostname <XMLBlaster host> PtpReceiveInput (modified from PtpReceive) java PtpReceiveInput -client.protocol XML-RPC -xmlrpc.hostname <XMLBlaster host> -file <file name> -abortCount 1 ======================= One other problem I encountered during these same tests, were the removing of persistent PtP messages. Although I tried using the erase() method that didn't seem to do the trick... Any help, comments, questions for me etc. are very appreciated. It looks like these last group of tests are what's standing in the way of management giving the go ahead to using XMLBlaster for this project. -Kelley Phillips ---------------------------------------------------------------------------- --- Kelley Phillips, email: Kelley.Phillips at infotechfl.com Systems Analyst, Info Tech Inc.
Attachment:
PtpSendInput.java
Description: java/
Attachment:
PtpReceiveInput.java
Description: java/