tracker issue : CF-4205271

select a category, or use search below
(searches all categories and all time range)

CF2018 Update 5: Server unresponsive

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/Investigate

Reporter/Name(from Bugbase): / ()

Created: 09/27/2019

Components: Performance

Versions: 2018

Failure Type: Crash

Found In Build/Fixed In Build: 315699 / CF2018U6

Priority/Frequency: Critical / Few users will encounter

Locale/System: /

Vote Count: 2

Problem: CF2018 Update 5: Server unresponsive

Method: After installing update 5, server becomes unresponsive after few minutes of up time. Repro case not available.  Attaching the logs. 

Result: Server becomes unresponsive. Only way to get it back up is by restarting the services.

Expected: NA

Workaround: Customer has reverted the update and running on update 4.




Vikram, Can you pls ask the customer to try using the following flag in JVM config -Dcoldfusion.http.usepooling=false
Comment by Piyush K.
31660 | October 18, 2019 09:53:42 AM GMT
We are seeing similar issues on 2016 Patch 12 - does this work around apply to that version as well?
Comment by Mike P.
31668 | October 21, 2019 03:10:34 PM GMT
This issue is occurring in our environments as well. We will try the JVM argument provided and see if the behavior changes.
Comment by dakota c.
31682 | October 24, 2019 03:31:19 PM GMT
Can anyone from Adobe clarify what this argument is doing? and how new is it? New to this update, or been there for years? Also, is this specific to hangups in cfhttp processing, or some more generic hangup?
Comment by Charlie A.
31729 | October 29, 2019 02:43:39 PM GMT
Charlie, I am wondering the same thing. My bug report was closed in favor of this one and I don't even know if they are the same. We need some feedback from Adobe on what to do. I have a bunch of ColdFusion servers that are stuck on ColdFusion 2018 Update 4 because of this.
Comment by Dave C.
31730 | October 29, 2019 02:46:49 PM GMT
And also please clarify if this suggestion is for 2016 Patch 12 as well as 2018 Patch 5.
Comment by Mike P.
31731 | October 30, 2019 02:19:17 PM GMT
Mike, This JVM flag is only applicable to CF2018. You should not face this issue in CF2016. If you are still experiencing Server hang issue after applying CF 2016 Update 12, it might be because of a different reason. Please reach out to ColdFusion support @ [|] with more information so that we can investigate this issue further. -Nimit
Comment by Nimit S.
31732 | October 31, 2019 02:21:24 AM GMT
Dave/Dakota, The JVM argument in discussion, that is suggested as a stopgap measure here, disables HTTP connection pooling, as is evident from it's name. This means that every time an HTTP call is made, instead of reusing a readily available connection from a pool of connections, a new one will be created (and subsequently terminated once it has served it's purpose). For further details you may reference the "Pooling connection manager" section at This is not suggested as a solution for any CF server may be running into performance issues. A CF server can become unresponsive for any number of reasons. The best way to determine the root cause is to collect thread dumps of the underlying JVM. We've suggested this workaround only for the folks, for whom, we've examined the logs and found HTTP connection allocation mechanism to be the problem. Here's an example of the stacktrace from a connection starved thread: "http-nio-10192-exec-9" #163 daemon prio=5 tid=0x00007fdc408cf800 nid=0x34e7 waiting on condition [0x00007fdb9bcdd000] java.lang.Thread.State: WAITING (parking) JavaThread state: _thread_blocked - jdk.internal.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise) - parking to wait for <0x00000000d9088e08> (a java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject) - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, line=194 (Compiled frame) - java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() @bci=42, line=2075 (Compiled frame) - org.apache.http.pool.PoolEntryFuture.await(java.util.Date) @bci=48, line=138 (Compiled frame) - org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(java.lang.Object, java.lang.Object, long, java.util.concurrent.TimeUnit, org.apache.http.pool.PoolEntryFuture) @bci=479, line=306 (Compiled frame) - org.apache.http.pool.AbstractConnPool.access$000(org.apache.http.pool.AbstractConnPool, java.lang.Object, java.lang.Object, long, java.util.concurrent.TimeUnit, org.apache.http.pool.PoolEntryFuture) @bci=8, line=64 (Compiled frame) - org.apache.http.pool.AbstractConnPool$2.getPoolEntry(long, java.util.concurrent.TimeUnit) @bci=15, line=192 (Compiled frame) - org.apache.http.pool.AbstractConnPool$2.getPoolEntry(long, java.util.concurrent.TimeUnit) @bci=3, line=185 (Compiled frame) - org.apache.http.pool.PoolEntryFuture.get(long, java.util.concurrent.TimeUnit) @bci=45, line=107 (Compiled frame) - org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(java.util.concurrent.Future, long, java.util.concurrent.TimeUnit)
Comment by Piyush K.
31733 | October 31, 2019 08:16:26 PM GMT
Hi Piyush, Is this a stopgap measure for CFHTTP randomly hanging as well? My stacktrace is much different than the one above. See bug report:
Comment by Dave C.
31734 | October 31, 2019 08:29:47 PM GMT
Dave, I'm sorry if I wasn't clear before. It is especially for CFHTTP. Although HTTPClient would normally be the underlying library used in anything that involves making an HTTP call. I don't see the full thread dumps attached with CF-4205439, but the single thread stack trace shared in the report there, looks like the thread is waiting for a connection from the pool, same as the thread in the example I quoted earlier. "org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection("  
Comment by Piyush K.
31735 | November 03, 2019 06:42:12 PM GMT
Hi Piyush, Thanks for the explanation. Is there a fix coming for this in the next patch? If so, how close is it?
Comment by Dave C.
31736 | November 03, 2019 07:28:17 PM GMT
Dave, That's the plan. No timelines yet. Can you pls share the file mentioned in your threadDump (E:\WEBROOT\\global\extensions\components\lloyd_mats.cfc:21)). I would like to see how the HTTP call is being made in your code. You may mail that to me at
Comment by Piyush K.
31737 | November 04, 2019 01:21:23 PM GMT
Thanks for the explanation, Piyush. (Somehow I didn't get or didn't see the notifications about these last few replies.) I see that update 6 is due to fix this: Can you confirm that those who added this arg should be able to remove it, after applying that fix?
Comment by Charlie A.
31810 | November 13, 2019 12:54:21 PM GMT
Also, shouldn't the status and fixed in build values be changed here?
Comment by Charlie A.
31811 | November 13, 2019 12:55:09 PM GMT