gvSIG feature requests #1618
sort table column OutOfMemoryError / sin memoria al ordenar una columna
| Status: | Closed | % Done: | 0% | |
|---|---|---|---|---|
| Priority: | Normal | Spent time: | - | |
| Assignee: | - | |||
| Category: | Document table | |||
| Target version: | - | |||
| gvSIG version: | 2.0.0 | Add-on resolve version: | ||
| Keywords: | Add-on resolve build: | |||
| Has patch: | No | Proyecto: | ||
| Add-on name: | Unknown | Hito: | ||
| Add-on version: |
Description
A java.lang.OutOfMemoryError exception occurs when you try to sort a table column (shapefile with 200000 rows).
Salta una excepción por falta de memoria cuando intentas ordenar un campo de una tabla (shapefile con 200000 registros).
ERROR [AWT-EventQueue-1] (MDIFrame.java:831) - Can't perform action 'table-order-asc'.
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Unknown Source)
at java.util.ArrayList.ensureCapacity(Unknown Source)
at java.util.ArrayList.add(Unknown Source)
at org.gvsig.fmap.geom.primitive.GeneralPathX.lineTo(GeneralPathX.java:285)
at org.gvsig.fmap.geom.primitive.impl.OrientablePrimitive2D.addVertex(OrientablePrimitive2D.java:407)
at org.gvsig.fmap.dal.store.shp.utils.SHPFile.fillCurve(SHPFile.java:497)
at org.gvsig.fmap.dal.store.shp.utils.SHPFile.getGeometry(SHPFile.java:374)
at org.gvsig.fmap.dal.store.shp.SHPStoreProvider.loadFeatureProviderByIndex(SHPStoreProvider.java:370)
at org.gvsig.fmap.dal.store.shp.SHPFeatureProvider.load(SHPFeatureProvider.java:30)
at org.gvsig.fmap.dal.store.shp.SHPFeatureProvider.getCopy(SHPFeatureProvider.java:74)
at org.gvsig.fmap.dal.feature.impl.featureset.FastOrderedIterator.<init>(FastOrderedIterator.java:31)
at org.gvsig.fmap.dal.feature.impl.featureset.DefaultFeatureSet.fastIterator(DefaultFeatureSet.java:367)
at org.gvsig.fmap.dal.feature.impl.featureset.DefaultFeatureSet.doAccept(DefaultFeatureSet.java:321)
at org.gvsig.tools.visitor.impl.AbstractIndexedVisitable.accept(AbstractIndexedVisitable.java:51)
at org.gvsig.fmap.dal.feature.paging.impl.FeaturePagingHelperImpl.loadDataFromFeatureSet(FeaturePagingHelperImpl.java:398)
at org.gvsig.fmap.dal.feature.paging.impl.FeaturePagingHelperImpl.loadCurrentPageDataNoSelection(FeaturePagingHelperImpl.java:382)
at org.gvsig.fmap.dal.feature.paging.impl.FeaturePagingHelperImpl.loadCurrentPageData(FeaturePagingHelperImpl.java:311)
at org.gvsig.tools.dynobject.impl.DefaultDynObjectPagingHelper.setCalculator(DefaultDynObjectPagingHelper.java:166)
at org.gvsig.tools.dynobject.impl.DefaultDynObjectPagingHelper.setDefaultCalculator(DefaultDynObjectPagingHelper.java:171)
at org.gvsig.fmap.dal.feature.paging.impl.FeaturePagingHelperImpl.reload(FeaturePagingHelperImpl.java:273)
at org.gvsig.fmap.mapcontrol.dal.feature.swing.table.ConfigurableFeatureTableModel.orderByColumn(ConfigurableFeatureTableModel.java:328)
at org.gvsig.app.extension.TableFieldOperations.doExecute(TableFieldOperations.java:73)
at org.gvsig.app.extension.TableFieldOperations.execute(TableFieldOperations.java:54)
at org.gvsig.andami.actioninfo.impl.DefaultActionInfo.execute(DefaultActionInfo.java:215)
at org.gvsig.andami.ui.mdiFrame.MDIFrame.actionPerformed(MDIFrame.java:813)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
sort-error.png (48.6 KB)
Related issues
History
#1
Updated by Juan Lucas Domínguez about 11 years ago
Hello,
We believe this is because one of the geometries is huge.
You can try to give gvSIG more memory when it starts.
On Linux, this is done by editing the file gvSIG.sh. Change this line:
GVSIG_MAX_MEM=512M
(Not recommended more than: 1408M)
On Windows, you should edit the file: gvsig-desktop.l4j.ini
(next to the .exe file)
Perhaps you can send us the file or a part of it than contains the huge geometry?
#2
Updated by Cesar Ordiñana about 11 years ago
I think the cause is not related to a huge geometry, but because of the ordering being perform with all the shape features (200.000) loaded into memory .
One possible solution would be to load only the feature attributes which are needed to perform the ordering, not loading the geometry and the other attributes. This way much less memory would be used. But this way, when the iterator is used to retreive the features, each Feature has to be loaded again (maybe through the FeatureReference), with all the needed attributes, so it might become a bit slower. At the end only the page of Features being shown is loaded by the table document, so maybe it is not very noticeable.
#3
Updated by Cesar Ordiñana about 11 years ago
Another possible solution, much easier but partial, would to review how the table document is creating the FeatureQuery. As it is not showing the geometry column, it does not need that Feature attribute, only the ones being shown. This way the data document performance would be better.
Its a partial solution because if the user activates the geometry column... bang!
#4
Updated by Álvaro Anguix over 10 years ago
- Assignee set to Joaquín del Cerro Murciano
- Priority changed from Normal to Urgent
#5
Updated by Álvaro Anguix over 10 years ago
- Target version set to 2.1.0-2218-testing
#6
Updated by Álvaro Anguix over 10 years ago
- Tracker changed from gvSIG bugs to gvSIG feature requests
- Target version deleted (
2.1.0-2218-testing)
Hola Chevy,
Ordenar un shape se hace en memoria (básicamente ordenar casi cualquier cosa se hace en memoria). Si ordenamos una tabla de un shp de 200.000 registros sin aplicar ningún filtro el comportamiento normal es que pete.
Para subsanar esto, lo correcto no sería usar formatos tipo shp, sino base de datos.
Quizá se podrían hacer cosas, pero a saber el coste de las mismas...
Lo paso a feature request para contemplarlo como posible mejora en el futuro.
#7
Updated by Joaquín del Cerro Murciano about 10 years ago
Es posible que los arreglos realizados en relacion al ticket #2283 mejoren algo en relacion a este ticket. No se ha hecho nada al respecto para ordenar en disco (no en memoria), con lo que es probable que con tablas muy grandes siga fallando la ordenacion.
#8
Updated by Álvaro Anguix about 10 years ago
- Priority changed from Urgent to Normal
#9
Updated by Álvaro Anguix about 10 years ago
- Assignee deleted (
Joaquín del Cerro Murciano)
#10
Updated by Álvaro Anguix over 9 years ago
- Status changed from New to Closed
Con los últimos builds de la 2.1 he realizado pruebas y ordena shapes de 200.000 registros bastante rápido (pocos segundos) y sin errores. Lo paso a closed.