id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
12396	[Patch] JMapViewer task queue is single-threaded and can be dominated by stale tasks	The111	team	"Older versions of JMapViewer used a custom implementation of a task queue. The current version uses a standard ExecutorService, which is in general a good idea. However, two major benefits of the old custom queue have been lost: multithreading, and cancellation of stale tasks. Without these two features, client performance is decreased, and server load is increased.

A simple experiment: fire up the Demo class from current HEAD code. Then do the following as quickly as possible:
1) zoom all the way out
2) zoom all the way in on the upper left corner
3) zoom all the way out
4) repeat steps 2 & 3 for all other corners
5) finally zoom all the way in on the center

I performed this experiment with instrumentation that counted every time a task finished and a tile was loaded. The actual input sequence described above takes only 10 seconds. Afterwards however I waited for over 10 minutes. In that time 2500+ tiles loaded, but I still could not see the portion of the map I was looking at, because all 2500 tiles that loaded were ones I was no longer interested in. It is very easy to clear the queue, in fact there is a method in place to do that and it is intentionally doing nothing now, which I seriously question. Once you fix this, you save 10 minutes of the user's time, and 2500 requests to the server (in my example at least, which is admittedly contrived, but the performance hit is real in every case even if less significant in normal use).

Also, the old custom task queue was multithreaded, however the new one is single-threaded which seems to me a very strange choice. I know this codebase has seen a lot of evolution since my last time here years ago (I've been busy since then with my [https://www.google.com/maps/d/ real job]), so perhaps there is some reason for this choice I'm unaware of... rate-limiting requests to server maybe?

Attached is a patch I would suggest we apply to fix both issues. I'm happy to do it myself, but I wanted to make sure the current active maintainers agree with my assessment, especially since I am, as ever, unfamiliar with JOSM which I know is the biggest use case for JMapViewer.

Thanks!"	defect	closed	normal	16.02	JMapViewer		fixed		wiktorn