The type for attribute format of tag document could not be determined

[Abdul L Koyappayil]

In my application, I am getting an error saying "The type for attribute format of tag document could not be determined". This is happening during PDF generation using cfdocument tag. Note that we are working with PDF files in Memory (ie , we are using the coldfusion option to write a PDF file to a variable by using the name attribute). Attaching the stack trace here.

[Charlie Arehart]

Abdul, the error says that you have not set a valid value for the "format" attribute of the cfdocument tag. You say you want a pdf, so you need to add format="pdf", as indicated in the cf docs for the tag.

Or do you think you are doing that already? 

[Abdul L Koyappayil]

Thanks Charlie for your response. Yes we do this via attributeCollection as below,

<cfset attributes.attrCollection = {
fontembed="true",
localUrl="yes",
format="PDF",
pagetype="A4",
unit="cm",
pageWidth="21",
pageHeight="29.7",
marginleft="0",
marginright="0",
margintop="5",
overwrite="true",
bookmark="true"
} />

The above variable we set to attributes scope since we generate PDF in CF thread. Also please note that when we try regenerating pdf 2 or 3 times this issuse never happens.

[Charlie Arehart]

OK, interesting. So first, wrap the cfdocument in a try/catch, and when it fails, dump out the attributes scope. You may well find that somehow it's NOT got the values that you think it does--in that moment. And in seeing what IS (or is NOT ) in the dump, you may better be able to tell where the problem is happening.

Second, if that doesn't get you anywhere, you could try a different scope than attributes. I do realize that the attributes scope is what's recommended by Adobe (such as here, https://helpx.adobe.com/coldfusion/developing-applications/developing-cfml-applications/using-coldfu..., even thought it's something that was creatd for use with CFML custom tags, an old concept).

But just as a sanity-check, what if you used the "request" scope instead? The doc there indicates that it would be supported. I realize the docs indicate that CF supposedly adds single-thread protection to use of the attributes scope, but I'm just throwing out an idea.

Indeed, finally, you say that "when we try regenerating pdf 2 or 3 times this issuse never happens." Can you clarify what you mean? Is it that this error only happens on the first call to create the PDF, but not subsequent ones? Is that about multiple calls in your browser to the same request, over and over? Or do you mean that within the code of this page, if called only once, it somehow sets things up to call multiple PDF generation actions? However you answer, that may be a clue as to why the problem happens. It sure sounds like some sort of race condition (despite the supposed protection of the attributes scope, mentioned in that doc page I linked to.)

WIll be interested to see how things sort out.

[Abdul L Koyappayil]

Sorry for being late to respond. In my further analysis, what we found is that this issue is happening only in a particular CF instance. We have 20 CF instances in a server. When we regenerate the PDF and if the regeneration happens on other CF instances this issue never occurs.

[Charlie Arehart]

That's interesting, but none of it negates the diagnostic approaches I offered in my last response. Have you tried any of them? Or do you mean that the fact it happens on only one server has led you or someone to deem that you don't want to try to solve or understand it?

If your conclusion is that "we think there must be something wrong with that one server", well, that may be so. It will be hard to diagnose that remotely. I would propose you could make 100% sure that all the CF Admin settings and jvm config args are the same.

And you could make sure there's no error in the running of any CF updates that you applied (there is a log for each update, in the CF hf-updates folder when you apply each update). I have a blog post on that with more details:

https://coldfusion.adobe.com/2019/03/problems-applying-cf-update-check-first/

But I'm hoping you may get to try the above to see what's up. It could be some coding issue that has a failure only on the one server, for some reason, and working backwards from that may get you to the solution, if the above ideas don't bear fruit.

Please do keep us posted/

[Abdul L Koyappayil]

I mentioned that issue is with only one particular instance of a server. Not with a server itself.

We have 20 instances (Say x1,x2......x20) in a CF server (CF 2018). Each of these instances pointing to the same code set. Now the issue is only with x16. There is no issues with other instances. If there is a code issue then we should get the same issue with all the instances right , since all the instances are pointing to the same code set.

[Charlie Arehart]

Abdul, replace the word  "server" with "instance" in my last reply, and all I said still applies--ESPECIALLY the first paragraph, which I plead for you to try.