XML::Parser, keeping file open

ruby-talk
1

Using:
Ruby 1.9.2p136
libxml-ruby (1.1.4)
on RHEL 5.7

I have an application that seems to not be cleaning up xml files as I
read them. I can force it to clean up by manually running GC.start. But
I'd like to understand how to really close this, like you can do

xyz = File.open
...
xyz.close

Using a block, or the example above, I know that file is closed... But
for xml files...

Here is a nice simple example that reproduces it for me. When I run the
below example, and execute lsof on the running process, I see there are
four instances of the xml file open. If I uncomment the "GC.start" line.
It leaves all but ONE instance open. Now, this is a simple example,
eventually the GC will clean things up. But I'd like to clean it up
myself, and not rely on the garbage collector to do it at some point.
I'd also rather not just force the garbage collector to run like I show
in my example.

Thanks

···

------------------------------------------------------
require 'xml/libxml'

def readIt()
  parser = XML::Parser.file("someFile.xml")
  parser = nil
end

while true
  readIt()
  readIt()
  readIt()
  readIt()

# GC.start
  puts "Sleeping"
  sleep 100
end
------------------------------------------------------------

--
Posted via http://www.ruby-forum.com/.

2

Close it by switching to nokogiri. libxml-ruby has had a history of memory leaks.

···

On Jun 5, 2012, at 14:49 , Grant Schoep wrote:

Using:
Ruby 1.9.2p136
libxml-ruby (1.1.4)
on RHEL 5.7

I have an application that seems to not be cleaning up xml files as I
read them. I can force it to clean up by manually running GC.start. But
I'd like to understand how to really close this, like you can do

3

I have an application that seems to not be cleaning up xml files as I
read them. I can force it to clean up by manually running GC.start. But
I'd like to understand how to really close this, like you can do

Close it by switching to nokogiri. libxml-ruby has had a history of
memory leaks.

  Thanks, I was looking at this. Unfortunately I probably can't get
nokogiri approved for use quickly(business related) . I'm going to
continue to dig a bit to see if I can at least find a solution for the
current libxml-ruby problem.

  If anyone has ideas fir libxml-ruby let me know. The GC will clean
them up. I may just put a GC.start in my process loop, as I generally
know when I am going to get a "delay" in incoming data.

  To keep "nice archives" of solutions, if I end up giving up. I will
also post that. Archives of old messages are great, I just hate it when
I see a thread "Hey thats my problem!" and there is never a follow up
like "I fixed it by doing this" or "I gave up"

···

--
Posted via http://www.ruby-forum.com/\.

4

When this happens, it always reminds me of:

Jesus.

···

On Wed, Jun 6, 2012 at 10:04 PM, Grant Schoep <lists@ruby-forum.com> wrote:

To keep "nice archives" of solutions, if I end up giving up. I will
also post that. Archives of old messages are great, I just hate it when
I see a thread "Hey thats my problem!" and there is never a follow up
like "I fixed it by doing this" or "I gave up"

5

They're both based on libxml. One works. One has a long well-documented history of not working. If the business wants to fail, you might want to update your resume.

···

On Jun 6, 2012, at 13:04 , Grant Schoep wrote:

Thanks, I was looking at this. Unfortunately I probably can't get
nokogiri approved for use quickly(business related) . I'm going to
continue to dig a bit to see if I can at least find a solution for the
current libxml-ruby problem.

6

Ryan Davis wrote in post #1063432:

Thanks, I was looking at this. Unfortunately I probably can't get
nokogiri approved for use quickly(business related) . I'm going to
continue to dig a bit to see if I can at least find a solution for the
current libxml-ruby problem.

They're both based on libxml. One works. One has a long well-documented
history of not working. If the business wants to fail, you might want to
update your resume.

Thanks, I already got it ok'ed and so on. Sometimes things are fast,
since I'm the maintainer of our ruby release, I can push these things
through pretty quickly usually.

So for others, I gave up on trying to get the libxml-ruby working as I
wanted it. Its not too bad, as it does cleanup the stuff eventually.

The basis of the problem was that there was no way that I ofund in
libxml-ruby to ensure the closing of the xml file. The only way to get
it to be cleaned up was rely on the GC running, or force it to run (i.e.
GC.start)

···

On Jun 6, 2012, at 13:04 , Grant Schoep wrote:

--
Posted via http://www.ruby-forum.com/\.