Re: [dspace-tech] Orcid v2

[Shaun donovan]

Thanks Tim.

I must be doing something wrong. Will try it again.

Shaun.


On 16/08/2018 17:22, Tim Donohue wrote:

Hi Shaun,

ORCID v2 integration was fixed in DSpace 5.9 and 6.3.  So, yes, it 
should be working in either of those versions.  Here's the ticket that 
tracked the fixes:

https://jira.duraspace.org/browse/DS-3447

You can try out ORCID v2 integration on our demo site at: 
http://demo.dspace.org (currently running 6.3).  On that site, you can 
select either the XMLUI or JSPUI interface.  Demo logins are listed on 
the homepage of either the XMLUI or JSPUI.


After logging in, if you submit a new item, the Authors field provides 
a "Lookup" button which allows you to search for people (via name) 
using the ORCID v2 API.


More information about DSpace ORCID integration is at 
https://wiki.duraspace.org/display/DSDOC6x/ORCID+Integration


- Tim



On Thu, Aug 16, 2018 at 6:28 AM Shaun donovan > wrote:


Hi All.

I have searched for a solution to the Orcid v2 problem, but have
not found one.

This thread
https://groups.google.com/forum/#%21topic/dspace-tickets/NUKWQL6gV98
suggests that in version 6.3 and version 5.9, one should be able
to use Orcid functionality, but only if one uses the Orcid ID in
the lookup field. I have installed a clean DSpace 6.3 and have
tried to test this functionality. The lookup always comes back
with "No people found", whether I search on Orcid ID or name.
Watching the traffic with tcpdump, I can see communications with
pub.orcid.org , but it is all encrypted.

Is this supposed to be working and I have a configuration error,
or is this a general problem?

Thanks up front.

Shaun.
-- 
All messages to this mailing list should adhere to the DuraSpace

Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
You received this message because you are subscribed to the Google
Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to dspace-tech+unsubscr...@googlegroups.com
.
To post to this group, send email to dspace-tech@googlegroups.com
.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

--
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org


--
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] Re: Questions about the checksum checker in DSpace 6.2

[Tim Donohue]

Hello Evgeni,

The fix in https://github.com/DSpace/DSpace/pull/2169 is a major change in
behavior (it reverts back to the same way this was done in 5.x).  In the
current 6.x code, the giant list of objects is loaded into JVM memory (in a
big Java code loop), which is a significant performance hit in Hibernate.

You can see this behavior here:
https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace-api/src/main/java/org/dspace/checker/MostRecentChecksumServiceImpl.java#L121

The proposed fix no longer loads these objects into the JVM / Hibernate,
and instead reverts back to performing this action in a single database
query (as it was in 5.x). Yes, the database query is complex and may still
take a while to run (for large sites), but it should be significantly
faster than loading thousands of objects into the JVM.

You can see the old 5.x behavior here:
https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace-api/src/main/java/org/dspace/checker/BitstreamInfoDAO.java#L63

I suspect anyone who is seeing significant performance issues in Checksum
Checker after upgrading from 5.x to 6.x will likely find this new PR will
bring performance back to 5.x levels. I'm sure we could improve performance
even further, though it may require some more analysis as to the best way
to refactor the database & code to do so. Obviously, we always welcome
improvements & contributions to DSpace in the form of Pull Requests.

- Tim



On Thu, Aug 16, 2018 at 12:48 PM Evgeni Dimitrov 
wrote:

> Hi Tim,
>
> As I understand this fix does not change the main design - first create a
> potentially very large list in memory, second update the DB in one single
> transaction. As I understand this fix promises to make the single
> transaction shorter/faster. One needs a big repository to test the fix and
> to compare. My only big repository is the production one. I can not run
> tests on it.
>
> Best regards
> Evgeni
>
>
>
> On Wednesday, August 15, 2018 at 10:17:57 PM UTC+3, Tim Donohue wrote:
>
>> Just a belated follow-up to this thread.  If you are still hitting issues
>> with the Checksum checker in 6.x, I'd recommend looking at the recently
>> logged bug (and proposed fix): https://jira.duraspace.org/browse/DS-3975
>>
>> Here's the proposed fix (which could use some testers to help us verify):
>> https://github.com/DSpace/DSpace/pull/2169   If you install the fix,
>> please report back on your findings by adding a comment to either the
>> GitHub PR or the JIRA ticket.  Reviews & reports back from the community
>> can help us to approve & merge fixes more quickly.
>>
>> Thanks,
>>
>> Tim
>>
>> On Thu, Jul 5, 2018 at 9:20 AM Evgeni Dimitrov 
>> wrote:
>>
> Thank you Mark,
>>>
>>> I am afraid that the checker first tries to update the
>>> most_recent_checksum table comparing with the bitstream table and only
>>> after that it looks at the options (in my case -c 1000).
>>>
>>> Which means that it will always first try to add 500 000 rows to
>>> most_recent_checksum table regardless the options.
>>>
>>>
>>> On Thursday, July 5, 2018 at 4:10:19 PM UTC+3, Mark H. Wood wrote:

 On Thursday, July 5, 2018 at 8:20:28 AM UTC-4, Evgeni Dimitrov wrote:
>
>
> Judging by MostRecentChecksumServiceImpl, first a simple List was
> created in memory with (in this case) 500 000 bitstreams.
>
> Now for every element in this list a row is being added to the
> most_recent_checksum table. Perhaps the transaction will be committed when
> all 500 000 rows are added . . . in two weeks time . . .
>
>
 I believe that you are correct.  There's a very unfortunate collision
 of Java culture (it's easy to create elastic Collections, don't worry about
 the 500 000 members case), ORM (of course you always want all 500 000 rows
 trapped in one transaction until you are done consuming them sequentially),
 and layers of service/DAO/holder, which makes it difficult to do
 large-scale operations efficiently. We may need to augment the storage
 layer with explicit support for bulk operations, such as the ability to
 pass an arbitrary instance of a bulk-operator interface to be applied
 iteratively to each result of a query, so that code which understands the
 storage model can use it well to avoid memory bloat.  The business logic
 layer does not and should not have access to these storage details.  There
 are a number of places in DSpace which might be made less resource-hungry
 by such means.

 Until this changes, you may wish to look over the checksum checker's
 options for limiting the amount of work that it does.  It can be run for a
 given amount of time or over a specific count of bitstreams, for example,
 and continue where it stopped when run again.

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "DSpace Technical Support" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send 

Re: [dspace-tech] Re: Questions about the checksum checker in DSpace 6.2

[Evgeni Dimitrov]

Hi Tim,

As I understand this fix does not change the main design - first create a 
potentially very large list in memory, second update the DB in one single 
transaction. As I understand this fix promises to make the single 
transaction shorter/faster. One needs a big repository to test the fix and 
to compare. My only big repository is the production one. I can not run 
tests on it.

Best regards
Evgeni


On Wednesday, August 15, 2018 at 10:17:57 PM UTC+3, Tim Donohue wrote:
>
> Just a belated follow-up to this thread.  If you are still hitting issues 
> with the Checksum checker in 6.x, I'd recommend looking at the recently 
> logged bug (and proposed fix): https://jira.duraspace.org/browse/DS-3975
>
> Here's the proposed fix (which could use some testers to help us verify): 
> https://github.com/DSpace/DSpace/pull/2169   If you install the fix, 
> please report back on your findings by adding a comment to either the 
> GitHub PR or the JIRA ticket.  Reviews & reports back from the community 
> can help us to approve & merge fixes more quickly.
>
> Thanks,
>
> Tim
>
> On Thu, Jul 5, 2018 at 9:20 AM Evgeni Dimitrov  > wrote:
>
>> Thank you Mark,
>>
>> I am afraid that the checker first tries to update the 
>> most_recent_checksum table comparing with the bitstream table and only 
>> after that it looks at the options (in my case -c 1000).
>>
>> Which means that it will always first try to add 500 000 rows to 
>> most_recent_checksum table regardless the options.
>>
>>
>> On Thursday, July 5, 2018 at 4:10:19 PM UTC+3, Mark H. Wood wrote:
>>>
>>> On Thursday, July 5, 2018 at 8:20:28 AM UTC-4, Evgeni Dimitrov wrote:


 Judging by MostRecentChecksumServiceImpl, first a simple List was 
 created in memory with (in this case) 500 000 bitstreams.

 Now for every element in this list a row is being added to the 
 most_recent_checksum table. Perhaps the transaction will be committed when 
 all 500 000 rows are added . . . in two weeks time . . .


>>> I believe that you are correct.  There's a very unfortunate collision of 
>>> Java culture (it's easy to create elastic Collections, don't worry about 
>>> the 500 000 members case), ORM (of course you always want all 500 000 rows 
>>> trapped in one transaction until you are done consuming them sequentially), 
>>> and layers of service/DAO/holder, which makes it difficult to do 
>>> large-scale operations efficiently. We may need to augment the storage 
>>> layer with explicit support for bulk operations, such as the ability to 
>>> pass an arbitrary instance of a bulk-operator interface to be applied 
>>> iteratively to each result of a query, so that code which understands the 
>>> storage model can use it well to avoid memory bloat.  The business logic 
>>> layer does not and should not have access to these storage details.  There 
>>> are a number of places in DSpace which might be made less resource-hungry 
>>> by such means.
>>>
>>> Until this changes, you may wish to look over the checksum checker's 
>>> options for limiting the amount of work that it does.  It can be run for a 
>>> given amount of time or over a specific count of bitstreams, for example, 
>>> and continue where it stopped when run again.
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "DSpace Technical Support" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to dspace-tech...@googlegroups.com .
>> To post to this group, send email to dspac...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/dspace-tech.
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> Tim Donohue
> Technical Lead for DSpace & DSpaceDirect
> DuraSpace.org | DSpace.org | DSpaceDirect.org
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] Orcid v2

[Tim Donohue]

Hi Shaun,

ORCID v2 integration was fixed in DSpace 5.9 and 6.3.  So, yes, it should
be working in either of those versions.  Here's the ticket that tracked the
fixes:
https://jira.duraspace.org/browse/DS-3447

You can try out ORCID v2 integration on our demo site at:
http://demo.dspace.org (currently running 6.3).  On that site, you can
select either the XMLUI or JSPUI interface.  Demo logins are listed on the
homepage of either the XMLUI or JSPUI.

After logging in, if you submit a new item, the Authors field provides a
"Lookup" button which allows you to search for people (via name) using the
ORCID v2 API.

More information about DSpace ORCID integration is at
https://wiki.duraspace.org/display/DSDOC6x/ORCID+Integration

- Tim



On Thu, Aug 16, 2018 at 6:28 AM Shaun donovan  wrote:

> Hi All.
>
> I have searched for a solution to the Orcid v2 problem, but have not found
> one.
>
> This thread
> https://groups.google.com/forum/#%21topic/dspace-tickets/NUKWQL6gV98
> suggests that in version 6.3 and version 5.9, one should be able to use
> Orcid functionality, but only if one uses the Orcid ID in the lookup field.
> I have installed a clean DSpace 6.3 and have tried to test this
> functionality. The lookup always comes back with "No people found", whether
> I search on Orcid ID or name. Watching the traffic with tcpdump, I can see
> communications with pub.orcid.org, but it is all encrypted.
>
> Is this supposed to be working and I have a configuration error, or is
> this a general problem?
>
> Thanks up front.
>
> Shaun.
>
> --
> All messages to this mailing list should adhere to the DuraSpace Code of
> Conduct: https://duraspace.org/about/policies/code-of-conduct/
> ---
> You received this message because you are subscribed to the Google Groups
> "DSpace Technical Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dspace-tech+unsubscr...@googlegroups.com.
> To post to this group, send email to dspace-tech@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Re: Mirage2 & xmlui "file not found" error

[Juliana Vasconcelos Braga]

Hi Enes!

It worked! 
The Bower version was 1.7.9. 
Thank you so much... :-)

Juliana

Em quinta-feira, 12 de julho de 2018 09:19:39 UTC-3, Sorin Solomon escreveu:
>
> Hi, everyone.
>
> I installed DSpace 6 on Ubuntu 18.04, following the instructions in the 
> wiki .
> All finished successfully, but when I go to [IP Address]:8080/xmlui I get 
> the error message shown in the attached screenshot.
> I searched the Support Forum and I found this issue in the past. 
> I checked, it's not an issue of permissions 
> .
>  
> I also tried to change permissions on the /root folder (like in this 
> article 
> ), 
> same result. I even tried to run mvn -U clean package -Dmirage2.on=true (like 
> shown here 
> ), 
> but the result is the same. 
>
> I'm pretty out of ideas here. Help?
>
> Thank you in advance for your assistance.
>
> Sorin Solomon
>
>
>
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Orcid v2

[Shaun donovan]

Hi All.

I have searched for a solution to the Orcid v2 problem, but have not 
found one.


This thread 
https://groups.google.com/forum/#%21topic/dspace-tickets/NUKWQL6gV98 
suggests that in version 6.3 and version 5.9, one should be able to use 
Orcid functionality, but only if one uses the Orcid ID in the lookup 
field. I have installed a clean DSpace 6.3 and have tried to test this 
functionality. The lookup always comes back with "No people found", 
whether I search on Orcid ID or name. Watching the traffic with tcpdump, 
I can see communications with pub.orcid.org, but it is all encrypted.


Is this supposed to be working and I have a configuration error, or is 
this a general problem?


Thanks up front.

Shaun.

--
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] dspace hidden files

[Claudia Jürgen]

Hello Asanali,

there is per default a access rights   awareness meaning that you will
not see in browse or searchs items that you are not allowed to view.
see
https://wiki.duraspace.org/display/DSDOC6x/Discovery#Discovery-AccessRightsAwareness
Maybe the user has priveliges to view the "missing" files.

Hope that helps

Claudia Jürgen

Am 15.08.2018 um 18:52 schrieb Asanali Msangi:

Hellow tech team, i would like to ask your help, i have installed dspace
6.3 on  ubuntu 16.0.4  is working fine but i have seen litle issue about
file  indexing   before  i logging to the xmlui interface i have 1635 file
after  loging i can see  about 1800 file in my dspace can someone point
me what should i do  to correct that file to be 1800!



--
Claudia Juergen
Eldorado

Technische Universität Dortmund
Universitätsbibliothek
Vogelpothsweg 76
44227 Dortmund

Tel.: +49 231-755 40 43
Fax: +49 231-755 40 32
claudia.juer...@tu-dortmund.de
www.ub.tu-dortmund.de

Wichtiger Hinweis: Die Information in dieser E-Mail ist vertraulich. Sie ist 
ausschließlich für den Adressaten bestimmt. Sollten Sie nicht der für diese 
E-Mail bestimmte Adressat sein, unterrichten Sie bitte den Absender und 
vernichten Sie diese Mail. Vielen Dank.
Unbeschadet der Korrespondenz per E-Mail, sind unsere Erklärungen 
ausschließlich final rechtsverbindlich, wenn sie in herkömmlicher Schriftform 
(mit eigenhändiger Unterschrift) oder durch Übermittlung eines solchen 
Schriftstücks per Telefax erfolgen.

Important note: The information included in this e-mail is confidential. It is 
solely intended for the recipient. If you are not the intended recipient of 
this e-mail please contact the sender and delete this message. Thank you. 
Without prejudice of e-mail correspondence, our statements are only legally 
binding when they are made in the conventional written form (with personal 
signature) or when such documents are sent by fax.

--
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.