CFIMAP use of connection attribute failing (with AWS)

Until recently, this code * worked fine:

<cfimap
	action="open"
	server = "imap.mail.us-west-2.awsapps.com" 
	port="993"
	username = "redacted@akhonline.com" 
	secure="true" 
	password = "redacted" 
	connection="aws01" />

<cfimap
	action="getAll"
	connection="aws01"
	name="getAll" 
	attachmentpath="#expandPath('./')#attachments" 
	generateuniquefilenames="true" 
	maxrows="8" />

<cfimap
	action="close"
	connection="aws01" />

Yesterday, this started throwing the following error:

There is no connection available with name [aws01]
line number references the 2nd tag.
stack trace attached

Change the code to something like this *, and the example works again:

	<cfimap
		action="getAll"
		server = "imap.mail.us-west-2.awsapps.com" 
		port="993"
		secure="true" 
		password = "redacted" 
		username = "redacted@akhonline.com" 
		name="getAll" 
		attachmentpath="#expandPath('./')#attachments" 
		generateuniquefilenames="true" 
		maxrows="8" 
		connection="aws01" />

	<cfimap
		action="close"
		connection="aws01" />

So, for some reason, Lucee can’t access or maintain a named AWS IMAP connection across <cfimap> tags anymore. The connection apparently exists only for the work within one?
As noted earlier, this code has been working fine in it’s original form until recently. It’s possible that some updates were applied by sysops without my knowledge.

  • Could some update have changed “allowed IMAP connections” (some unknown setting I’m guessing might be in Lucee, Java, or Linux?) to a bad value? (Something like Java BIO comes to mind)
  • I cannot find any log / error entries to indicate why or when an IMAP connection would have been opened, closed or not created. Where should I look?
  • Any other ideas or thoughts?
    Those are my questions, thanks for reading!

These * examples (using two tags vs using one) are for simplicity, as our usage of sequential cfimap tags is actually for more complicated actions, like:
  1. Open connection (tag 1)
  2. Get a query of 8 emails in the Inbox, with their unique ids (tag 2)
  3. Parse each email for AWS notify structure, make database changes
  4. Use the open connection to reference one email by unique id and either trash it or move to another folder (tag 3)
  5. When done looping through the emails, close the connection (tag 4)

stackTrace.txt (2.9 KB)

Aaaannd it’s started working again.
No wait… it’s breaking again a few minutes later.
Whoops. Now it’s working, even for a while this time.

F5 is an amazing key, right?

I wish I could find or dump the details of the actual IMAP conversation!

Today it’s broken again. Same issue: An IMAP connection created one tag earlier is not available for the following tag.

Are multiple users / connections accessing the same page at the same / similar time and creating a race condition? Could try a lock to see if that helps?

Thanks @psarin - this is a dedicated script which is called by a cron job every 15 minutes. There’s no user action or other event to trigger it.
I currently have the job disabled while I experiment with possible fixes, so I’ll try the lock and update this thread with results.

I would also suggest that you try a lock. A structure like

<cflock name="imapLock" timeout="5">
    <cfimap
	    action="open">
</cflock>
<cflock name="imapLock" timeout="30">
    <cfimap
	    action="getAll">
</cflock>
<cfimap
	action="close">