#314 MOBAC 2.4.0 feedback [code]

[nono303]

Hi @r_x,
Starting this new ticket to not interfere in "MOBAC 2.4.0 beta 6" forum discussion as I'll only speak about code implementation and not usage ;)

So, I've forked 2.4.0 with my tunning and have some test to build big maps: Works like a charm 🤩 (I'm just struggling with the SourceForge Git; it's not very user-friendly, slow or even buggy...)
✅Apache http client seems well implemented without network issue (Windows, up to 24 concurrent threads)
✅Doesn't see regression or other issues.
✅Quickly checked residual memory after creating 1M+ tiles (~7GB mbtiles) maps: didn't find evident leaked objects (mainly checked around HttpClient & BerkleyDB)

My 2 cents

1. Still have some gradle deprecated Implicit lookup of properties in parent projects.
   • see https://sourceforge.net/u/nono303/mobac24/ci/841e527c266e96ac7bce01be7bb27d57f404c71d/tree/mobac/build.gradle?diff=c4477cccab08e1d5bf584fba97715a409719e15b

2. It might be interesting to implement 30X follow redirect on http client because actually if server response is 30X, a trace is displayed with url to follow but tile is not downloaded :(

   • Concrete example is with kompass provider which send 200 for "touristic" tile for covered area and a 301 for out of the coverage area with "osm" tile url

   I had a quick look onto code but I'm not enough fluent with this "recent" implementation to PR it properly...

++NoNo

[r_x]

Not to follow redirects was implemented intentionally. Usually redirects happen when the server changes their path. So usually you will get a redirect for every map tile or none.

If you get a redirect for every map tile you should adapt the map source and use the new url. A redirect means the server has to server twice the number of requests from MOBAC. As MOBAC performs thousand of requests this can increase the server load a lot and thus should be avoided.

Your case is a bit special but from my perspective you have two maps that have to be added individually in MOBAC.

[nono303]

Agree with your point of view for the common use-case.
If you could ever give me the patch or tell me where to put the "setRedirect(true)" in the code, it would be nice for me to apply it in my fork ;)

[r_x]

Search for disableRedirectHandling.

[nono303]

...Effectivement ^^
Thx @r_x !

[r_x]

Regarding the Implicit lookup of properties in parent projects: How the git attributes are accessed wasn't consistent among the different build.gradle files. So I reworked those sections.