[Dspace-devel] [DuraSpace JIRA] Closed: (DS-871) XMLUI caches community / collection page which doesn't show a recently submitted item immediately
[ https://jira.duraspace.org/browse/DS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Dietz closed DS-871. -- Resolution: Fixed Fix Version/s: 1.8.0 Assignee: Peter Dietz Committed the proposed patch to 1.7.x (to make it into 1.7.2), and to trunk to make it into 1.8 > XMLUI caches community / collection page which doesn't show a recently > submitted item immediately > - > > Key: DS-871 > URL: https://jira.duraspace.org/browse/DS-871 > Project: DSpace > Issue Type: Bug > Components: XMLUI >Affects Versions: 1.7.0, 1.7.1 >Reporter: Peter Dietz >Assignee: Peter Dietz > Fix For: 1.7.2, 1.8.0 > > Attachments: DS-871-invalidate-cache-on-recycle.diff > > > With discovery disabled in xmlui, a recently submitted item does not show on > the recently submitted items list for the collection or community page, until > the page cache expires. This may be by design, but it is a route that a user > may be expecting to find their recently submitted item. > Perhaps on submission, the cache for the parent container pages can be > invalidated so that the next page view of it will get the recently submitted > item in the list. > To reproduce, in xmlui (tested with discovery off), view a collection page, > then submit a new item to that collection, and go back to that collection > page after submission. Continuously refreshing the page will not show the new > item, unless a user tries to hard-clear the xmlui cache. Such as appending > junk to the url as a parameter. i.e. > servername.com/handle/123456789/1234?random-text -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-898) Caching error in browse, search and discovery results
[ https://jira.duraspace.org/browse/DS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20343#action_20343 ] Hardy Pottinger commented on DS-898: Hi, I've confirmed that, with the revised patch, searching no longer throws NPEs, and have put the code into production in our repository. Thanks to the quick response from everyone, we have a great community here! > Caching error in browse, search and discovery results > - > > Key: DS-898 > URL: https://jira.duraspace.org/browse/DS-898 > Project: DSpace > Issue Type: Bug > Components: XMLUI >Affects Versions: 1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.1 >Reporter: Ben Bosman >Assignee: Ben Bosman >Priority: Major > Fix For: 1.8.0 > > > The results page for browse, search and discovery uses caching based on the > validity. This validity takes the listed items into account. It doesn't take > the amount of results into account however. > The total amount of results is incorrect if the page was rendered before, and > the same list of items is returned, but some items are added or removed which > are not displayed on the current page -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-841) 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI admin eperson (with Oracle backend)
[ https://jira.duraspace.org/browse/DS-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20339#action_20339 ] Mark H. Wood commented on DS-841: - The remaining part of DS-633 (in DatabaseManager) should at least give us a more descriptive Exception for understanding what happened, should the affected condition arise. The code which led to DS-633 is not yet part of stock DSpace, but I can provide a copy if you want one. > 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI > admin eperson (with Oracle backend) > --- > > Key: DS-841 > URL: https://jira.duraspace.org/browse/DS-841 > Project: DSpace > Issue Type: Bug >Affects Versions: 1.7.0, 1.7.1 > Environment: RHEL5, with Oracle on the back end >Reporter: Hardy Pottinger > Fix For: 1.7.2 > > Attachments: DS-841-fix-Oracle-compatibility-for-ePerson.patch > > > In using the 1.7.x branch for testing with Oracle. Everything installed fine, > and I've got a bare-bones repository up and running. However, in the XMLUI, > when I click on the admin ePeople link, I get the following error: > java.lang.IllegalArgumentException: No such column rnum > Here are the first few lines of the stack trace: > java.lang.IllegalArgumentException: No such column rnum > at > org.dspace.storage.rdbms.TableRow.canonicalizeAndCheck(TableRow.java:581) > at org.dspace.storage.rdbms.TableRow.setColumn(TableRow.java:433) > at > org.dspace.storage.rdbms.DatabaseManager.process(DatabaseManager.java:) > at > org.dspace.storage.rdbms.TableRowIterator.next(TableRowIterator.java:151) > at > org.dspace.storage.rdbms.TableRowIterator.toList(TableRowIterator.java:204) > at org.dspace.eperson.EPerson.search(EPerson.java:358) > at > org.dspace.app.xmlui.aspect.administrative.eperson.ManageEPeopleMain.addBody(ManageEPeopleMain.java:121) > at > org.dspace.app.xmlui.wing.AbstractWingTransformer.startElement(AbstractWingTransformer.java:223) > at sun.reflect.GeneratedMethodAccessor213.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71) > at $Proxy66.startElement(Unknown Source) > at > org.apache.cocoon.components.sax.XMLTeePipe.startElement(XMLTeePipe.java:87) > at > org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:94) > at > org.dspace.app.xmlui.wing.AbstractWingTransformer.startElement(AbstractWingTransformer.java:240) > at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71) > at $Proxy49.startElement(Unknown Source) > No such error is thrown when using the JSPUI. > > org.dspace.storage.rdbms.TableRow.canonicalizeAndCheck(TableRow.java:581 > Looking more closely at the stack trace, the problem appears to be that the > canonicalizeAndCheck method in TableRow is failing when it attempts to verify > the rnum column, which is created back in org.dspace.eperson.EPerson.search. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-841) 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI admin eperson (with Oracle backend)
[ https://jira.duraspace.org/browse/DS-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20338#action_20338 ] Hardy Pottinger commented on DS-841: Hi, I wanted to be clear, if this patch is accepted, it may have the affect of turning back on DS-633, as this patch partially reverts code changes that were meant to fix that issue (at the expense of Oracle compatibility). I did point this out when I submitted the patch, but wanted to be sure it wasn't missed. I've been so far unable to find conditions to replicate DS-633, but am willing to test to see if DS-633 shows back up while running this patch, if someone can help me figure that out. > 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI > admin eperson (with Oracle backend) > --- > > Key: DS-841 > URL: https://jira.duraspace.org/browse/DS-841 > Project: DSpace > Issue Type: Bug >Affects Versions: 1.7.0, 1.7.1 > Environment: RHEL5, with Oracle on the back end >Reporter: Hardy Pottinger > Fix For: 1.7.2 > > Attachments: DS-841-fix-Oracle-compatibility-for-ePerson.patch > > > In using the 1.7.x branch for testing with Oracle. Everything installed fine, > and I've got a bare-bones repository up and running. However, in the XMLUI, > when I click on the admin ePeople link, I get the following error: > java.lang.IllegalArgumentException: No such column rnum > Here are the first few lines of the stack trace: > java.lang.IllegalArgumentException: No such column rnum > at > org.dspace.storage.rdbms.TableRow.canonicalizeAndCheck(TableRow.java:581) > at org.dspace.storage.rdbms.TableRow.setColumn(TableRow.java:433) > at > org.dspace.storage.rdbms.DatabaseManager.process(DatabaseManager.java:) > at > org.dspace.storage.rdbms.TableRowIterator.next(TableRowIterator.java:151) > at > org.dspace.storage.rdbms.TableRowIterator.toList(TableRowIterator.java:204) > at org.dspace.eperson.EPerson.search(EPerson.java:358) > at > org.dspace.app.xmlui.aspect.administrative.eperson.ManageEPeopleMain.addBody(ManageEPeopleMain.java:121) > at > org.dspace.app.xmlui.wing.AbstractWingTransformer.startElement(AbstractWingTransformer.java:223) > at sun.reflect.GeneratedMethodAccessor213.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71) > at $Proxy66.startElement(Unknown Source) > at > org.apache.cocoon.components.sax.XMLTeePipe.startElement(XMLTeePipe.java:87) > at > org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:94) > at > org.dspace.app.xmlui.wing.AbstractWingTransformer.startElement(AbstractWingTransformer.java:240) > at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71) > at $Proxy49.startElement(Unknown Source) > No such error is thrown when using the JSPUI. > > org.dspace.storage.rdbms.TableRow.canonicalizeAndCheck(TableRow.java:581 > Looking more closely at the stack trace, the problem appears to be that the > canonicalizeAndCheck method in TableRow is failing when it attempts to verify > the rnum column, which is created back in org.dspace.eperson.EPerson.search. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-898) Caching error in browse, search and discovery results
[ https://jira.duraspace.org/browse/DS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20337#action_20337 ] Ben Bosman commented on DS-898: --- I was able to verify there was an error pasting the changes to the AbstractSearch class. I moved the lines to the correct location now. > Caching error in browse, search and discovery results > - > > Key: DS-898 > URL: https://jira.duraspace.org/browse/DS-898 > Project: DSpace > Issue Type: Bug > Components: XMLUI >Affects Versions: 1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.1 >Reporter: Ben Bosman >Assignee: Ben Bosman >Priority: Major > Fix For: 1.8.0 > > > The results page for browse, search and discovery uses caching based on the > validity. This validity takes the listed items into account. It doesn't take > the amount of results into account however. > The total amount of results is incorrect if the page was rendered before, and > the same list of items is returned, but some items are added or removed which > are not displayed on the current page -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] [Dspace-tech] XMLUI weirdness--RESOLVED
Hi Jeff, I'm not aware of the ehcache file getting stale, usually a tomcat restart will cure what ails us. But its probably fine to clean it out regularly. (Note, I'm not the expert on this). However, I am a de-facto expert at running into xmlui weirdness with cache. The overall solution might be to have more investigating into each component that gets cached, to make sure that it is properly setting its cacheable elements, and invalidating them when the situation changes. Regarding webapp locations, I prefer to keep all my dspace webapps where ant puts them: [dspace]/webapps. Then I edit tomcat's server.xml to add context listeners for all of DSpace's webapps. https://wiki.duraspace.org/display/DSPACE/Installing+DSpace+1.7+on+Ubuntu+10.10#InstallingDSpace1.7onUbuntu10.10-ConfigureTomcattoknowabouttheDSpacewebapps. Peter Dietz On Mon, May 16, 2011 at 9:59 AM, Jeffrey Trimble wrote: > I reported an issue with XMLUI as "weirdness". Several private suggestions > came to me. Though those didn't answer the issue at hand, they > did give me some great ideas of fixing other issues that I needed to > address. > > This weekend, while looking at logs (Catalina logs in Tomcat) and other > files, I was reminded that there is a "cache" file in Cocoon that needs > attention. If you go to: [Tomcat]/work/Catalina/localhost/xmlui/cache-dir > you will find two files: > >cocoon-ehcache.data >cocoon-ehcache.index > > If you delete the cocoon-ehcache.data file and restart tomcat, the issue I > experienced goes away. It seems that Cocoon is not updating > this file appropriately in any automated fashion (from rebuilding DSpace > from scratch). > > There is one other issue connected with this problem, where I do not have > any hard data to support it, but I will put it out for discussion. Is there > a > difference were the DSpace Webapps reside that makes this happen or not > happen. For example, our webapps are at [dspace]/webapps/* > instead of the standard [tomcat]/webapps/* . These are two options we have > in our documentation. The first option is one that I implemented > with release 1.6 at my own local installation. Very convenient. Prior to > 1.6, I had always copied over the webapps to the Catalina$ directories. > > Food for thought. > > Perhaps we should update the documentation with the above tip about > deleting the cache file on a regular basis or when DSpace is rebuilt/updated > at any time. > > Comments? > > Thanks > > Jeff > > > > On May 9, 2011, at 4:19 PM, Jeffrey Trimble wrote: > > > I have a strange XMLUI "weirdness" happening. When you choose a "browse" > search, you usually retrieve the first entry in the browse index. > > For Title, dates, series, subject this works just fine. When you choose > "author" (at least in my current install), you retrieve a slightly > > disfunctional display. Everything looks just, how can I say this "more > twisted than a color tv". If you click the "next" button or the previous > > button or choose an alpha character that will drop you further into the > index, all is well. > > > > What do you make of this? My solution, that has worked, has been to > re-compile DSpace. That seems so drastic. > > > > Please look at http://digital.maag.ysu.edu and then choose "Author" > browse on the rh. side. > > > > All ideas are welcome. > > > > Thanks in advance, > > > > Jeffrey Trimble > System LIbrarian > William F. Maag Library > Youngstown State University > 330.941.2483 (Office) > jatrim...@ysu.edu > http://www.maag.ysu.edu > http://digital.maag.ysu.edu > ""For he is the Kwisatz Haderach..." > > > > -- > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Updated: (DS-871) XMLUI caches community / collection page which doesn't show a recently submitted item immediately
[ https://jira.duraspace.org/browse/DS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Donohue updated DS-871: --- Fix Version/s: 1.7.2 > XMLUI caches community / collection page which doesn't show a recently > submitted item immediately > - > > Key: DS-871 > URL: https://jira.duraspace.org/browse/DS-871 > Project: DSpace > Issue Type: Bug > Components: XMLUI >Affects Versions: 1.7.0, 1.7.1 >Reporter: Peter Dietz > Fix For: 1.7.2 > > Attachments: DS-871-invalidate-cache-on-recycle.diff > > > With discovery disabled in xmlui, a recently submitted item does not show on > the recently submitted items list for the collection or community page, until > the page cache expires. This may be by design, but it is a route that a user > may be expecting to find their recently submitted item. > Perhaps on submission, the cache for the parent container pages can be > invalidated so that the next page view of it will get the recently submitted > item in the list. > To reproduce, in xmlui (tested with discovery off), view a collection page, > then submit a new item to that collection, and go back to that collection > page after submission. Continuously refreshing the page will not show the new > item, unless a user tries to hard-clear the xmlui cache. Such as appending > junk to the url as a parameter. i.e. > servername.com/handle/123456789/1234?random-text -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Updated: (DS-871) XMLUI caches community / collection page which doesn't show a recently submitted item immediately
[ https://jira.duraspace.org/browse/DS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Donohue updated DS-871: --- Status: Open (was: Received) > XMLUI caches community / collection page which doesn't show a recently > submitted item immediately > - > > Key: DS-871 > URL: https://jira.duraspace.org/browse/DS-871 > Project: DSpace > Issue Type: Bug > Components: XMLUI >Affects Versions: 1.7.0, 1.7.1 >Reporter: Peter Dietz > Attachments: DS-871-invalidate-cache-on-recycle.diff > > > With discovery disabled in xmlui, a recently submitted item does not show on > the recently submitted items list for the collection or community page, until > the page cache expires. This may be by design, but it is a route that a user > may be expecting to find their recently submitted item. > Perhaps on submission, the cache for the parent container pages can be > invalidated so that the next page view of it will get the recently submitted > item in the list. > To reproduce, in xmlui (tested with discovery off), view a collection page, > then submit a new item to that collection, and go back to that collection > page after submission. Continuously refreshing the page will not show the new > item, unless a user tries to hard-clear the xmlui cache. Such as appending > junk to the url as a parameter. i.e. > servername.com/handle/123456789/1234?random-text -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Updated: (DS-875) DSpace Configuration service error when using "dspace" script.
[
https://jira.duraspace.org/browse/DS-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue updated DS-875:
---
Fix Version/s: (was: 1.8.0)
1.7.2
> DSpace Configuration service error when using "dspace" script.
> --
>
> Key: DS-875
> URL: https://jira.duraspace.org/browse/DS-875
> Project: DSpace
> Issue Type: Bug
> Components: DSpace API
>Affects Versions: 1.7.1
>Reporter: Kevin Van de Velde
>Priority: Major
> Fix For: 1.7.2
>
> Attachments: dspace_script_bugfix.patch
>
>
> When using the dspace script (located in {dspace.dir}/bin directory) in
> DSpace 1.7.1 the following error will occur:
> java.lang.IllegalArgumentException: Resource path
> [{dspace.dir.path}/bin/dspace] does not denote a directory
> at
> org.springframework.core.io.support.PathMatchingResourcePatternResolver.retrieveMatchingFiles(PathMatchingResourcePatternResolver.java:563)
> at
> org.springframework.core.io.support.PathMatchingResourcePatternResolver.doFindMatchingFileSystemResources(PathMatchingResourcePatternResolver.java:543)
> at
> org.springframework.core.io.support.PathMatchingResourcePatternResolver.doFindPathMatchingFileResources(PathMatchingResourcePatternResolver.java:526)
> at
> org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:342)
> at
> org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:276)
> at
> org.dspace.servicemanager.config.DSpaceConfigurationService.loadInitialConfig(DSpaceConfigurationService.java:390)
> at
> org.dspace.servicemanager.config.DSpaceConfigurationService.(DSpaceConfigurationService.java:62)
> at
> org.dspace.servicemanager.DSpaceKernelImpl.start(DSpaceKernelImpl.java:145)
> at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:51)
> This error in itself is completely harmless since it is actually a log bug,
> there is an e.printstacktrace() that should have been a log.error, the
> configuration service will just fail to load the dspace config files in the
> jars (which is harmless since the configuration service isn't used by DSpace
> at the moment).
> The reason why the error is thrown lies in the configuration service, the
> following method is called when attempting to retrieve .cfg files from the
> classpath.
> PathMatchingResourcePatternResolver patchMatcher = new
> PathMatchingResourcePatternResolver();
> Resource[] resources =
> patchMatcher.getResources("classpath*:dspace/config-*.cfg");
> From the Spring documentation
> (http://static.springsource.org/spring/docs/2.5.x/reference/resources.html):
> Please note that "classpath*:" when combined with Ant-style patterns
> will only work reliably with at least one root directory before the
> pattern starts, unless the actual target files reside in the file
> system. This means that a pattern like "classpath*:*.xml" will not
> retrieve files from the root of jar files but rather only from the
> root of expanded directories. This originates from a limitation in the
> JDK's ClassLoader.getResources() method which only returns file system
> locations for a passed-in empty string (indicating potential roots to
> search).
> From the dspace script:
> FULLPATH=$CLASSPATH:$JARS:$DSPACEDIR/config
> java $JAVA_OPTS -classpath $FULLPATH org.dspace.app.launcher.ScriptLauncher
> "$@"
> Conclusion:
> The problem is caused by the fact that the JDK is expecting directories or
> directories with at least one subdirectory to be passed in the FULLPATH
> argument when invoking Java. It is obvious that {dspace.dir}/bin/dspace
> violates these requirements, causing the process to throw an exception when
> trying to use this location as a directory. In order to solve this, I suggest
> removing the $CLASSPATH variable from the FULLPATH argument because I do not
> expect it to be of any use when running DSpace processes. I have verified the
> behavior of the dspace command after removing the $CLASSPATH variable and all
> processes seem to be working fine. However, in case this variable would be
> required for a reason I missed, a different solution should be used. The
> easiest alternative would be to properly handle the $CLASSPATH argument in
> order to avoid the exception.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Achieve unprecedented app performance
[Dspace-devel] [DuraSpace JIRA] Updated: (DS-841) 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI admin eperson (with Oracle backend)
[ https://jira.duraspace.org/browse/DS-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Donohue updated DS-841: --- Status: Open (was: Received) > 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI > admin eperson (with Oracle backend) > --- > > Key: DS-841 > URL: https://jira.duraspace.org/browse/DS-841 > Project: DSpace > Issue Type: Bug >Affects Versions: 1.7.0, 1.7.1 > Environment: RHEL5, with Oracle on the back end >Reporter: Hardy Pottinger > Attachments: DS-841-fix-Oracle-compatibility-for-ePerson.patch > > > In using the 1.7.x branch for testing with Oracle. Everything installed fine, > and I've got a bare-bones repository up and running. However, in the XMLUI, > when I click on the admin ePeople link, I get the following error: > java.lang.IllegalArgumentException: No such column rnum > Here are the first few lines of the stack trace: > java.lang.IllegalArgumentException: No such column rnum > at > org.dspace.storage.rdbms.TableRow.canonicalizeAndCheck(TableRow.java:581) > at org.dspace.storage.rdbms.TableRow.setColumn(TableRow.java:433) > at > org.dspace.storage.rdbms.DatabaseManager.process(DatabaseManager.java:) > at > org.dspace.storage.rdbms.TableRowIterator.next(TableRowIterator.java:151) > at > org.dspace.storage.rdbms.TableRowIterator.toList(TableRowIterator.java:204) > at org.dspace.eperson.EPerson.search(EPerson.java:358) > at > org.dspace.app.xmlui.aspect.administrative.eperson.ManageEPeopleMain.addBody(ManageEPeopleMain.java:121) > at > org.dspace.app.xmlui.wing.AbstractWingTransformer.startElement(AbstractWingTransformer.java:223) > at sun.reflect.GeneratedMethodAccessor213.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71) > at $Proxy66.startElement(Unknown Source) > at > org.apache.cocoon.components.sax.XMLTeePipe.startElement(XMLTeePipe.java:87) > at > org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:94) > at > org.dspace.app.xmlui.wing.AbstractWingTransformer.startElement(AbstractWingTransformer.java:240) > at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71) > at $Proxy49.startElement(Unknown Source) > No such error is thrown when using the JSPUI. > > org.dspace.storage.rdbms.TableRow.canonicalizeAndCheck(TableRow.java:581 > Looking more closely at the stack trace, the problem appears to be that the > canonicalizeAndCheck method in TableRow is failing when it attempts to verify > the rnum column, which is created back in org.dspace.eperson.EPerson.search. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Updated: (DS-841) 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI admin eperson (with Oracle backend)
[ https://jira.duraspace.org/browse/DS-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Donohue updated DS-841: --- Fix Version/s: 1.7.2 > 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI > admin eperson (with Oracle backend) > --- > > Key: DS-841 > URL: https://jira.duraspace.org/browse/DS-841 > Project: DSpace > Issue Type: Bug >Affects Versions: 1.7.0, 1.7.1 > Environment: RHEL5, with Oracle on the back end >Reporter: Hardy Pottinger > Fix For: 1.7.2 > > Attachments: DS-841-fix-Oracle-compatibility-for-ePerson.patch > > > In using the 1.7.x branch for testing with Oracle. Everything installed fine, > and I've got a bare-bones repository up and running. However, in the XMLUI, > when I click on the admin ePeople link, I get the following error: > java.lang.IllegalArgumentException: No such column rnum > Here are the first few lines of the stack trace: > java.lang.IllegalArgumentException: No such column rnum > at > org.dspace.storage.rdbms.TableRow.canonicalizeAndCheck(TableRow.java:581) > at org.dspace.storage.rdbms.TableRow.setColumn(TableRow.java:433) > at > org.dspace.storage.rdbms.DatabaseManager.process(DatabaseManager.java:) > at > org.dspace.storage.rdbms.TableRowIterator.next(TableRowIterator.java:151) > at > org.dspace.storage.rdbms.TableRowIterator.toList(TableRowIterator.java:204) > at org.dspace.eperson.EPerson.search(EPerson.java:358) > at > org.dspace.app.xmlui.aspect.administrative.eperson.ManageEPeopleMain.addBody(ManageEPeopleMain.java:121) > at > org.dspace.app.xmlui.wing.AbstractWingTransformer.startElement(AbstractWingTransformer.java:223) > at sun.reflect.GeneratedMethodAccessor213.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71) > at $Proxy66.startElement(Unknown Source) > at > org.apache.cocoon.components.sax.XMLTeePipe.startElement(XMLTeePipe.java:87) > at > org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:94) > at > org.dspace.app.xmlui.wing.AbstractWingTransformer.startElement(AbstractWingTransformer.java:240) > at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71) > at $Proxy49.startElement(Unknown Source) > No such error is thrown when using the JSPUI. > > org.dspace.storage.rdbms.TableRow.canonicalizeAndCheck(TableRow.java:581 > Looking more closely at the stack trace, the problem appears to be that the > canonicalizeAndCheck method in TableRow is failing when it attempts to verify > the rnum column, which is created back in org.dspace.eperson.EPerson.search. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-898) Caching error in browse, search and discovery results
[ https://jira.duraspace.org/browse/DS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20334#action_20334 ] Peter Dietz commented on DS-898: @Hardy, See the commit to trunk/1.8 for your patch: Pretty: https://github.com/DSpace/DSpace/commit/9a907b0f5ebabb7686d982f3213443a659a7a359 Diff/patch: https://github.com/DSpace/DSpace/commit/9a907b0f5ebabb7686d982f3213443a659a7a359.diff @Mark and @Tim, I think we'll stick with our decision to keep 1.7.2 limited to things broken _by_ the 1.7.x work. Since this appears to have affected previous versions (1.6.x) as well, then the general fix can come in 1.8.0. > Caching error in browse, search and discovery results > - > > Key: DS-898 > URL: https://jira.duraspace.org/browse/DS-898 > Project: DSpace > Issue Type: Bug > Components: XMLUI >Affects Versions: 1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.1 >Reporter: Ben Bosman >Assignee: Ben Bosman >Priority: Major > Fix For: 1.8.0 > > > The results page for browse, search and discovery uses caching based on the > validity. This validity takes the listed items into account. It doesn't take > the amount of results into account however. > The total amount of results is incorrect if the page was rendered before, and > the same list of items is returned, but some items are added or removed which > are not displayed on the current page -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] [Dspace-tech] XMLUI weirdness--RESOLVED
I reported an issue with XMLUI as "weirdness". Several private suggestions came to me. Though those didn't answer the issue at hand, they did give me some great ideas of fixing other issues that I needed to address. This weekend, while looking at logs (Catalina logs in Tomcat) and other files, I was reminded that there is a "cache" file in Cocoon that needs attention. If you go to: [Tomcat]/work/Catalina/localhost/xmlui/cache-dir you will find two files: cocoon-ehcache.data cocoon-ehcache.index If you delete the cocoon-ehcache.data file and restart tomcat, the issue I experienced goes away. It seems that Cocoon is not updating this file appropriately in any automated fashion (from rebuilding DSpace from scratch). There is one other issue connected with this problem, where I do not have any hard data to support it, but I will put it out for discussion. Is there a difference were the DSpace Webapps reside that makes this happen or not happen. For example, our webapps are at [dspace]/webapps/* instead of the standard [tomcat]/webapps/* . These are two options we have in our documentation. The first option is one that I implemented with release 1.6 at my own local installation. Very convenient. Prior to 1.6, I had always copied over the webapps to the Catalina$ directories. Food for thought. Perhaps we should update the documentation with the above tip about deleting the cache file on a regular basis or when DSpace is rebuilt/updated at any time. Comments? Thanks Jeff On May 9, 2011, at 4:19 PM, Jeffrey Trimble wrote: > I have a strange XMLUI "weirdness" happening. When you choose a "browse" > search, you usually retrieve the first entry in the browse index. > For Title, dates, series, subject this works just fine. When you choose > "author" (at least in my current install), you retrieve a slightly > disfunctional display. Everything looks just, how can I say this "more > twisted than a color tv". If you click the "next" button or the previous > button or choose an alpha character that will drop you further into the > index, all is well. > > What do you make of this? My solution, that has worked, has been to > re-compile DSpace. That seems so drastic. > > Please look at http://digital.maag.ysu.edu and then choose "Author" browse on > the rh. side. > > All ideas are welcome. > > Thanks in advance, > Jeffrey Trimble System LIbrarian William F. Maag Library Youngstown State University 330.941.2483 (Office) jatrim...@ysu.edu http://www.maag.ysu.edu http://digital.maag.ysu.edu ""For he is the Kwisatz Haderach..." -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-866) OAI requests with resumption token start at the wrong offset if non-public items are included and there are withdrawn items
[ https://jira.duraspace.org/browse/DS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20330#action_20330 ] Robin Taylor commented on DS-866: - Can I retract that last comment ?! Looking at the code provided with DS-829 I think it may exacerbate the problems with Resumption Tokens. > OAI requests with resumption token start at the wrong offset if non-public > items are included and there are withdrawn items > --- > > Key: DS-866 > URL: https://jira.duraspace.org/browse/DS-866 > Project: DSpace > Issue Type: Bug > Components: DSpace API >Affects Versions: 1.6.1, 1.6.2, 1.7.0, 1.7.1 >Reporter: Andrea Schweer >Priority: Major > Fix For: 1.8.0 > > Attachments: oai-offset.patch > > > In some circumstances, items are not disseminated via OAI. > OAI responds to listRecords requests with batches of up to 100 (or other > number set via oai.didl.maxresponse property) records. Requests can include a > resumption token to specify which batch is required. The resumption token is > then translated into an offset to the response from the database. > OAI listRecords responses contain withdrawn items (marked as "deleted"). > If harvest.includerestricted.oai = false is set in dspace.cfg, only publicly > readable items are included in the response. The offset into the database > results is recalculated to skip over restricted items. If a withdrawn item is > found in the database response, this item will also be skipped over by the > offset recalculation code (because it is not publicly readable) even though > it shouldn't because it will still be included in the OAI response. The code > that actually adds items to the response, in contrast, does not skip over > withdrawn items. The next batch will start n items later in the database > response than it should, where n is the number of withdrawn items before the > start of the batch. > This means that a full OAI harvest via consecutive listRecords requests will > miss as many items as there are withdrawn items. > I first found this in the 1.6.1 code and it is still present in 1.7.1. I > didn't check whether this affects earlier versions too. A patch against 1.7.1 > is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-898) Caching error in browse, search and discovery results
[ https://jira.duraspace.org/browse/DS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20328#action_20328 ] Hardy Pottinger commented on DS-898: See this thread on DSpace-tech: http://sourceforge.net/mailarchive/message.php?msg_id=27508120 looks like in production, with this patch applied, we've found that searches produce an NPE with a stack trace that points back to lines of code from this patch. In production, we're planning to revert this patch, but in testing we'll try out Graham's suggestion, and will post any revised patches that we can confirm still addresses the issue with DS-898, as well as does not produce NPEs when searching. I will keep an eye out for any modifications to this ticket, in the mean time. > Caching error in browse, search and discovery results > - > > Key: DS-898 > URL: https://jira.duraspace.org/browse/DS-898 > Project: DSpace > Issue Type: Bug > Components: XMLUI >Affects Versions: 1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.1 >Reporter: Ben Bosman >Assignee: Ben Bosman >Priority: Major > Fix For: 1.8.0 > > > The results page for browse, search and discovery uses caching based on the > validity. This validity takes the listed items into account. It doesn't take > the amount of results into account however. > The total amount of results is incorrect if the page was rendered before, and > the same list of items is returned, but some items are added or removed which > are not displayed on the current page -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-866) OAI requests with resumption token start at the wrong offset if non-public items are included and there are withdrawn items
[ https://jira.duraspace.org/browse/DS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20327#action_20327 ] Robin Taylor commented on DS-866: - Haven't tested this theory but at first glance DS-829 may include code to resolve this problem. Cheers, Robin. > OAI requests with resumption token start at the wrong offset if non-public > items are included and there are withdrawn items > --- > > Key: DS-866 > URL: https://jira.duraspace.org/browse/DS-866 > Project: DSpace > Issue Type: Bug > Components: DSpace API >Affects Versions: 1.6.1, 1.6.2, 1.7.0, 1.7.1 >Reporter: Andrea Schweer >Priority: Major > Fix For: 1.8.0 > > Attachments: oai-offset.patch > > > In some circumstances, items are not disseminated via OAI. > OAI responds to listRecords requests with batches of up to 100 (or other > number set via oai.didl.maxresponse property) records. Requests can include a > resumption token to specify which batch is required. The resumption token is > then translated into an offset to the response from the database. > OAI listRecords responses contain withdrawn items (marked as "deleted"). > If harvest.includerestricted.oai = false is set in dspace.cfg, only publicly > readable items are included in the response. The offset into the database > results is recalculated to skip over restricted items. If a withdrawn item is > found in the database response, this item will also be skipped over by the > offset recalculation code (because it is not publicly readable) even though > it shouldn't because it will still be included in the OAI response. The code > that actually adds items to the response, in contrast, does not skip over > withdrawn items. The next batch will start n items later in the database > response than it should, where n is the number of withdrawn items before the > start of the batch. > This means that a full OAI harvest via consecutive listRecords requests will > miss as many items as there are withdrawn items. > I first found this in the 1.6.1 code and it is still present in 1.7.1. I > didn't check whether this affects earlier versions too. A patch against 1.7.1 > is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-818) Asynchronous Release
[ https://jira.duraspace.org/browse/DS-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20326#action_20326 ] Robin Taylor commented on DS-818: - As a side benefit the removal of the dspace-parent pom might resolve the issues with Maven 3 and duplicate projects as described in DS-881. Cheers, Robin. > Asynchronous Release > > > Key: DS-818 > URL: https://jira.duraspace.org/browse/DS-818 > Project: DSpace > Issue Type: New Feature > Components: Documentation, DSpace API, JSPUI, Language Packs, LNI, > OAI-PMH, REST API (experimental), Solr, SWORD, Unit Testing Framework, XMLUI >Reporter: Mark Diggory >Assignee: Mark Diggory >Priority: Major > Fix For: 1.8.0 > > > Asynchronous Release: Asynchronous Release is change in the DSpace release > process and version numbering process on modules within the DSpace trunk to > allow more flexibility adding prebuilt Addon modules into DSpace. > Goals > The primary goal of Async release is to break the the authoritative grip that > dspace-parent has on the version assignment and dependencyManagement in the > DSpace trunk modules such that: > Make the build in the DSpace Modules Source Tree dependent on a specific > dspace-api and dspace-xmlui-api versions. Specifically, dspace-statistics and > dspace-discovery > Make a packaged release of DSpace that includes a combination of Trunk and > Module projects. > More easily package releases of DSpace cyclically while allowing minor > updates of core modules to occur more often, to easily provide a minor update > path for DSpace. > View wiki page for further details. > https://wiki.duraspace.org/display/DSPACE/Asynchronous+Release -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-892) Performance issues in update enabling the StatisticsLoggingConsumer
[ https://jira.duraspace.org/browse/DS-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20325#action_20325 ] Bram Luyten (@mire) commented on DS-892: With the risk of going out of scope on this issue, I was wondering what the desired behavior would be, with regards to updates/changes of statistics after moves or deletes of items. In one way, you could think that statistics information from the past should be immutable to ensure consistency with previous reports. E.G, If I'm a repository manager, making monthly reports to my director about bitstream downloads for each of the collections, I don't want the current interface to contradict figures I reported from the past. So in that respect, item pageviews and downloads should only start counting for the new collection or community they are added to, after the move. I can imagine there are usecases that totally contradict this. (for example, if a collection represents a department, and the department is split into two new departments (e.g. two new collections), you do want to transfer those historical downloads and pageviews to the new collection). > Performance issues in update enabling the StatisticsLoggingConsumer > --- > > Key: DS-892 > URL: https://jira.duraspace.org/browse/DS-892 > Project: DSpace > Issue Type: Bug > Components: Solr >Affects Versions: 1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.1 >Reporter: Andrea Bollini >Priority: Critical > > We have found that enabling the StatisticsLoggingConsumer to keep statistics > data up-to-date after item changes (metadata edit or collection > moving/mapping) the item update operations become slowly and the system > unusable. > NOTE: the StatisticsLoggingConsumer is NOT enabled out-of-box in the > dspace.cfg this imply that your statistics data could be incongruous (item > access assigned to incorrect communities/collections) > We noticed problems when there are large amount of statistics data (> 20M > records), for small repository (< 1M statistics record) the overhead is > acceptable. > Finally, after the introduction of the autocommit patch, the > StatisticsLoggingConsumer is not more able to assure the data consistence > because the statistics data collected between two auto-commit are not > processed by the class. > Our current idea is to discard the consumer approach in favour to implement a > batch tools to periodically analyze the statistics data and fix it as > appropriate. > This issue is a placeholder for such feature and discussion around it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
