running a Jenkins server with the embedded Jetty, I get errors regarding too big headers in the Jenkins log:
Feb 15, 2017 3:18:15 PM org.eclipse.jetty.util.log.JavaUtilLog warn
WARNING: header full: java.lang.ArrayIndexOutOfBoundsException: 8192
I'd like to increase the Jetty max header size but can't find how to do it, in the case of a Jenkins... I can't find any Jetty config file and don't know if I can set the limit on the Jenkins command line (and what would be the name of the variable to define).
How to achieve this?
If using the built-in Jetty found in the self-running jenkins.war, you cannot adjust that value.
You can only adjust the maximum number of parameters.
--maxParamCount=N = set the max number of parameters allowed in a form submission to protect
against hash DoS attack (oCERT #2011-003). Default is 10000.
Either deploy the war to a full blown container which you can then adjust the value, or change how you use Jenkins to not send excessive URI or HTTP headers (such as using POST vs GET).
To adjust the Jetty 9 header buffer maximum size, you'd adjust the requestHeaderSize in the HttpConfiguration for the ServerConnector that you want that new setting to exist in.
Add this parameter to jenkins config:
JENKINS_ARGS="--requestHeaderSize=258140"
Related
I need to display the date and time of actual log info within the tomcat8-stdout log file for my tomcat 8.5 installation, I found one solution of adding this line to the logging.properties file, but it didn't work, the following is what i added to logging.properties:
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
java.util.logging.ConsoleHandler.encoding = UTF-8
java.util.logging.SimpleFormatter.format=%1$tF %1$tT [%4$-7s] %5$s %n
(My actual logging file without the line spacing)
Right now it’s just a bunch of data that has without timestamps. I just wanted the standard yyyymmdd hhmmss that precedes the INFO or ERROR, etc in stdout log output.
My Tomcat setup is running on Java 8 and Tomcat is starting using windows services.
Any help provided to solve this issue will be appreciated and thank you in advance.
We were building our solution without any "Pipeline" in Jenkins until recently, so I'm currently in the progress to move our build to multibranch pipelines.
The issue that I'm running into is that we have a lot of structure une our solution(lot of subfolder, and sometimes some big names).
Currently, the jenkins pipeline extract everything in a folder that looks like:
D:\ws\ght-build_feature_pipelines-TMQ33LB5OQIQ5VXVMFKFDG2HWCD4MUOGEGUWJUOMZ5D2GI42BIQA
Which is very-long, and now we are reaching the 260 characters limit of MSBuild:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2991,5):
error MSB3553: Resource file
"obj\Release\xx.aaaaaaaaaa.yyy.bbbbbb.dddddddddddddd.yyyyyyy.vvv.dddddddddd.Resources.resources"
has an invalid name. The item metadata "%(FullPath)" cannot be applied
to the path
"obj\Release\xx.aaaaaaaaaa.yyy.bbbbbb.dddddddddddddd.yyyyyyy.vvv.dddddddddd.Resources.resources".
The specified path, file name, or both are too long. The fully
qualified file name must be less than 260 characters, and the
directory name must be less than 248 characters.
[D:\ws\ght-build_feature_pipelines-TMQ33LB5OQIQ5VXVMFKFDG2HWCD4MUOGEGUWJUOMZ5D2GI42BIQA\Src\bbbbbb\dddddd\dddddddddddddd\yyyyyyy\xx.aaaaaaaaaa.yyy.bbbbbb.dddddddddddddd.yyyyyyy.vvv\xx.aaaaaaaaaa.yyy.bbbbbb.dddddddddddddd.yyyyyyy.vvv.csproj]
We have so much cases where the length is big that it's really a big job to refactor everything, so I'm looking on how to specify to jenkins a smaller path?
What I finally did:
pipeline {
agent {
node{
label 'windows-node'
customWorkspace "D:\\ws\\${env.BRANCH_NAME}"
}
}
options{
skipDefaultCheckout()
}
...
}
And I've a step that does the checkout. It was easier for me to have a "per-job" behavior, without touching jenkins global settings.
Update (for any recent Jenkins instances)
Turns out that with recent Jenkins versions PATH_MAX seems to be ignored.
The only thing it does: Issue a warning in the Jenkins log when smaller than a certain value, which actually does not matter - as the setting itself will anyways be ignored (as seen on Jenkins 2.249.3). See also: JENKINS-2111
As far as I can tell - the new setting was introduced in jenkins-branch-api 2.0.21:
There's a new property introduced: MAX_LENGTH.
This defaults to 32 characters by default.
You can set it the same way like PATH_MAX:
As a java property - to ensure that Jenkins will start using the right setting, e.g.:
-Djenkins.branch.WorkspaceLocatorImpl.MAX_LENGTH=40
or during run-time, using the script console:
jenkins.branch.WorkspaceLocatorImpl.MAX_LENGTH=40
For older Jenkins instances
Actually there's a java property you can set to specify the length of the directory name, e.g.:
-Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=20
To make it permanent you have to specify this property in the Jenkins java startup configuration file.
You may also read and write this property using the Jenkins script console for temporary changes or to just give it a try as it takes effect immediately, e.g.
println jenkins.branch.WorkspaceLocatorImpl.PATH_MAX
jenkins.branch.WorkspaceLocatorImpl.PATH_MAX = 20
println jenkins.branch.WorkspaceLocatorImpl.PATH_MAX
Setting this value to 0 changes the path generation behavior.
For details please check:
https://issues.jenkins-ci.org/browse/JENKINS-34564
https://issues.jenkins-ci.org/browse/JENKINS-38706
We're using uWSGI in Emperor mode. We want to be able to track the default (non-custom) metrics like worker.0.requests, and we're trying to use the metrics-dir configuration parameter in the vassals' ini files. For example:
enable-metrics = true
metrics-dir = /tmp/pametrics
Files are being written to the directory we specify, and their timestamps are being updated each time we hit the app being served by the vassal, but they are all 4096 bytes long and full of zero bytes; they are not text files as the documentation says.
What are we missing?
They are memory mapped files so their size is the same of a memory page.
Being 0 terminated, you can use the classic unix utilities to manage them
I am getting out of memory errors when doing compile time weaving. As you can see, I have already set the Xmx (via maxmem) to 1024m. This could be due to the jar I am trying to weave is ~70MB.
How do I set the Garbage Collector? I tried using the X param but when I connect to the process with JConsole the ConcMarkSweep is not set.
<echo message="Weaving..."/>
<aspectj:iajc classpathref="compile.libs" aspectpath="${src.dir}" outJar="${output.jar}" fork="true" maxmem="1024m" X="+UseConcMarkSweepGC">
<inpath>
<pathelement path="${classes.dir}"/>
</inpath>
</aspectj:iajc>
The error is:
Bugs for exceptions thrown have titles File:line from the top stack,
e.g., "SomeFile.java:243"
If you don't find the exception below in a bug, please add a new bug
at http://bugs.eclipse.org/bugs/enter_bug.cgi?product=AspectJ
To make the bug a priority, please include a test program
that can reproduce this exception.
GC overhead limit exceeded
when weaving classes
when weaving
when batch building BuildConfig[null] #Files=0 AopXmls=#0
GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
at org.aspectj.apache.bcel.classfile.ConstantPool.copy(ConstantPool.java:69)
at org.aspectj.apache.bcel.generic.ClassGen.<init>(ClassGen.java:161)
at org.aspectj.weaver.bcel.LazyClassGen.<init>(LazyClassGen.java:255)
at org.aspectj.weaver.bcel.BcelObjectType.getLazyClassGen(BcelObjectType.java:523)
at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1742)
at org.aspectj.weaver.bcel.BcelWeaver.weaveWithoutDump(BcelWeaver.java:1710)
at org.aspectj.weaver.bcel.BcelWeaver.weaveAndNotify(BcelWeaver.java:1472)
at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1286)
at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.weaveQueuedEntries(AjPipeliningCompilerAdapter.java:435)
at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.afterCompiling(AjPipeliningCompilerAdapter.java:304)
at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$afterReturning$org_aspectj_ajdt_internal_compiler_CompilerAdapter$2$f9cc9ca0(CompilerAdapter.aj:73)
at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:430)
at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:1003)
at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:267)
at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:181)
at org.aspectj.ajdt.ajc.AjdtCommand.doCommand(AjdtCommand.java:112)
at org.aspectj.ajdt.ajc.AjdtCommand.runCommand(AjdtCommand.java:60)
at org.aspectj.tools.ajc.Main.run(Main.java:355)
at org.aspectj.tools.ajc.Main.runMain(Main.java:234)
at org.aspectj.tools.ajc.Main.main(Main.java:84)
23-Sep-2013 23:58:12 org.aspectj.weaver.tools.Jdk14Trace info
INFO: Dumping to D:\Projects\Delete\AspectjTest\.\ajcore.20130923.234357.932.txt
1 fail|abort
a workaround would be to use the <java> ant command, and list the main weaver class as the thing that runs. org.aspectj.tools.ajc.Main, you would also have to set all the args manually that this ant task does automatically.
I got it using it via ANTs exec task calling the aspectj1.7/bin/ajc.bat (1.7.3) with args.
Just editing ajc.bat and replacing -Xmx64g by -Xmx3g helped me trying to apply it e.g. on the guava-18.0.jar.
Similarly it was also mentioned here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=36234#c3
if you wan't to use the aspectj:iajc task nevertheless you should run your ant.bat (or sh) with the appropriate JVM args as above.
Within Eclipse (it happens normally within the Eclipse VM and in case it is not appropriately configured and you don't wanna make the JVM arg changes in the eclipse.ini file) you would need to adjust the implicitely created External Tools Configuration for your ANT target and set JRE => Runtime JRE: [x] Separate JRE: ... and adjust its VM arguments: -Xmx3g e.g..
I've been running into some issues with the ejbdoclet Ant task, specifically, it is giving me output such as the following:
[ejbdoclet] XJavaDoc Ignoring class myClass in
/path/myClass.java. It was generated (Wed Mar 28 16:59:12 EDT 2012) after XJavaDoc's timestamp was reset (Wed Mar 28 16:58:52 EDT
2012)
You will note that the file is being ignored because it was generated after the timestamp on the file. The source files are currently sitting on an NFS share connected to the build cluster and for various resasons, generating the files on the local machines will not be posible. As such, I have used the force="true" tag as documented as follows:
<ejbdoclet ejbSpec="2.0" destdir="${common.generated}" force="true">
However, it is not being respected by XDoclet, any thoughts as to what might be going on?
Oddly enough, this appears to be an error where the message that was provided didn't accurately reflect what was expected. The error message indicates that the file is being ignored due to the fact that it's date stamp is in the future when compared to the one that ejbdoclet is using to determine if the files should be generated. This actually bypasses the force attribute so the error is actually with regards to the system clocks not being synchronized as opposed to with ejbdoclet itself per se.