I would like to know what – theoretically – could happen on the long run if I limit jbidwatcher to let’s say 128MB and add 300 auctions. Any hints ? (running jbidwatcher on debian lenny)

Funny thing is, I first started jbidwatcher with the -Xmx512m option. It quickly went to consume 1GB of memory. I then started jbidwatcher with the -Xmx256m option three days ago. It now consumes more than 500MB of memory. Can anybody explain this behaviour to me ? It seems like it uses double of what I tell it to use.

Greetings,
I’m not sure; what version of Java are you running on Linux? I strongly discourage the use of non-Sun Java versions, because none of them are really ready for prime time. (I might trust an IBM Java version, but I’m not even sure they still make their own.)

That’s a Java option, not a JBidwatcher option, which is why I ask. JBidwatcher doesn’t limit its own memory usage, the command line option tells Java to limit it.

— Morgan Schweers, CyberFOX!

I am using sun-java6. After running jbidwatcher for some days and adding like hundreds of auctions it finally froze even though consuming 1GB of memory. What exactly is using so much memory ? If it is the db, I would be able to use MySQL… well, would want to, because there is a bug in the MySQL interface (tested on JBidwatcher-2.1pre5);
If I want to use any other database name than “jbidwatcher” it creates the tables in the customly selected database, additionally creates the “jbidwatcher” database and tables (yes, a sepparate db) and then doesn’t work any longer if I delete the “jbidwatcher” db. (got it ?)
At this moment I am using an external script to restart and recreate the derby db every 24 hours, to avoid lockups… this is no perfect solution in my opinion though.

Greetings,
I don’t believe it’s the database that’s taking the memory. My goal, eventually, is to offload everything TO the database, and keep only a tiny amount of the current auctions ‘in memory’. It doesn’t really work that way right now, unfortunately. Currently it keeps a great deal of information in memory, and occasionally I make a mistake and it keeps hold of some data (like parsed auctions, or searches) longer than it should, thus foiling garbage collection.

As for MySQL, out of curiosity, is there a reason you can’t use the jbidwatcher database name? I don’t dispute that it’s a bug, and I’ll definitely dig into it, but in the mean time why not use the ‘jbidwatcher’ database under MySQL as it stands?

— Morgan Schweers, CyberFOX!

I will have to read more about java then. All I found up until now is that -Xmx$$$m limits the memory java WILL be able to use when it’s needed since -Xms$$$m (s!) determines how much memory it will start uppon. It absolutely makes no sense at all, though, that it uses hundreds of megs for some auction information (even if you load a hundred auctions into jbidwatcher), using the db (which in my oppinion also is present in the memory, at least parts of it) even if one would consider to cache all images into the memory. And by the way: It consumes the memory mentioned above almost instantly after startup (without adding auctions).

I am using a MySQL server with many databases. In order to have a better overview I am using prefixes to my databases (ie. web_project1, web_project2 or app_application1… and so forth). This is why I don’t want to use a database named “jbidwatcher” but rather “app_jbidwatcher” or “app_testing”.