Unable to GlobalAlloc memory for LAN message buffer.

Hi There,

I'm not sure if this is the right place to be posting this topic, but I'm not sure where else to put it. I think it's more of a Microsoft issue than a Java one, but maybe someone can point me in the right direction of where to look.

I have written a front-end Java application that acts as an interface for a Teradata back-end. It has a JTree that displays data warehouses, tables and columns. Once you click on a node, some queries are executed to fetch the data for that node and cache it in a Java object for easy access. That all works well.

Now I have written a class that queries the database, creates the objects and caches all of them at once so that the user does not have to wait for the database to be queried every time an un-cached node is clicked. This is where the problem comes in...

The design of the Java classes is that each table or column are stored as custom-made Entity classes. Depending on the type of Entity it is (i.e. a table or column), it can contain LinkedLists of type Mapping, Index, or IndexColumn. Of course, to create each object requires a new query to be executed.

There are in excess of 19,000 tables and columns that are created. For each of these, anything between 2 to 5 queries may be executed. I realise this may well be a design issue, but for now I want to try complete as much as possible of what I already have, with code revisions and possible re-designs being done afterwards.

When I run the class to cache all of the relevant tables and columns at once, it gets to about 18,000 Entity objects (i.e. tables or columns containing their own LinkedLists of the above-mentioned types) and then throws the following error:

java.sql.SQLException: [NCR][ODBC Teradata Driver] Unable to GlobalAlloc memory for LAN message buffer.

It then continues creating Entity objects representing tables, but does not create Entity objects representing columns anymore. It then creates the very last Entity object representing a table, after which it throws the following error:

Exception java.lang.OutOfMemoryError: requested 655360 bytes for GrET* in C:/BUILD_AREA/jdk1.5.0_06/hotspot\src\share\vm\utilities\growableArray.cpp. Out of swap space?

I have been running the class to create the objects with -Xmx256m as the virtual memory allocation in the command line. I have also tried changing this number, but I still seem to get the same error.

I have added memory handling to detect when the virtual memory is starting to run out of space. When this is detected, the objects that have been created thus far are written to file. I have tested this by only caching 20 Entity objects and changing the virtual memory to a very small amount. Under these circumstances, my memory handling works. However, it does not work when I run the full method because of the initial GlobalAlloc error that is thrown.

I think the GlobalAlloc() error is a Microsoft problem, but I have tried that avenue and haven't really received much support.

Can anyone help?

[3104 byte] By [RoxyLJa] at [2007-10-3 9:11:04]
# 1
Help? Anyone?
RoxyLJa at 2007-7-15 4:23:10 > top of Java-index,Security,Other Security APIs, Tools, and Issues...
# 2
You have to forget about this caching design immediately as you have obviously run into a hard limit. Let your database do the caching, it's good at it.And btw this has nothing to do with 'Other Security APIs, Tools, and Issues'.
ejpa at 2007-7-15 4:23:10 > top of Java-index,Security,Other Security APIs, Tools, and Issues...
# 3

Yes, in theory, a novel idea.

The problem is that when I was given the specs for this application, everyone was happy with querying the database and using that as the cache. Now that I have finished it, they want a faster cache. I pretty much have no option but to find a way to make this thing run faster.

The GlobalAlloc() method is a Microsoft security method - or so I am lead to believe. I am quite aware that this might be the wrong forum. Hence my starting sentence.

RoxyLJa at 2007-7-15 4:23:10 > top of Java-index,Security,Other Security APIs, Tools, and Issues...
# 4

GlobalAlloc() is not a security method, it's just a memory allocation method. If the database can't allocate enough memory clearly you are using too much. A cache should be small, not large, reflecting the most active parts of the database. A cache that holds the entire database isn't a cache, it's a database.

ejpa at 2007-7-15 4:23:10 > top of Java-index,Security,Other Security APIs, Tools, and Issues...
# 5
Yes, I realise that. As I say, the problem is that all the users querying the database at once takes too long and puts too much of a load on the server. They want it faster...
RoxyLJa at 2007-7-15 4:23:10 > top of Java-index,Security,Other Security APIs, Tools, and Issues...
# 6

Of course they want it faster, that's fine. The problem is just this:

> When I run the class to cache all of the relevant tables and columns at once,

You've discovered that the database can't handle 'all of the relevant tables and columns at once', so you just have to reduce the scope of your caching. If it's a JTree maybe don't cache the bottom level, something like that.

ejpa at 2007-7-15 4:23:10 > top of Java-index,Security,Other Security APIs, Tools, and Issues...
# 7

Yeah. I was really hoping to find a way around it, seeing as pretty much "all of the relevant tables and columns" are used regularly by various users. Implementing a client-level cache rather than a server-level cache could also work, but that would mean initially they would still have to wait for tables and columns to load into the cache before their access to nodes in general is faster...

I guess I was hoping for some miracle cure for the GlobalAlloc error message. Seeing as that's not going to happen, I'll have to do something else.

Thanks again, ejp. You always seem to be the one to answer my questions.

*Hands you a noddy badge.*

RoxyLJa at 2007-7-15 4:23:10 > top of Java-index,Security,Other Security APIs, Tools, and Issues...