Measurement widget: measure-end event triggered multiple times

1291
5
03-07-2017 12:22 PM
YohanBienvenue
Occasional Contributor II

When using the area measuring tool, for each point you add (starting from the third point) the widget starts making areasAndLength requests to the geometry service to find the surface area of the current polygon. After receiving the surface from areasAndLength, the widget sends a "measure" event each time (except the last time where it sends you a "measure-end" event if you double-clicked instead of clicked).

The problem is that if for some reason the areasAndLength requests are pending and take a while to return, it doesn't stop you from adding points and even double-clicking to add the last point. Then when the areasAndLength requests finally return, instead of sending the "measure" events and one final "measure-end" event, the widget sends a bunch of "measure-end" events.

This is problematic because I have specific/different code in my "measure" and "measure-end" event handlers.

If all goes well it works fine, but intermittently if there's a lag with the geometry service then the wrong handler will be called multiple times, creating a bug in my application.

I can't figure out a way to work around this at the moment. I can't just ignore the extra "measure-end" events, I really need to call my regular "measure" event handler for each point, but the thing is when I receive the first "measure-end" event, I have no idea that more might follow because of this issue. Otherwise I would just redirect it to my "measure" handler instead.

I'm wondering if anyone else has this problem and how they deal with it.

Thanks

0 Kudos
5 Replies
YohanBienvenue
Occasional Contributor II

For now I implemented this, I hate it but it's the best I've got so far.

Basically if I receive a bunch of measure-end events together, I count them up but call the handlers with a 750ms delay.

Then I can check if I have more then one and act accordingly if that is the case.

I'm sure it's not full proof, but I tested it in the worst navigator for this issue (i.e. Internet Explorer) and it seems to do the job to work around this.

this.esriMeasurement.on('measure-end', lang.hitch(this, function(event){
    this.measureEndCount++;
    setTimeout(lang.hitch(this, function(){
        this.measureEndCount > 1 ? this.onMeasureEvent(event) : this.onMeasureEndEvent(event);
        this.measureEndCount--;
    }), 750);
}));‍‍‍‍‍‍‍
0 Kudos
RobertScheitlin__GISP
MVP Emeritus

Yohan,

   Have you set your app to use your own geometry service instead of the sometimes over taxed esri geometry service?

0 Kudos
YohanBienvenue
Occasional Contributor II

Yes I have

esriConfig.defaults.geometryService = new GeometryService(this.config.geometryService.url);

We actually have 9 servers (each with a geometry service) spread over 30 clients, each with 1 to 10 map services.

We've always had some minor lag issues at peak usage times (e.g. 9am, 2pm), sometimes by chance 2-3 users will make a bunch of requests at the same time. However usually it doesn't create bugs, it just takes longer to get the response.

0 Kudos
RobertScheitlin__GISP
MVP Emeritus

Yohan,

  Strange, normally when you are using your own Geometry service stuff like that does not happen. Are your ArcGIS servers configured in a roll over/ round robin type configuration?

0 Kudos
YohanBienvenue
Occasional Contributor II

No, each client is assigned a specific server. But I'm not convinced ArcGIS Server is to blame for the lags here, I didn't mean to imply it was. If I had to take a guess I'd say the problem probably lies with a bad Apache web server configuration. All requests go through Apache before being redirected to 1 of the 9 servers. I've seen lags with other requests too, sometimes simple html files, for instance. It's like sometimes connections are hanging.

However I still think it's bad practice for the measurement widget to assume the geometry service will respond before the user has time to add another point. It shouldn't rely on that.

0 Kudos