Re: HELP HELP HELP - Invalid heap space using HTTPAPI

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Hi Julio,

I don't know how your code works, and that makes it hard to give any 
sort of suggestion.

Are you using http_url_post_xml()?  (This is purely a stab in the 
dark...  but it's the routine I often use for web services examples, so 
it might be what you're using.)

If so, consider replacing it with http_url_post().   http_url_posT() 
will save your XML file to a stream file in the IFS.  It will not parse 
the XML for you, but you can subsequently call http_parse_xml_stmf() to 
run the XML parser.  (And no change will be needed to your XML parsing 
logic.)

Here's why I suggest this:

The error seems to be happening in Expat.  (At least, on the surface... 
though, as Thomas points out, if memory corruption is happening, it 
might be happening elsewhere.)

So if you can save the XML file to disk, and call http_parse_xml_stmf(), 
then you'll have the XML on-hand.  If the problem occurs, you should be 
able to reproduce it by parsing the same XML file a second time. 
(Without repeating the HTTP communications.)

...and if that's true, then it's much easier to reproduce the problem! 
You can load the XML file onto your test system, and you can experiment 
to see if you can narrow the problem down more.

If possible, at that point, you can write a simple program that does 
little else besides take the XML and reproduce the problem.  And if that 
is possible to do -- then you can send it to me, and I can (potentially) 
solve the problem.

 From your job log, it doesn't look like you're running out of memory. 
Rather, it looks like the value of a pointer is getting corrupted, and 
when Expat tries to free the memory it's using, it gets an error that 
the pointer isn't valid.  But exactly where/how that's happening is 
impossible to see at this point...  which is why we need to try to make 
it reproducible.


On 2/4/2011 3:15 PM, Julio Cabrera wrote:
>
> Scott:
>
> A year ago the company I am working with decided to rewrite a big part
> of our system in java and move all the members files to Oracle.
> The other part of the system stays in the AS400 but getting the
> membership information from the Sun Micro system servers.
> Since I am a sincere admirer of your work I did propose to use HTTP API
> to consume the java Web Servers and get the information we need in the
> AS400.
> Because it is an open source, the IT director was a little concern about
> the support that we can get. At that moment I did contact the HTTPAPI
> group and get a response from you that we really can get a good support
> from the people in the group, and I believe that very good professionals
> are answering the questions we could ask.
> I did create some modules that use a very similar logic as your test
> programs.
> After 5 months working without any problem, very fast too. We are
> getting this error when we process a large amount of records.
> Because all the pressure of this situation is in my shoulder I did get a
> little anxious to resolve the problem.
> The error is very difficult to reproduce because happens randomly, In
> the other hand the Web Services are internal java programs so, it is
> practically impossible to test outside Interval International.
>   Because we were in trial I have the Debug in *ON all the time, but when
> I was following the Charles suggestion to send him the IFS file it was
> already override.
> I am not an expert in java, or EXPAT, I was looking information about
> the last I get the idea it was a C++ or java product.
> Also, I did not know if the error was a known issue or not in the
> HTTPAPI community.
> So I cannot tell you how to reproduce it in your own test environments
> where you can use our debugging tools.
> This is something I have to do and I was trying to get some advice that
> you can give me so I can do it correctly.
> As you said troubleshooting is necessary.
> I always respect you and your work, and I hope that maybe you can help
> me in this matter.
>
> Note: If this error happens again I will be prepare to get the HTTPAPI
> debug log.
>
> Regards,
>
>
> JULIO C. CABRERA
> Sr. Programmer Analyst, Information Technology
> Interval International
> 6262 Sunset Drive * Miami, Florida 33143
> 305.666.1861, ext. 7287 * direct 305.925.7287
> cell 305.928.7925* fax 305.668.3409
> Julio.Cabrera@xxxxxxxxxxxxxxxx
>
> IntervalWorld.com * ResortDeveloper.com
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------