Hello Stuart, thanks for response.
Am 02.12.2014 um 19:43 schrieb Stuart Yeates <[email protected]>: >> Although my postgresql is in standard configuration running autovacuum >> regularly, I did a manual vacuum full and a reindex database and reindex >> system for the dspace database yesterday. These jobs finished fast without >> problems. The snippet of the logfile above was recorded after this >> maintainance. > > (a) have you cheaked the operating system logs for evidence of disk > corruption? ('dmesg' in the case of linux) I would not know how exactly this would look in dmesg, however, I found nothing alarming. Here is a short snippet I guess to be relevant. [ 1.788926] sd 2:0:1:0: [sdb] Assuming drive cache: write through [ 1.788996] sd 2:0:1:0: [sdb] Attached SCSI disk [ 1.886328] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) [ 3.839917] Adding 4190204k swap on /dev/mapper/esxh--15-swap_1. Priority:-1 extents:1 across:4190204k [ 3.847649] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 3.854768] udevd[330]: starting version 175 [ 3.891588] lp: driver loaded but no devices found [ 3.906648] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro [ 4.042432] init: portmap-wait (statd) main process (393) killed by TERM signal This is VM-Ware ESX Virtual machine on physical host not under my direct control. I havent ever noticed any resource shortcomings. There is either sufficient disk space, RAM und cpu available. > (b) is postgres configured to be utf-8? The configuration has not changed within at least half a year (tomcat) or two years in case of postgres respectively. Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+-------------+-------------+----------------------- dspace | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 | Meanwhile, I have managed to reproduce the db connection error with this simple command: /srv/dspace> bin/dspace test-database Attempting to connect to database: - URL: jdbc:postgresql://localhost:5432/dspace - Driver: org.postgresql.Driver - Username: dspace - Password: B7c3nEN5 - Schema: null Testing connection... Connected successfully! /srv/dspace# tail -n1 /var/log/postgresql/postgresql-9.1-main.log 2014-12-02 20:38:03 CET LOG: unexpected EOF on client connection Here are the corresponding lines from dspace.log.2014-12-02: 2014-12-02 20:37:54,529 INFO org.dspace.usage.LoggerUsageEventListener @ anonymous:session_id=09A36205C9F2829E4B5B1E8EDAE0DC61:ip_addr=66.249.78.193:view_bitstream:bitstream_id=29870 2014-12-02 20:37:55,340 INFO org.dspace.usage.LoggerUsageEventListener @ anonymous:session_id=CAD1BA058DE25F60C838A52F1A5EAEA8:ip_addr=66.249.78.186:view_item:handle=2339/875 2014-12-02 20:38:00,814 INFO org.dspace.core.ConfigurationManager @ Loading from classloader: file:/srv/dspace/config/dspace.cfg 2014-12-02 20:38:00,832 INFO org.dspace.core.ConfigurationManager @ Using dspace provided log configuration (log.init.config) 2014-12-02 20:38:00,832 INFO org.dspace.core.ConfigurationManager @ Loading: /srv/dspace/config/log4j.properties 2014-12-02 20:38:07,563 INFO org.dspace.usage.LoggerUsageEventListener @ anonymous:session_id=1F75DD2F249867FD40DD717CCE4D118D:ip_addr=157.55.39.94:view_bitstream:bitstream_id=22317 2014-12-02 20:38:10,385 INFO org.dspace.usage.LoggerUsageEventListener @ anonymous:session_id=223CF7F693A11CE3527C5230AB202506:ip_addr=66.249.78.186:view_item:handle=2339/1282 The log4j.properties have been set to DEBUG for the A1 appender. Huge amounts of DEBUG messages are found in the dspace log when issuing something like bin/dspace filter-media or bin/dspace itemcounter. Changing settings in the log4j-console.properties does not have an effect. I also set the cocoon logging settings to DEBUG, but got no useful messages at the same time in the cocoon logfile. I does not make sense to me, that DSpace says everything is fine while the database contemplates a stale connection, abandoned by tomcat. I have checked that the current jdbc connector postgresql-9.1-903.jdbc4.jar is available in /srv/dspace/lib, where /srv/dspace is the working directory of my dspace installation. I have also made sure, that this is the only jdbc connector there. I mention this because there was an elder connector postgresql-8.1-408.jdbc3.jar besides the current connector. I dont know the rules how connectors are matched, but I just wanted to be sure. I checked the same two conditions within each WEB-INF/lib under /var/lib/tomcat7/webapps/*. I restarted completely after cleaning out the old jdbc connector files. I lowered and raised the db.maxconnections setting from 30 to 5 and to 80. I restarted tomcat7 each time and did my test running bin/dspace itemcounter and checking the postgresql logfile afterwords. I had the "unexpected EOF on client connection" messages in the postgresql log regardless of this setting. I did not yet try to change postgres connection settings and I can hardly see this to be meaningful. So, fellow DSpace admins, please help with more suggestions what to check to understand the issue. I cant accept to gather more broken items in our repository with users not even be warned about the fact. Thanks, Christian ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
