Anybody having a similar experience, the time is not regular, but I have 2 instances, that both crash with a "regular" interval, and it is always with some stacktrace like:
at java.lang.Thread.run(Unknown Source) UIDefaults.getUI() failed: no ComponentUI class for: com.jxcell.HB[,0,0,0x0,inva lid,alignmentX=0.0,alignmentY=0.0,border=,flags=4194304,maximumSize=,minimumSize =,preferredSize=,blockIncrement=10,orientation=VERTICAL,unitIncrement=1] java.lang.Error at javax.swing.UIDefaults.getUIError(Unknown Source) at javax.swing.MultiUIDefaults.getUIError(Unknown Source) at javax.swing.UIDefaults.getUI(Unknown Source) at javax.swing.UIManager.getUI(Unknown Source) at javax.swing.JScrollBar.updateUI(Unknown Source) at javax.swing.JScrollBar.<init>(Unknown Source) at javax.swing.JScrollBar.<init>(Unknown Source) at com.jxcell.HB.<init>(EYFN) at com.jxcell.Adapter_2_0.createScrollbar(EYFN) at com.jxcell.mvc.Viewview.<init>(EYFN) at com.jxcell.ssView.<init>(EYFN) at com.jxcell.View.append(EYFN) at com.jxcell.View.<init>(EYFN) at com.jxcell.View.<init>(EYFN) at com.benryan.conversion.SpreadsheetConverter.convert(SpreadsheetConver ter.java:476) at com.benryan.conversion.XlsConverter$1.doConversion(XlsConverter.java: 45) at com.benryan.conversion.DocConverter.execute(DocConverter.java:61) at com.benryan.conversion.macro.ConverterMacro.execute(ConverterMacro.ja va:250)
For one Instance, Atlassian has been looking into some GC logging, and Hercules came with some advises and I do suspect 99,9% some Microsoft Office / Excel integration to cause the issue, the stacktrace includes "com.benryan.conversion.SpreadsheetConverter.convert(Spreadshee....")
Even this should not be an 4.X issue....
BTW: None of the instances crashed at release 3.5
This is an old case, and the problem was not in the Office (I think), making some changes to JAVA_OPTS seemed to help alot:
JAVA_OPTS="-Xms2048m -Xmx2048m -XX:MaxPermSize=512m $JAVA_OPTS -Djava.awt.headless=true -Dcom.sun.management.jmxremote=true -Dnetic.rmi.agent.port=18080 -javaagent:/pack/jmx/JMXAgent.jar -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.access.file=/pack/jmx/jmxremote.access -Dcom.sun.management.jmxremote.password.file=/pack/jmx/jmxremote.password -verbose:gc -Xloggc:/pack/confluence/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:NewSize=384m -XX:+UseParallelOldGC -Dsun.rmi.dgc.client.gcInterval=900000 -Dsun.rmi.dgc.server.gcInterval=900000 -XX:+DisableExplicitGC"
Notice the XX:+UseParallelOldGC and -XX:+DisableExplicitGC flags. Ignore the JMX
Hi Normann,
It seems that you're hitting the when field has currency format in your view macro. For more information please refer to the following bug report.
* https://jira.atlassian.com/browse/CONF-20631
Feel free to add your comments to the discussion, vote on it and add yourself as a watcher for future updates. Also, please bear in mind the following document on how Atlassian development team approach bug fixing.
From the bug report, it seems that this issue is not resolved and some user actually post some workaround on the bug report, and it seems weird if it's not an issue in Confluence 3.5.x. If the workaround is not feasible I personally believe it will be handled better on our Support Channel.
Hope this information helps, and if there's anything unclear or needs clarification please ask.
Best regards,
Josua
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That could be right, but the problem never occoured before version 4.X . The workaound is not feasible, as its a costumers instance.
And I am using the Support Channel also :-) This is merely a cry out to "asses" how common the issue is, as many must have upgraded to v4 by now..
But thanx for the reply :-)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I see. From what I see in bug report, it seems that the issue is solved in Confluence 4.2. Perhaps you can keep in view in upgrading to Confluence 4.2. Chhers :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I see, thanks for letting us know on that. From what I see in bug report, it seems that this bug is fixed in Confluence 4.2 which will be released soon. Perhaps you can keep it in view to upgrade your Confluence once that version is released. Cheers! :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Resurrecting another old thread; changing the format of the Excel file from XLSX to XLS is often all you need to do.
XLSX does some funky things which results in super high memory usage. In later versions of Confluence we've restricted XLSX file sizes to 2mb, but XLS files are generally ok.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This is an old case, and the problem was not in the Office (I think), making some changes to JAVA_OPTS seemed to help alot:
JAVA_OPTS="-Xms2048m -Xmx2048m -XX:MaxPermSize=512m $JAVA_OPTS -Djava.awt.headless=true -Dcom.sun.management.jmxremote=true -Dnetic.rmi.agent.port=18080 -javaagent:/pack/jmx/JMXAgent.jar -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.access.file=/pack/jmx/jmxremote.access -Dcom.sun.management.jmxremote.password.file=/pack/jmx/jmxremote.password -verbose:gc -Xloggc:/pack/confluence/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:NewSize=384m -XX:+UseParallelOldGC -Dsun.rmi.dgc.client.gcInterval=900000 -Dsun.rmi.dgc.server.gcInterval=900000 -XX:+DisableExplicitGC"
Notice the XX:+UseParallelOldGC and -XX:+DisableExplicitGC flags. Ignore the JMX
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
As is usually the case the best advice is to upgrade if possible. I have had no problems for months after upgrading to 4.2.5 - Office connector included.
It may be worth investigating the "DB connections reach it's peak" - may be that someone is running a huge query?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We have been running through a similar issue with a little difference that it will not crash but gets frozen and the DB connections reach it's peak .
Atlassian support has been looking into the issue and so far they could not identify a single reason for this frequent freeze.
Though we have set a very high bar on the memory allocation, the issue still appears. With my analysis so far, either someone is trying to view a large excel in confluence or something related to office connector plugin.
I have tried disabling the {viewxls} macro and still the errors continue to appear in the log while the confluence is still up and running for the last two days now atleast. Knock on the wood !
See if that helps in your case.
FYI : The latest update on https://jira.atlassian.com/browse/CONF-20631 says that bug is not known to crash confluence.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Normann,
We are encountering the same issue (on 3.5.13). When you did your analysis, did you see specific log messages pointing to OOM or other issues ?
Francis
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
We did a lot of debugging with atlassian, and ended with this for setenv.sh:
JAVA_OPTS="-Xms2048m -Xmx2048m -XX:MaxPermSize=512m $JAVA_OPTS -Djava.awt.headless=true -verbose:gc -Xloggc:/pack/confluence/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:NewSize=700m -XX:+UseParallelGC -Dsun.rmi.dgc.client.gcInterval=900000 -Dsun.rmi.dgc.server.gcInterval=900000 -XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/backup/hdump -javaagent:/pack/confluence/jmx/JMXAgent.jar -Dnetic.rmi.agent.port=18080 -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.access.file=/pack/confluence/jmx/jmxremote.access -Dcom.sun.management.jmxremote.password.file=/pack/confluence/jmx/jmxremote.password"
Also, number of DB connections was raised from 30 to 60.
Seems that Confluence need a ridiculous amount of memory for a medium size installation and that GC sucks....
There alot of debugging and jmx in the above You can leave out.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
I dont think the problem I faced was the one above, but memory issue, we have debugged a lot (with Atlassian) and ended up with 2 issues:
1. Memory - the setenv.sh is currently:
JAVA_OPTS="-Xms2048m -Xmx2048m -XX:MaxPermSize=512m $JAVA_OPTS -Djava.awt.headless=true -verbose:gc -Xloggc:/pack/confluence/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:NewSize=700m -XX:+UseParallelGC -Dsun.rmi.dgc.client.gcInterval=900000 -Dsun.rmi.dgc.server.gcInterval=900000 -XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/backup/hdump -javaagent:/pack/confluence/jmx/JMXAgent.jar -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.access.file=/pack/confluence/jmx/jmxremote.access -Dcom.sun.management.jmxremote.password.file=/pack/confluence/jmx/jmxremote.password"
export JAVA_OPTS
2. Max MySQL Database connections raised from 30 default to 50
Try something like those - especially the -XX:MaxPermSize=512m and XX:NewSize=700m is an issue.
And it seems to have helped. I am a bid disapointed that the settings we used for a long time on 3.5 failed so severely, and that we had to push Atlassian support quite a bit, there very slow...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I have the same thing with 3,5,13 straight after startup and I think it is resposible for dropouts every few days.
UIDefaults.getUI() failed: no ComponentUI class for: com.jxcell etc
Nice to know that this is fixed in 4,2,2 - it is just a shame that I cannot upgrade due to the lack of plugin readiness :(
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.