[JIRA] [core] (JENKINS-19561) Unsafe & inefficient concurrency in XStream

jglick@cloudbees.com (JIRA)

unread,

Oct 5, 2015, 1:31:02 PM10/5/15

to jenkinsc...@googlegroups.com

Jesse Glick updated an issue

Jenkins /

JENKINS-19561

Unsafe & inefficient concurrency in XStream

Change By:	Jesse Glick
Labels:	2.0 performance threads workflow xstream

Add Comment

This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)

dbeck@cloudbees.com (JIRA)

unread,

Mar 7, 2016, 3:54:02 PM3/7/16

to jenkinsc...@googlegroups.com

Daniel Beck updated an issue

Jenkins /

JENKINS-19561

Unsafe & inefficient concurrency in XStream

Change By:	Daniel Beck
Labels:	2.0 -rejected performance threads workflow xstream

Add Comment

jglick@cloudbees.com (JIRA)

unread,

Aug 3, 2016, 11:28:02 AM8/3/16

to jenkinsc...@googlegroups.com

Jesse Glick commented on

JENKINS-19561

Re: Unsafe & inefficient concurrency in XStream

Confirmed to occur in production using Pipeline 1.14.1 on 1.625.x:

 
                                                                …	WARNING	j.u.ErrorLoggingScheduledThreadPoolExecutor#afterExecute: failure in task not wrapped in SafeTimerTaskjava.lang.RuntimeException: Failed to serialize org.jenkinsci.plugins.workflow.job.WorkflowRun#execution for class org.jenkinsci.plugins.workflow.job.WorkflowRun
	at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:215)
	at hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:183)
	at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:138)
	at hudson.util.RobustReflectionConverter.doMarshal(RobustReflectionConverter.java:168)
	at hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:109)
	at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
	at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
	at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
	at com.thoughtworks.xstream.core.TreeMarshaller.start(TreeMarshaller.java:82)
	at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.marshal(AbstractTreeMarshallingStrategy.java:37)
	at com.thoughtworks.xstream.XStream.marshal(XStream.java:1026)
	at com.thoughtworks.xstream.XStream.marshal(XStream.java:1015)
	at com.thoughtworks.xstream.XStream.toXML(XStream.java:988)
	at hudson.XmlFile.write(XmlFile.java:178)
	at hudson.model.Run.save(Run.java:1901)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.copyLogs(WorkflowRun.java:397)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.access$600(WorkflowRun.java:111)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun$3.run(WorkflowRun.java:265)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
	at java.util.HashMap$EntryIterator.next(HashMap.java:1463)
	at java.util.HashMap$EntryIterator.next(HashMap.java:1461)
	at com.thoughtworks.xstream.converters.collections.MapConverter.marshal(MapConverter.java:75)
	at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
	at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
	at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
	at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:88)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution$ConverterImpl.writeChild(CpsFlowExecution.java:949)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution$ConverterImpl.marshal(CpsFlowExecution.java:925)
	at hudson.util.XStream2$AssociatedConverterImpl.marshal(XStream2.java:361)
	at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
	at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
	at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84)
	at hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:224)
	at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:211)
	... 24 more
 
                                                            

Add Comment

This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)

jglick@cloudbees.com (JIRA)

unread,

Oct 6, 2016, 3:28:02 PM10/6/16

to jenkinsc...@googlegroups.com

Jesse Glick commented on

JENKINS-19561

Re: Unsafe & inefficient concurrency in XStream

Codehaus is dead, and I cannot find a new location for XSTR-744, but mail archives can be found here.

Add Comment

jglick@cloudbees.com (JIRA)

unread,

Oct 6, 2016, 3:44:01 PM10/6/16

to jenkinsc...@googlegroups.com

Jesse Glick commented on

JENKINS-19561

Re: Unsafe & inefficient concurrency in XStream

XStream2 could be a façade which keeps a per-thread pool of actual implementations

Though this could introduce its own performance problems, if you have a lot of threads coming online and newly needing instances: initialization is not so cheap.

The alternative is to not call AnnotationMapper.autodetectAnnotations, but this implies either not honoring XStream annotations (incompatible for some plugins—example), or processing them when the plugin is loaded (not practical without some way of quickly finding annotated classes without scanning every class file).

Rather than a ThreadLocal it might be better to have an unbounded pool of instances. When a method is called and the pool is empty, a new instance would be created; otherwise an instance would be withdrawn from the pool. When the method completes the instance would be returned to the pool.