Hi, on the server side even with the read-only search the MMapDataAccess is *not* fully thread safe due to the limited Java API (ByteBuffer) which is stateful. For example see getBytes where bb.position(0) can potentially influence other threads. Just try to use QueryTorture and exceptions should show up pretty early or check distance/geometry. So yes, using the sync wrapper is highly recommended or use RAMDataAccess.
We could implement memory mapping via Unsafe to make it faster and no synchronized would be necessary (as we do not use the ByteBuffer API). But there was no demand regarding this and also it is quite tricky and we leave Java supported land ;) Regards, Peter On 01.07.2015 19:49, John Zhao wrote: > Hi Peter, > > If we use RAM to extract graphhopper, then use MMapDataAccess to load > graphhopper data. > In other words, if we read only with MMapDataAccess on server side, is > it correct and thread-safe? > > *Best Regards,* > *ZhiQiang ZHAO* > > On Tue, Jun 30, 2015 at 10:53 PM, Peter <[email protected] > <mailto:[email protected]>> wrote: > > Hi, > > this is for two reasons: > first, it allows you to use the MMap for server side > second, it allows us to use multi-threaded algorithms at some > point in the future > > Regards, > Peter > > > On 01.07.2015 02:31, John Zhao wrote: >> Hi Peter, >> >> This question is for you. :) >> >> I guess MMapDataAccess is mainly designed for running Graphhopper >> on Android device, which you can't load all the data into the >> limited memory. >> >> In the comment of MMapDataAccess: >> This is a data structure which uses the operating system to >> synchronize between disc and memory. >> Use SynchDAWrapper if you intent to use this from multiple threads! >> >> why GH need a thread-safe one, somebody want to do the extract on >> Android device? >> just curious. >> >> Thanks in advance. >> >> *Best Regards,* >> *ZhiQiang ZHAO* >
_______________________________________________ GraphHopper mailing list [email protected] https://lists.openstreetmap.org/listinfo/graphhopper
