| [udig-devel] 3 issues to be discussed/fixed/considered/.. |
Hi!
There are some issues that may cause different problems for UDIG platform. I
would like to briefly describe them.
1) SelectLayerCommand takes ~12000 ms in average on my laptop to be executed
if has been sent synchronously ( code is in MapEditor class). When the old
approach (asynchronous) is used, it takes 0-50 ms. Asynchronous sending of
this command is performed from UI thread, but the command through
EditManager's listeners calls ToolManager.setEnabled(..) stuff that calls in
its own order lots of routines in UI thread asynchronously. The performance
is horrible.
Asynchronous sending of the command is not fully safe, but from performance
point of view is not appropriate. It is still an open issue how to do
things in right way here.
2) Imagine there is a filter based on BBOX in the layer from shapefile. When
I call FeatureStore.modifyFeatures(..., Filter) where I put new values for
the set of features filtered by Filter it causes rendering problems later
on. The reason: ShapefileDataStore (actually TransactionStateDiff) sends a
notification for every changed feature and this notification comes to the
Layer class through FeatureListener and causes re-rendering of the layer.
Shouldn't it be a batch notification from GeoTools stuff? Or should events
be collected at the Layer's class level?
The first way constraints low level events making them batched that is not
appropriated for all cases where GeoTools is used. The second approach needs
a special event from low level GeoTools stuff that all modifications are
done and the Layer is able to send batched event to notify listeners
including re-rendering of the layer.
See boxselection_after.jpg where described effect of not batched
re-rendering is displayed as a result of current behavior.
3) This issue relates to concurrent
List<IResolve> CatalogImpl.find(URL ) call.
This method is called from Layer.getGeoResources() when IGeoResource is not
yet created.
CatalogImpl.find(URL ) finds firstly in CONNECTED services, then in
NOTCONNECTED..
Imagine we have OracleServiceImpl and we have only CONNECTED or NOTCONNECTED
states. There is a map with 3 layers from Oracle database, so 3
IGeoResources are requested to be found in CatalogImpl simultaneously from
different threads during opening MapEditor with this map (initial call comes
from Layer.getGeoResources()).
Map:
Layer1 (IGeoResource1)
Layer2 (IGeoResource2)
Layer3 (IGeoResource3)
First attempt to get members of the service is a blocking call, especially
in case of database when DataStore is created. The concurrent call of
CatalogImpl.find(URL ) causes that sometimes IGeoResource is not found and
the Layer is marked as a broken. I thought because of tricky
CatalogImpl.find(URL ) algorithm, but seems it does not.
CatalogImpl.find(URL ) uses getChildById(..) method that iterates through
members. My suspicion falls onto OracleServiceImpl.members(..) method:
public List<OracleGeoResource> members( IProgressMonitor monitor )
throws IOException {
if(members == null){
rLock.lock();
try{
if(members == null){
getDS(monitor); // load ds
members = new LinkedList<OracleGeoResource>();
String[] typenames = ds.getTypeNames();
if(typenames!=null)
for(int i=0;i<typenames.length;i++){
members.add(new
OracleGeoResource(this,typenames[i]));
}
}
}finally{
rLock.unlock();
}
}
return members;
}
members list is created, but filled after ds.getTypeNames() that is a
time-consuming call. During this time OracleServiceImpl.members() from other
threads returns empty but already created List instance and the caller is
unable to find IGeoResource.
May be fix for members() method is a right solution of underlying problem?
Vitali.
Attachment:
boxselection_after.JPG
Description: JPEG image
Attachment:
boxselection_before.JPG
Description: JPEG image
