tracker issue : CF-3787631

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

Axis2 web services can cache unexpectedly.

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Raymond Camden / Raymond Camden (raymondcamden)

Created: 07/10/2014

Components: Web Services

Versions: 10.0

Failure Type:

Found In Build/Fixed In Build: Final /

Priority/Frequency: Normal / Some users will encounter

Locale/System: English / Platforms All

Vote Count: 6

Listed in the version Issues Fixed doc
Copying the text from my blog post here (

Credit for this find goes to Steve Seaquist. He and I have been discussing this over email the last few days. Ok, quiz time, look at the following CFC:

component  {

	variables.weird = 0;
	remote numeric function testWeird() {
		return variables.weird;

Imagine you are calling this CFC directly from JavaScript code. As you know, each time you call a CFC remotely, it will be created on the fly. So calling this CFC's testWeird method N times will always return 1. However, what happens if you call it as a web service?

If you said 1, you would be wrong. Under Axis2, the CFC is now persistent. I have no idea why. But if you make calls to the CFC as a webservice, you will see that the result increments by one every time you do so. I've got no idea what scope this is living in (my first test was early this morning, hours ago), and the only way to clear this is to edit the CFC itself. (Refreshing the WSDL also does it.) If you add wsversion="1" to the component tag it will use the earlier Axis library and act the right way.

Perhaps this is some known "feature" of Axis2. I did a bit of Googling but nothing really struct me as relevant. Whether good or bad, this is one of those things I did not expect (neither did Steve) so I'm blogging to warn others.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3787631

External Customer Info:
External Company:  
External Customer Name: raymondcamden
External Customer Email:  
External Test Config: My Hardware and Environment details:



Voting for consistent behavior.
Vote by External U.
11657 | July 10, 2014 10:39:40 AM GMT
This is a change in behavior in how we designed the Axis 2 web services support. In Axis 1, For every web service request we created a new CFC instance and the request was handled by this new instance. That is why the variables always gets re initialized for every request. In Axis 2, we are creating the CFC instance the first time only. For every subsequent requests the same instance is used. So you are seeing the caching there. A new CFC instance will be created only if service CFC is modified. Normally if you are deploying an axis2 based aar, in tomcat, you will see the same behavior. This was a design decision we took. Are you facing any issues because of this caching? Do you have a requirement to use different CFC instances for each web service request?
Comment by Paul N.
11649 | August 21, 2014 07:55:10 AM GMT
Well, in every other aspect of using a CFC, via Ajax (regular GET) or web service, it does not act like this. To me, this is unexpected and needs to be documented - at minimum. I'd change it to reload, but, I don't feel strongly about it.
Comment by External U.
11650 | August 21, 2014 08:38:45 AM GMT
This needs to be made consistent with Axis 1 behavior or a way to toggle it in Application.cfc or CFAdmin.
Vote by External U.
11658 | August 21, 2014 02:15:28 PM GMT
What a terrible idea. Just because it's by design doesn't make that a good decision. This is not only inconsistent, it is purposefully and lazily inconsistent.
Vote by External U.
11659 | August 22, 2014 06:32:56 AM GMT
This needs to be documented and consistent by default. If you think it's a good idea to cache CFC instances used as web services, fine, I can see there might be some significant performance gains there. But for Pete's sake, make it a configurable option on a per-CFC basis.
Vote by External U.
11660 | August 22, 2014 11:04:26 AM GMT
Now a new attribute is added in CFC called reuseInstance. It takes a boolean value. If the reuseInstance is specified as true, the same instance is used for handling the requests. If reuseInstance is specified as false, a new instance of CFC is created each time for serviceing the request. The default value is true. And it is the recommended value. It should be set to false, only if you really need that as it has performance implications. Along with the attribute in CFC, a new application setting is also added. You can specifiy that like this.wssettings.reuseInstance="true" in the Application.cfc
Comment by Paul N.
11651 | September 12, 2014 12:17:50 PM GMT
+1, this gave me a headache for about a month before I knew it existed.
Vote by External U.
11661 | September 19, 2014 03:55:26 PM GMT
This works as expected.
Comment by Akhila K.
11652 | October 15, 2014 06:15:18 AM GMT
It is marked as fixed. Is it in CF10?
Comment by External U.
11653 | October 15, 2014 08:56:02 AM GMT
I've verified this is fixed in CF11 Update 3. The default value of reuseInstance is false, which maintains backward-compatibility. Good, b/c opting into performance improvement here is probably preferred over opting into backward-compat. Thanks!, -Aaron
Comment by External U.
11654 | November 07, 2014 04:32:41 AM GMT
dom_watson's workaround works: It's okay for Axis2 to cache. Those who need it not to do so can apply the workaround.
Vote by External U.
11662 | December 12, 2014 06:52:47 PM GMT
I'm the discoverer of the bug. I just now voted "it's all good, we cool" after proving to myself that dom_watson's suggested workaround worked. Our site had trouble with CF11 Update 3 (released 2014-12-10, I think), and had to revert. Good to know, when we finally **DO** get it installed, reuseInstance will make it even easier than Dominic's CreateObject trick. And to DanaKowalski, I felt that same pain for just as long. I can't tell you how many times I had to request CF Server restarts and ask my CF Admin to check that he hadn't turned on Trusted Cache. (Bleedover of data wasn't the only symptom. It also manifested as source changes not taking effect.) Thanks for voting yes everyone.
Comment by External U.
11655 | December 12, 2014 07:11:15 PM GMT
P.S.: When you think about it, Adobe's original design choice was *profoundly* useful for performance. The problems were unannounced major change of behavior and lack of configurability (at first). I intend to use reuseInstance true with dom_watson's workaround in production for performance. And I intend to use reuseInstance false in development and test. It's like Trusted Cache for the Axis environment, in other words. Thanks again, everyone.
Comment by External U.
11656 | December 13, 2014 12:46:44 PM GMT