Difference between revisions of "ESciDoc Committer Meeting 2010-11-30"
Jump to navigation
Jump to search
m (→others) |
|||
| Line 14: | Line 14: | ||
'''Next committer meetings''' | '''Next committer meetings''' | ||
*[[ESciDoc_Committer_Meeting_2010-12- | *[[ESciDoc_Committer_Meeting_2010-12-14]] | ||
*[[ESciDoc_Committer_Meeting_2010-12-21]] to be scheduled on 14th of Dezember | |||
=Topics= | =Topics= | ||
Latest revision as of 10:28, 1 December 2010
Date: 30.11.2010 Start time: 14:30 End time: 15:30
Location: Karlsruhe, München phone: +49-89-38602-223 VidCo-ISDN: 08938602595; alternate ip 192.129.1.132
Participants MPDL: Natasa Bulatovic, Wilhelm Frank
Participants FIZ: Steffen Wagner, Frank Schwichtenberg, Michael Hoppe, Harald Kappus
Previous committer meeting
Next committer meetings
- ESciDoc_Committer_Meeting_2010-12-14
- ESciDoc_Committer_Meeting_2010-12-21 to be scheduled on 14th of Dezember
Topics[edit]
next meetings[edit]
- 07.12.10 skip
- 14.12.10 ok
- 21.12.10 ok, open
postgres connections[edit]
- since core service 1.2 deployment and the postgres connections, we have had experienced quite unusual memory consumption of postgres. From ca. 10 connections to the database, one of these connections consumes enourmous RAM and is never set free (4-6 GB). The same behavior is on all servers, even those which are simply set as default and have no midnight fetching of data.
- Note that this process is not the postmaster process itself, but is the escidoc-core connection process to escidoc-core database.Our servers start to consume after a while a lot of swap and then after some time the system stops functioning.The total memory of the server where this is really critical is 32 GB, where postgres database itself uses only 1/4 of it.
- Can you please investigate a bit or let us know if you have some ideas how to monitor this problem?
Outcome[edit]
- will be investigated
OU[edit]
- What has to be done when a OU "A" gets a Successor A´?
- will the children of A still be children of A´
- what to do
- if A will be split into A´ and A´´
- if A and B are joined to C
- what happens with the parents?
Outcome[edit]
- no changes shall be made automatically to children or parents in case of Successor relations
PID[edit]
Will be postponed to next week since no final solution could be defined
- component - content update for components of released items associated with a PID
- A Component PID should be treated like an "object PID"
- that is the understood, the question is how to provide a valid component "object PID" into each item version
- is the versioning of component content a choice of application developers in this case
On Behalf-of deposit[edit]
- discussed already before, to check it again
- see also new features for v2.0
- outcome: no decission taken for content of next release
Release timelines[edit]
- PID bug fix
others[edit]
- eSciDoc-Colab Page setup
- installation guides
- scalability/load tests environment setup
- outcome: will be checked within the FIZ team