ThinkGeo.com    |     Documentation    |     Premium Support

WorldMapKitData reading conflicts

#1

In our shop we have two developers building our application using MapSuite Edition.  We also have about 8 to 10 other supporting personnel who test and demo our application to our sponsors (end users).  We purchased two licenses for Desktop edition development and one license for the WorldMapKitData.  We have installed the WorldMapKitData on a computer that is accessible to eveyone within our workgroup.  We have modified the sample application delivered with the WorldMapKitData to render the map layer in our application from the 700+ shapefiles in the map kit.


It seems to take under five seconds to render all the shapefiles in the world map layer.  However, we have begun to experience times when it code encountered a much longer delay (more than a minute or so). Usually, after the delay the user gets an exception message of "The Process cannot access 'someshape.idx' processor because it is being used by another processor".   The 'someshape.idx' is one of the shapefiles in the WorldMapKitData.  It seems to be different everytime we see the message. 


Is there anyway to control the access to prevent this lockout (deadlock) or whatever it is?  Do we need to have some sort of mutex or something on the code to render the shapefiles?   Do we need to "close" shapefiles to prevent "in use" locks on the files?  I am not sure how to trap this error or determine where or who has a lock on the files.


If anyone has any suggestions it would be greatly appreciated. 


Richard


 



#2

Richard, 
  
   I can take a look at this for you.  When we open the layers they should be opened for read access and it should share rather well.  Are you using the WorldMapKitLayer that comes with the world map kit or are you loading the layers yourself? 
  
 David

#3

I am using the sample code that came with the WorldMapKitData. 


Richard



#4

Richard, 
  
   I am setting up the framework to test this and while I am doing that can you send me the exact error message and call stack information please? 
  
 David

#5

The exact message is "The process cannot access the file '\\T74....dev.com\STTI Maps\WorldMapKitData\USA\urban_dtl.shp' because it is being used by another process."   The file name in the message varies.  Sometimes it is a .shp other times it might be a .idx.  A stack trace is attached below. 



#6

Richard, 
  
   One more question…  Are you 100% sure you don’t have any other processes trying to build an index on the files or anything else?  No one is trying to access the data outside of the WorldMapKitLayer right?  I just want to be 100% before I go down the super detailed path.  Oh also how often does it fail? 
  
 David

#7

David, in the original post, he indicated that the data is on a central server, but looks like the apps are running on local boxes.  So he has two boxes trying to hit the centrally stored files at the same time.

#8

Ted, 
  
   Good catch…  It’s been so long since I working in shared network files scenario that I can’t seem to remember if this was ok.  I would imagine that if each person opened it as read-only and shareable then it should be ok.  Is this not the case over a network? 
  
 David

#9

Read-only and shareable should likely solve the problem if the map kit doesn’t generate the .idx files dynamically.

#10

David, 
  
 Am I 100% sure? No.  But I am probably 99% sure.  When we set up the folder with the maps on the computer where the map data is located, we granted read-only access to everyone except the administrator.  The administrator should not be running our application so all “users” should have read only access.  Sharable is a little more cloudy to me.  The “users” do have shared access to the drive on the computer.  I am not sure whether this implies shared access to the individual files.   
  
 No one is trying to access the shapefiles/indices outside of the WorldMapKitLayer but each user is running a separate copy of our application so there are potentially several WorldMapKitLayer accessing the maps folder during the same time period.  I would not think anyone is updating the index files as all the access should be read only but I haven’t checked the file to see if any updates have occured.  I can do this if it is helpful. 
  
 I am not sure we have a finger on how often this is occuring.  I do not get regular feedback from all the “users” and I do not have a way to monitor there usage.  I have only had a few reports that this occured over a period of several weeks but the users may not recognize this as the same problem or report it as such.  I have personnally seen it about 3 to 4 times and our primary tester has reported to me that it has occured 3-4 times.  I am guessing the frequency to be once per day on average but if one user is experiencing it, others may also experience around the same time. 
 I know these answer as not very definitive but they are the best information I have available at this time. 
  
 Richard

#11

David,  
  
 Just to confirm. I did a search on the WorldMapKitData folder on the "server" and nothing has been updated within the folder for more than one month which would be longer than the time period we have observed this issue.  
  
 Richard

#12

David, 
  
 We have some additional questions about this scenario.   
  
 Are the shapefiles in the WorldMapKitData "locked" is some way when the shapefiles are being read  to render the World Map layer(s)?  Are the shapefiles themselves  re-accessed(opened and read) every time a refresh occurs or when the map is panned or zoomed to a different geographical center?  If they files are locked, is there a way to prevent or control the lock from the API?   Is there any sort of timeout that can be set or controlled when a "lock" condition has been encountered?  Or do we have some type of deadlock where one process has the shapefile open and another happens to have the .idx or one of the other related file in use?  Lastly, if the shapefiles are reaccessed frequently (when panning or zooming) is there anyway to cache shapefiles so that the files themselves do not need to be reused everytime? 
  
 The caching question may be important to us for perfromance reasons in addtion to the issue with the "locked" files.   We are seeing some degradation in the speed that the map renders on operations such as panning and zooming.   We may start to look into limiting the shapefiles which we include when we render the map (currently we use all the shapefiles in the WorldMapKitData).  If we could cache the critical shapefiles would we see the zooming and panning functions respond more quickly? 
  
 Thanks for your assistance.   
  
 Richard

#13

Richard, 
  
   I am looking into this issue right now.  Briefly to answer some of your questions we do not lock the shapefiles while reading.  At least we are not supposed to by default which is what I am going to test.  We may or may not close and re-open them depending on the version of Map Suite you have and I have to check the code in the world map kit.  I would highly suggest you get the latest version of the product though as there was a bug in the initial 5.5 where we closed and reopened the shapefiles after drawing and that was a bug.  We since then make sure they remain opened after drawing for speed purposes and to keep the cache.  To be sure make certain you at least 5.5.0.49 or high if you are on the released branch.  If you are on the developer branch then you need 5.5.49.0 or higher. 
  
 Let me address the caching a bit later after I have some time to check out the locking issue. 
  
 David

#14

Richard, 
  
   I was able to find one place where the sharing mode was write, all the other are Open / Read / Read for the other modes which should be fine.  Get developers build number 5.5.78.0 or higher, should come out tonight around 6pm central.  Try that out and let me know if it fixes it.  If not I will have to go to step two which is re-create it which may take a bit of doing… 
  
 David

#15

I probably won’t have an opportunity to test with any new versions of MapSuite for a while.  We have a release of our product due on Tues Jan 31st.  I can’t make changes to that environment at this point unless it is an aboslute fatal crash.  This testing environment is the only place I have that exhibits the lock conditions.  We will be in another testing cycle around the middle of February so I should be able to change to the newer version then. 
  
 Richard

#16

Richard, 
  
   That sounds good.  I’m not sure if that change really fixed it and it gives me a little time to setup a real test on a network and a few clients.  Let me know how it goes when you are ready. 
  
 David

#17

David,


We are back in a testing cycle again where we are having more users trying to access the MapSuite server.  We don't seem to be having as many locking conditions as we were encountering in the prior testing cycle but we have had several again.    I am having a lot of difficulty getting information on the lock condition as I don't believe the users are reporting every occurence and I have not found a suitable monitoring tool to track the locking condition.   I have heard that in some cases our application has crashed prior to the MapSuite server having a file locking problem but I have no evidence that this is true.  If an application with the map being displayed were to crash, would this be triggering a file left in a locked state?


Have you had any luck in setting up a test situation? 


Richard



#18

Hello Richard, 
  
 Sorry we  still doesn’t have the environment to test it, we will try to set up one and test it, I will let you know the result asap. 
  
 Regards, 
  
 Gary

#19

Richard, 
  
 We failed to recreate this issue. We put the WMK data on a remote machine and create a multi threading program hitting the maps within a small area asynchronously, it doesn’t throw any issues in the 2 hours it was running. We also run them on different machines and they are working fine too. So can you try using a similar program on your side to see if that can recreate it? 
  
 Thanks, 
  
 Ben 
  


#20

Richard,  
  
 We did another test today and requesting the map on 3 machines asynchronously (with assembly 5.5.127.0),  they are all working fine for 7 hours before we close the it. I guess it doesn’t have the lock issue and please have a try to see if you can recreate.    
  
 Thanks, 
  
 Ben