08-18-2008 08:51 PM - edited 08-18-2008 09:12 PM
I'm trying to find out why my blackberry application seems to die/block when it recieves the following error message, even though locationUpdate spawns a thread (pulled from the on device event log):
0x50 0x72 0x6F 0x63 0x65 0x73 0x73 0x20 0x6E 0x65 0x74 0x5F 0x72 0x69 0x6D 0x5F 0x62 0x62 0x5F 0x67 0x70 0x73 0x5F 0x65 0x65 0x28 0x32 0x30 0x30 0x29 0x20 0x71 0x75 0x65 0x75 0x65 0x20 0x6F 0x76 0x65 0x72 0x66 0x6C 0x6F 0x77 0x3B 0x20 0x6F 0x6C 0x64 0x65 0x73 0x74 0x20 0x65 0x76 0x65 0x6E 0x74 0x20 0x64 0x72 0x6F 0x70 0x70 0x65 0x64 - Process net_rim_bb_gps_ee(200) queue overflow; oldest event dropped
The basic flow is that interval for gps is 5 minutes, then at night time it goes to 4hrs. Anyone know what the problem is?
08-19-2008 06:16 AM
Have a quick look at the following:
Process [ApplicationName] killed due to message queue overflow
Article Number: DB-00401
Despite the fact that this looks like the problem is in the GPS processing, this would message would suggest that the LocationListener is blocking on some event, which could be GUI related (most commonly with this error it is).
However I note that you start a new Thread, so in theory, this should not be the case. So this probably isn't the answer, in which case I can only offer you the following suggestions:
a) Log an entry in the Event Log before at the start and end of your Location Listener processing. Given this happens infrequently, this will not be a big overhead, however it will tell you if you are in your code when this error occurs and will tell you how long you spend in your code.
b) I think in the locationUpdate you need to take a copy of the Location provided and return as quickly as possible. In my testing, I found that the location listener was always being provided with the same Location - the update processing basically updates this Object with the new values. So if you take a reference to this Location Object and use it elsewhere in your application (at some later time) you might find that you no longer have the correct value, because you have a reference to the current value. Most importantly, if you do an synchronization on this Object, you could inadvertently be blocking the GPS processing
c) Elsewhere in the forum, there has been a discussion comparing Location Listener and getLocation() - I can't find it now. I think the summary of that discussion is that for longer intervals you are better off just running your own thread, sleeping and doing a getLocation(). That is what I would do, for intervals of 5 minutes, let alone 4 hours. To keep the chip 'hot' I think you need to have an update interval of 10 seconds or less. I think changing to your own long running thread rather than Location Listener would also alleviate this problem. However you might have other design reasons for Location Listener.
Can you tell us what device, JDE level and OS level you see this on?
08-20-2008 02:48 PM
FYI, I think Peter, in c), is refering to this post:
More precisely to these answers:
08-20-2008 11:08 PM
Thanks for the info, very helpful.
Does RIM have an official stance on this?
Now an 8800 seems to be suffering a similar problem but from google maps?
0x50 0x72 0x6F 0x63 0x65 0x73 0x73 0x20 0x67 0x6D 0x61 0x70 0x73 0x38 0x38 0x30 0x30 0x5F 0x76 0x34 0x5F 0x32 0x5F 0x4C 0x31 0x28 0x31 0x33 0x39 0x29 0x20 0x71 0x75 0x65 0x75 0x65 0x20 0x6F 0x76 0x65 0x72 0x66 0x6C 0x6F 0x77 0x3B 0x20 0x6F 0x6C 0x64 0x65 0x73 0x74 0x20 0x65 0x76 0x65 0x6E 0x74 0x20 0x64 0x72 0x6F 0x70 0x70 0x65 0x64 - Process gmaps8800_v4_2_L1(139) queue overflow; oldest event dropped
08-21-2008 10:07 AM
Yes, please see the following link.
Support - Process [ApplicationName] killed due to message queue overflow
Article Number: DB-00401
08-22-2008 08:59 AM