Description of problem: Update engine from 3.2 to 3.2.1. Now main reports page and also after login pages are scambled Version-Release number of selected component (if applicable): ovirt-engine-reports-3.2.0-2.fc18.noarch How reproducible: always Steps to Reproduce: 1. connect to reports with engine in 3.2 (f18 + ovirt stable repo) and layout is ok 2. update engine to 3.2.1 3. connect to reports with engine in 3.2.1 (f18 + ovirt stable repo) from the same client Actual results: layout is scrambled Expected results: correct layout as before Additional info: In my case, I have a cluster with two f18 nodes with 3.2 and an f18 engine with 3.2. I updated engine to 3.2.1. # engine-upgrade Checking for updates... (This may take several minutes)...[ ESC[32mDONEESC[0m ] 9 Updates available: * ovirt-engine-3.2.1-1.fc18.noarch * ovirt-engine-tools-3.2.1-1.fc18.noarch * ovirt-engine-backend-3.2.1-1.fc18.noarch * ovirt-engine-dbscripts-3.2.1-1.fc18.noarch * ovirt-engine-genericapi-3.2.1-1.fc18.noarch * ovirt-engine-restapi-3.2.1-1.fc18.noarch * ovirt-engine-setup-3.2.1-1.fc18.noarch * ovirt-engine-userportal-3.2.1-1.fc18.noarch * ovirt-engine-webadmin-portal-3.2.1-1.fc18.noarch Error: New ovirt-engine-setup rpm available via yum. Please execute `yum update ovirt-engine-setup`, then re-execute 'engine-upgrade'. SO # yum update ovirt-engine-setup Loaded plugins: langpacks, presto, refresh-packagekit, versionlock Resolving Dependencies --> Running transaction check ---> Package ovirt-engine-setup.noarch 0:3.2.0-4.fc18 will be updated ---> Package ovirt-engine-setup.noarch 0:3.2.1-1.fc18 will be an update --> Finished Dependency Resolution ... Updated: ovirt-engine-setup.noarch 0:3.2.1-1.fc18 Complete! Then # engine-upgrade ... During the upgrade process, oVirt Engine will not be accessible. All existing running virtual machines will continue but you will not be able to start or stop any new virtual machines during the process. Would you like to proceed? (yes|no): yes Stopping ovirt-engine service... [ ESC[32mDONEESC[0m ] Stopping DB related services... [ ESC[32mDONEESC[0m ] Pre-upgrade validations... [ ESC[32mDONEESC[0m ] Backing Up Database... [ ESC[32mDONEESC[0m ] Rename Database... [ ESC[32mDONEESC[0m ] Updating rpms... [ ESC[32mDONEESC[0m ] Updating Database... [ ESC[32mDONEESC[0m ] Restore Database name... [ ESC[32mDONEESC[0m ] Preparing CA... [ ESC[32mDONEESC[0m ] Running post install configuration... [ ESC[32mDONEESC[0m ] Starting ovirt-engine service... [ ESC[32mDONEESC[0m ] oVirt Engine upgrade completed successfully! * Error: Can't start the ovirt-engine-dwhd service * Upgrade log available at /var/log/ovirt-engine/ovirt-engine-upgrade_2013_03_19_09_27_59.log * Perform the following steps to upgrade the history service or the reporting package: 1. Execute: yum update ovirt-engine-reports* 2. Execute: ovirt-engine-dwh-setup 3. Execute: ovirt-engine-reports-setup * DB Backup available at /var/lib/ovirt-engine/backups/ovirt-engine_db_backup_2013_03_19_09_27_59.sql After this: 1) yum update ovirt-engine-reports* gives nothing to update I presume I still have to run 2) and 3) or not if 1) doesn't catch anything? In anu case: 2) ovirt-engine-dwh-setup # ovirt-engine-dwh-setup Setting DB connectivity... [DONE] Upgrade DB... [DONE ] Starting ovirt-engine... [DONE ] Starting oVirt-ETL... [DONE] Successfully installed ovirt-engine-dwh. The installation log file is available at: /var/log/ovirt-engine/ovirt-engine-dwh-setup-2013_03_19_09_32_22.log 3) # ovirt-engine-reports-setup Welcome to ovirt-engine-reports setup utility Exporting current users... [DONE] Updating Redirect Servlet... [DONE] Importing reports... [DONE] Importing current users... [DONE] Customizing Server... [DONE] Running post setup steps... [DONE] Starting ovirt-engine... [DONE] Succesfully installed ovirt-engine-reports. The installation log file is available at: /var/log/ovirt-engine/ovirt-engine-reports-setup-2013_03_19_09_32_57.log Then update my other f18 packages (comprising the ovirt ones for possible new nodes deploy..) 4) yum update 5) reboot (at 12:16) At first ovirt-engine-dwhd didn't start correctly and then at 12:47 I started it manually and seems to be ok now. See messages: Mar 19 12:16:49 f18engine systemd[1]: Started PostgreSQL database server. Mar 19 12:16:49 f18engine systemd[1]: Starting oVirt Engine... Mar 19 12:16:50 f18engine systemd[1]: Started The Apache HTTP Server. Mar 19 12:16:50 f18engine libvirtd[901]: 2013-03-19 11:16:50.984+0000: 1046: error : virNWFilterSnoopLeaseFileRefresh:1903 : o pen("/var/run/libvirt/network/nwfilter.ltmp"): No such file or directory Mar 19 12:16:52 f18engine chronyd[641]: Selected source 131.175.12.3 Mar 19 12:16:55 f18engine ovirt-engine-dwhd[892]: Starting ovirt-engine-dwhd: at Tue Mar 19 12:16:43 CET 2013[ OK ] Mar 19 12:16:55 f18engine systemd[1]: Started LSB: oVirt Engine History ETL Service for Data Warehouse and Reporting. Mar 19 12:16:56 f18engine kernel: [ 28.759401] Ebtables v2.0 registered Mar 19 12:16:56 f18engine kernel: [ 29.161347] ip6_tables: (C) 2000-2006 Netfilter Core Team Mar 19 12:16:57 f18engine engine-service[1050]: Started engine process 1091. Mar 19 12:16:57 f18engine engine-service[1050]: Starting engine-service: [ OK ] Mar 19 12:16:57 f18engine kernel: [ 30.004260] cgroup: libvirtd (1046) created nested cgroup for controller "memory" which has incomplete hierarchy support. Nested cgroups may change behavior in the future. Mar 19 12:16:57 f18engine kernel: [ 30.004263] cgroup: "memory" requires setting use_hierarchy to 1 on the root. Mar 19 12:16:57 f18engine kernel: [ 30.004306] cgroup: libvirtd (1046) created nested cgroup for controller "devices" which has incomplete hierarchy support. Nested cgroups may change behavior in the future. Mar 19 12:16:57 f18engine kernel: [ 30.004352] cgroup: libvirtd (1046) created nested cgroup for controller "blkio" which has incomplete hierarchy support. Nested cgroups may change behavior in the future. Mar 19 12:16:57 f18engine systemd[1]: Started oVirt Engine. Mar 19 12:16:57 f18engine systemd[1]: Starting Multi-User. Mar 19 12:16:57 f18engine systemd[1]: Reached target Multi-User. Mar 19 12:16:57 f18engine systemd[1]: Starting Update UTMP about System Runlevel Changes... Mar 19 12:16:57 f18engine systemd[1]: Starting Stop Read-Ahead Data Collection 10s After Completed Startup. Mar 19 12:16:57 f18engine systemd[1]: Started Stop Read-Ahead Data Collection 10s After Completed Startup. Mar 19 12:16:58 f18engine systemd[1]: Started Update UTMP about System Runlevel Changes. Mar 19 12:16:58 f18engine systemd[1]: Startup finished in 1s 492ms 639us (kernel) + 2s 488ms 802us (initrd) + 26s 343ms 715us (userspace) = 30s 325ms 156us. Mar 19 12:17:02 f18engine systemd[1]: ovirt-engine-dwhd.service: main process exited, code=exited, status=232/n/a Mar 19 12:17:02 f18engine ovirt-engine-dwhd[1154]: Stopping ovirt-engine-dwhd: [FAILED] Mar 19 12:17:02 f18engine ovirt-engine-dwhd[1154]: oVirt ETL Service is currently not running Mar 19 12:17:02 f18engine systemd[1]: Unit ovirt-engine-dwhd.service entered failed state Mar 19 12:17:07 f18engine systemd[1]: Starting Stop Read-Ahead Data Collection... Mar 19 12:17:07 f18engine systemd[1]: Started Stop Read-Ahead Data Collection. Mar 19 12:27:12 f18engine systemd-logind[612]: New session 1 of user g.cecchi. Mar 19 12:31:27 f18engine systemd[1]: Starting Cleanup of Temporary Directories... Mar 19 12:31:28 f18engine systemd[1]: Started Cleanup of Temporary Directories. Mar 19 12:47:10 f18engine systemd[1]: Starting LSB: oVirt Engine History ETL Service for Data Warehouse and Reporting... Mar 19 12:47:20 f18engine ovirt-engine-dwhd[1797]: Starting ovirt-engine-dwhd: at Tue Mar 19 12:47:10 CET 2013[ OK ] Mar 19 12:47:20 f18engine systemd[1]: Started LSB: oVirt Engine History ETL Service for Data Warehouse and Reporting. # systemctl status ovirt-engine-dwhd ovirt-engine-dwhd.service - LSB: oVirt Engine History ETL Service for Data Warehouse and Reporting Loaded: loaded (/etc/rc.d/init.d/ovirt-engine-dwhd) Active: active (running) since Tue 2013-03-19 12:47:20 CET; 13s ago Process: 1154 ExecStop=/etc/rc.d/init.d/ovirt-engine-dwhd stop (code=exited, status=0/SUCCESS) Process: 1797 ExecStart=/etc/rc.d/init.d/ovirt-engine-dwhd start (code=exited, status=0/SUCCESS) Main PID: 1805 (java) CGroup: name=systemd:/system/ovirt-engine-dwhd.service └─1805 /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java -Xms256M -Xmx1024M -Djavax.net... Mar 19 12:47:10 f18engine systemd[1]: Starting LSB: oVirt Engine History ETL Service...... Mar 19 12:47:10 f18engine runuser[1802]: pam_unix(runuser:session): session opened fo...0) Mar 19 12:47:10 f18engine runuser[1802]: pam_unix(runuser:session): session closed fo...ot Mar 19 12:47:20 f18engine ovirt-engine-dwhd[1797]: Starting ovirt-engine-dwhd: at Tue ...] Mar 19 12:47:20 f18engine systemd[1]: Started LSB: oVirt Engine History ETL Service ...ng. Right before update, connecting from a pc with chrome returned correct reports gui. As soon I started again, after update, the same client gets scrambled reports output, as I already posted in the first e-mail of this thread. I get the same also in an all-in-one fedora 18 installation where I didn't run the two steps ( 2. Execute: ovirt-engine-dwh-setup 3. Execute: ovirt-engine-reports-setup ) Tried from firefox 19, chrome 25, ie 8 and all give the same scramble, while before all were working. Gianluca
Did you try to clean the tmp folder? the jboss work folder? Yaniv
Can you explain what to check? I find [root@f18engine jboss-as]# ll /var/tmp/ovirt-engine total 36 drwx------. 2 ovirt ovirt 4096 Mar 19 12:17 auth drwxr-xr-x. 4 ovirt ovirt 4096 Mar 19 12:17 engine-service_history -rw-r--r--. 1 ovirt ovirt 440 Mar 19 12:16 engine-service-logging.properties -rw-r--r--. 1 ovirt ovirt 11054 Mar 19 12:18 engine-service.xml drwxr-xr-x. 13 root root 4096 Mar 19 12:16 modules drwxr-xr-x. 4 ovirt ovirt 4096 Mar 19 12:17 vfs drwxr-xr-x. 3 ovirt ovirt 4096 Mar 19 12:17 work [root@f18engine jboss-as]# ll /var/tmp/ovirt-engine/work/jboss.web/default-host/ total 24 drwxr-xr-x. 2 ovirt ovirt 4096 Mar 19 12:17 _ drwxr-xr-x. 2 ovirt ovirt 4096 Mar 19 12:17 api drwxr-xr-x. 3 ovirt ovirt 4096 Mar 19 12:29 ovirt-engine-reports drwxr-xr-x. 2 ovirt ovirt 4096 Mar 19 12:17 OvirtEngineWeb drwxr-xr-x. 2 ovirt ovirt 4096 Mar 19 12:17 UserPortal drwxr-xr-x. 2 ovirt ovirt 4096 Mar 19 12:17 webadmin what to operationally do? I can stop ovirt-engine service if required If you refer instead to engine /tmp directory it is a fedora 18 system and /tmp is in memory so every reboot is lost Gianluca
I mean clearing the jboss work directory and /tmp directory and restarting the jboss. Yaniv
"work" path to check for JBoss 7 (it changed a lot between 5, 6 and 7 versions...)? Thanks BTW: if after testing it results that this is the reason, can we track this bugzilla and in case of acceptance, implement into reports? https://bugzilla.redhat.com/show_bug.cgi?id=901061
http://stackoverflow.com/questions/9851652/jboss-as-7-how-to-clean-up-tmp Yaniv
I already found that link and also this one: http://www.mastertheboss.com/jboss-configuration/jboss-as-storage-hints that I think is useful to compare JBoss 5 and 7. Still I don't understand correctly how to map these info with ovirt-engine + ovirt-reports installation... and if I have to clean overall or only specifically to reports.... Why is it so difficult give direct operations/paths as we are not talking about JBoss implementation in general but this particular one?
Finally I found it. So recap: my engine is on fedora 18 so: - /tmp/ is mounted as tmpfs [g.cecchi@tekkaman ovirt-engine]$ mount | grep /tmp tmpfs on /tmp type tmpfs (rw,seclabel) - work is under /var/tmp and I noticed this: after system started and ovirt-engine and ovirt-engine-dwhd services started [root@tekkaman tmp]# systemctl status ovirt-engine ovirt-engine.service - oVirt Engine Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; enabled) Active: active (running) since Wed 2013-03-20 23:56:06 CET; 2min 21s ago Process: 8089 ExecStop=/usr/bin/engine-service stop (code=exited, status=0/SUCCESS) Process: 8200 ExecStart=/usr/bin/engine-service start (code=exited, status=0/SUCCESS) Main PID: 8201 (java) CGroup: name=systemd:/system/ovirt-engine.service └─8201 engine-service -server -XX:+TieredCompilation -Xms1g -Xmx1g -XX:PermSize=256m -XX:MaxPermSize=256... Mar 20 23:56:06 tekkaman.localdomain.local engine-service[8200]: Started engine process 8201. Mar 20 23:56:06 tekkaman.localdomain.local engine-service[8200]: Starting engine-service: [ OK ] Mar 20 23:56:06 tekkaman.localdomain.local systemd[1]: Started oVirt Engine. [root@tekkaman tmp]# systemctl status ovirt-engine-dwhd ovirt-engine-dwhd.service - LSB: oVirt Engine History ETL Service for Data Warehouse and Reporting Loaded: loaded (/etc/rc.d/init.d/ovirt-engine-dwhd) Active: active (running) since Wed 2013-03-20 23:58:45 CET; 5s ago Process: 8547 ExecStart=/etc/rc.d/init.d/ovirt-engine-dwhd start (code=exited, status=0/SUCCESS) Main PID: 8555 (java) CGroup: name=systemd:/system/ovirt-engine-dwhd.service └─8555 /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java -Xms256M -Xmx1024M -Djavax.net.ssl.trustStore=/etc... Mar 20 23:58:35 tekkaman.localdomain.local systemd[1]: Starting LSB: oVirt Engine History ETL Service for Data Warehou...g... Mar 20 23:58:35 tekkaman.localdomain.local runuser[8552]: pam_unix(runuser:session): session opened for user root by (uid=0) Mar 20 23:58:35 tekkaman.localdomain.local runuser[8552]: pam_unix(runuser:session): session closed for user root Mar 20 23:58:45 tekkaman.localdomain.local ovirt-engine-dwhd[8547]: Starting ovirt-engine-dwhd: at Wed Mar 20 23:58:35 ... ] Mar 20 23:58:45 tekkaman.localdomain.local systemd[1]: Started LSB: oVirt Engine History ETL Service for Data Warehous...ing. [root@tekkaman tmp]# pwd /var/tmp [root@tekkaman tmp]# ll -d ovirt-engine/ drwxr-xr-x. 7 ovirt ovirt 4096 Mar 20 23:56 ovirt-engine/ [root@tekkaman tmp]# ll ovirt-engine/ total 36 drwx------. 2 ovirt ovirt 4096 Mar 20 23:56 auth drwxr-xr-x. 4 ovirt ovirt 4096 Mar 20 23:56 engine-service_history -rw-r--r--. 1 ovirt ovirt 440 Mar 20 23:56 engine-service-logging.properties -rw-r--r--. 1 ovirt ovirt 11054 Mar 20 23:56 engine-service.xml drwxr-xr-x. 13 root root 4096 Mar 20 23:56 modules drwxr-xr-x. 4 ovirt ovirt 4096 Mar 20 23:56 vfs drwxr-xr-x. 3 ovirt ovirt 4096 Mar 20 23:56 work If I stop the services [root@tekkaman tmp]# systemctl stop ovirt-engine-dwhd [root@tekkaman tmp]# systemctl stop ovirt-engine [root@tekkaman tmp]# pwd /var/tmp [root@tekkaman tmp]# ll -d ovirt-engine ls: cannot access ovirt-engine: No such file or directory So there is already an autoclean of all the directories, without any user manual intervention - after a new start they are recreated but my web layotu is still scrmabled. So it is not a problem related with /tmp or JBoss work dir
Can you please recreate on another machine? I don't see any reason for this to happen otherwise then a faulty installation or a db correption. Yaniv
I have reproduced in two different environments. One with an all-in-one on fedora 18 The other with an f18 engine + 2 fedora 18 hosts configured as nodes. I also have a third environment where I can verify. The problem happens when passing from ovirt-engine-*-3.2.0-4.fc18.noarch ovirt-engine-dwh-3.2.0-1.fc18.noarch ovirt-engine-reports-3.2.0-2.fc18.noarch to ovirt-engine-*-3.2.1-1.fc18.noarch while remaining at the same version for reports and dwh the same at least for another user that complained on the user mailing list: http://lists.ovirt.org/pipermail/users/2013-March/013342.html http://lists.ovirt.org/pipermail/users/2013-March/013376.html
Juan, any clue as to what might cause this? Yaniv
I don't really understand why it fails, but I see that when the browser requests any of the .css files it gets as result a long sequence of hex characters instead of the expected CSS code. For example, if I try the following URL: https://whatever/ovirt-engine-reports/_themes/7210329C/theme.css I get something like this: F2a0a202a2046726f... Approx 29 KiB of that, in just one line. Looks like some kind of encoding, but I can tell exactly what. The headers of the response don't help either, as it is mostly empty, it doesn't even include the content type. I would like to check if the content is wrong, but it looks like those URLs are served by a servlet, so I don't really know where to look.
same thing here [root@ovirt ovirt-engine]# rpm -qa | grep ovirt ovirt-log-collector-3.2.0-1.fc18.noarch ovirt-engine-3.2.1-1.fc18.noarch ovirt-engine-dbscripts-3.2.1-1.fc18.noarch ovirt-engine-userportal-3.2.1-1.fc18.noarch ovirt-engine-genericapi-3.2.1-1.fc18.noarch ovirt-engine-reports-3.2.0-2.fc18.noarch ovirt-engine-cli-3.2.0.10-1.fc18.noarch ovirt-image-uploader-3.2.0-1.fc18.noarch ovirt-host-deploy-java-1.0.0-1.fc18.noarch ovirt-engine-dwh-3.2.0-1.fc18.noarch ovirt-engine-backend-3.2.1-1.fc18.noarch ovirt-engine-tools-3.2.1-1.fc18.noarch ovirt-engine-sdk-3.2.0.9-1.fc18.noarch ovirt-host-deploy-1.0.0-1.fc18.noarch ovirt-release-fedora-5-3.noarch ovirt-engine-restapi-3.2.1-1.fc18.noarch ovirt-iso-uploader-3.2.0-1.fc18.noarch ovirt-engine-setup-3.2.1-1.fc18.noarch ovirt-engine-webadmin-portal-3.2.1-1.fc18.noarch Don't know if it helps, but in /var/log/ovirt-engine/server.log I'm getting this when trying to view any report which shows jasperreports server not being able to parse xml in JRXmlLoader <<< cut long list of spring wiring >>> 2013-03-25 09:40:38,227 INFO [org.springframework.beans.factory.xml.XmlBeanFactory] (ajp--127.0.0.1-8702-11) Overriding bean definition for bean 'ganttType': replacing [Generic bean: class [org.springframework.beans.factory.config.FieldRetrievingFactoryBean]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null] with [Generic bean: class [org.springframework.beans.factory.config.FieldRetrievingFactoryBean]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null] 2013-03-25 09:40:38,758 ERROR [org.apache.commons.digester.Digester] (ajp--127.0.0.1-8702-11) Parse Fatal Error at line 1 column 1: Content is not allowed in prolog.: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Content is not allowed in prolog. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) [xercesImpl-2.7.1.jar:] at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) [xercesImpl-2.7.1.jar:] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) [xercesImpl-2.7.1.jar:] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) [xercesImpl-2.7.1.jar:] at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source) [xercesImpl-2.7.1.jar:] at org.apache.xerces.impl.XMLDocumentScannerImpl$PrologDispatcher.dispatch(Unknown Source) [xercesImpl-2.7.1.jar:] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) [xercesImpl-2.7.1.jar:] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) [xercesImpl-2.7.1.jar:] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) [xercesImpl-2.7.1.jar:] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) [xercesImpl-2.7.1.jar:] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) [xercesImpl-2.7.1.jar:] at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) [xercesImpl-2.7.1.jar:] at org.apache.commons.digester.Digester.parse(Digester.java:1647) [commons-digester-1.7.jar:1.7] at net.sf.jasperreports.engine.xml.JRXmlLoader.loadXML(JRXmlLoader.java:243) [jasperreports-4.7.0.jar:4.7.0] at net.sf.jasperreports.engine.xml.JRXmlLoader.loadXML(JRXmlLoader.java:230) [jasperreports-4.7.0.jar:4.7.0] at net.sf.jasperreports.engine.xml.JRXmlLoader.load(JRXmlLoader.java:218) [jasperreports-4.7.0.jar:4.7.0] at com.jaspersoft.jasperserver.api.engine.jasperreports.service.impl.EngineServiceImpl.loadReportDesign(EngineServiceImpl.java:1688) [jasperserver-api-engine-impl-4.7.0.jar:] at com.jaspersoft.jasperserver.api.engine.jasperreports.service.impl.EngineServiceImpl.compileReport(EngineServiceImpl.java:2305) [jasperserver-api-engine-impl-4.7.0.jar:] at com.jaspersoft.jasperserver.api.engine.jasperreports.service.impl.CacheableCompiledReports.getData(CacheableCompiledReports.java:58) [jasperserver-api-engine-impl-4.7.0.jar:] at com.jaspersoft.jasperserver.api.metadata.common.service.impl.hibernate.HibernateRepositoryCache.saveData(HibernateRepositoryCache.java:274) [jasperserver-api-metadata-impl-4.7.0.jar:] at com.jaspersoft.jasperserver.api.metadata.common.service.impl.hibernate.HibernateRepositoryCache.getCachedItem(HibernateRepositoryCache.java:141) [jasperserver-api-metadata-impl-4.7.0.jar:] at com.jaspersoft.jasperserver.api.metadata.common.service.impl.hibernate.HibernateRepositoryCache.cache(HibernateRepositoryCache.java:90) [jasperserver-api-metadata-impl-4.7.0.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09-icedtea] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09-icedtea] at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09-icedtea]
My problems seem to be caused by the handling of the data column, a bytea type, in jifileresource where the css and jrxml are stored in jasper reports. I changed the postgres config and added bytea_output = escape and reports appear to be working again. http://jaspersoft.com/questions/538234/bad-storage-format-themes-css-postgres-metadatabase-js-4 was where I got the hint. postgres versions ares [root@ovirt backup]# rpm -qa | grep postgres postgresql-jdbc-9.2.1002-1.fc18.noarch postgresql-server-9.2.3-1.fc18.x86_64 postgresql-contrib-9.2.3-1.fc18.x86_64 postgresql-9.2.3-1.fc18.x86_64 postgresql-libs-9.2.3-1.fc18.x86_64
John, you are right, this is the problem. We can solve it changing that parameter in the postgres configuration or updating the JDBC driver to a newer version that understands the new output of bytea. I think that the latter is better, and in fact has already been updated in the master branch in the following changes: http://gerrit.ovirt.org/11310 http://gerrit.ovirt.org/12790 I am backporting both to the 3.2 branch, so once they are reviewed and merged they should be included in the next build from that branch. These are the changes: http://gerrit.ovirt.org/13549 http://gerrit.ovirt.org/13550 Meanwhile, to solve the issue, you can download the updated driver manually and copy it to /usr/share/ovirt-engine/modules/org/postgresql/main/postgresql.jar: # wget http://jdbc.postgresql.org/download/postgresql-9.2-1002.jdbc4.jar -O /usr/share/ovirt-engine/modules/org/postgresql/main/postgresql.jar Check that it is correctly installed: # java -cp /usr/share/ovirt-engine/modules/org/postgresql/main/postgresql.jar org.postgresql.util.PSQLDriverVersion PostgreSQL 9.2 JDBC4 (build 1002) Found in: jar:file:/usr/share/ovirt-engine/modules/org/postgresql/main/postgresql.jar!/org/postgresql/Driver.class Then restart the engine: # systemctl restart ovirt-engine
Finally! I confirm that in my setup (3.2.1) after downloading PostgreSQL 9.2 JDBC4 (build 1002) and restarting ovirt-engine and ovirt-engine-dwhd services, report main page and also the following ones are now ok. Tested in: - Chrome 25.0.1364.172 on Fedora 17 - ie 9 on windows 7 32bit Thanks, Gianluca
juan - was this fixed for 3.2.2 and can be closed?
It has been fixed in the engine_3.2 branch. I assume that 3.2.2 will include it, so it can be moved to closed once 3.2.2 is released.