Greetings, Frank,
If all you really want to do is to check that the data can be used to
create a valid SDT, then you could use the more direct approach of simply
creating one. The test code for SDTs shows how to do this; here's what it
looks like for the Activity SDT:
29 public void testActivitySDT() throws Exception {
30 String sensorType = "Activity";
31 Date timestamp = new Date();
32 String timestampString = String.valueOf(timestamp.getTime());
33 String tool = "Emacs";
34 ActivityType activityType = ActivityType.OPEN_FILE;
35 String data = "foo.txt";
36
37 // Create a key-val String Map containing the data.
38 Map keyValStringMap = new HashMap();
39 keyValStringMap.put("tool", tool);
40 keyValStringMap.put("tstamp", timestampString);
41 keyValStringMap.put("type", activityType.toString());
42 keyValStringMap.put("data", data);
43
44 Activity activity = (Activity)
SensorDataEntryFactory.getEntry(sensorType, keyValStringMap);
:
49 }
This has less overhead than invoking the whole SensorShell apparatus. This
code requires the current version of Hackystat that employs the
evolutionary SDT mechanism, of course.
I am a little surprised that you're getting the out of memory exception.
The public server, of course, manipulates hundreds of thousands of SDT
instances and does not have this problem.
If you have a chance and can determine the number of doCommand()
invocations that occur before getting the out of memory error, that would
be helpful.
And, of course, it would also be helpful to isolate where exactly in your
program the heap is being expended. Have you tried a tool such as
JProfiler? It is quite easy to use and can usually pinpoint the source of
these problems quite quickly, along with very useful information about the
kinds of objects using up the heap. Although I won't be at all surprised
if the SensorShell is the source of the problem, it might potentially be
some place else as well. If it is SensorShell, the more detailed
diagnostic information provided by a tool like JProfiler could help us fix
the problem.
Cheers,
Philip
--On Thursday, October 6, 2005 2:52 PM +0200 "Schlesinger, Frank-Michael"
<[EMAIL PROTECTED]> wrote:
Hi all,
During my work on the ElectroCodeoGram (www.electrocodeogram.org), which
is using the HackyStat sensorshell.jar as a Component I'm running into
some trouble.
My code uses the SensorShell.doCommand() method to check if event data
is a valid in respect to the known SensorDataTypes (SDT). So far this
works well for me. If the event is a valid SDT event, doCommand()
returns true and otherwise it returns false.
But if am using doCommand() over and over again the JVM crashes with a
java.lang.OutOfMemeoryError after some time.
I never connect the SensorShell to a HackyStat server, so I guess that
every event that is passed into the SensorShell via doCommand() is
creating Objects with references that are never released. So the Java
heap-size growths until the OutOfMemeoryError is thrown.
I already tried to invoke the OfflineManager.clear() command with no
effect.
Is there any way of releasing the memory occupied by the SensorShell
without having to write into the SensorShell's code?
Cheers,
Frank
