I'm currently on 3.1 Build 2014-03-30 22:33:45 GMT, but this has been going on since 2.0.2
On Tuesday, July 15, 2014 1:04:08 PM UTC-4, Al Holden wrote: > > I'm running cfimap commands in hourly cron jobs and have yet to see this > error. Weird. > FYI, this app is still on OpenBD: Version=3.0; Build=2013-03-04 04:03:30 > GMT > I wonder if you're on a newer version, and if the tag has any revisions > since then? > Al > > On 7/11/2014 2:48 PM, Rawk wrote: > > So, I've modified my code to use static variables with hard-coded values > (see below). I'm still getting the occasional error stating a missing > server attribute. Very strange, indeed. > > <cfset svr = "mail.server.com"> > <cfset uName = "username"> > <cfset pWord = "password"> > <cfset attachmentPath = "/path/to/attachment/folder/"> > > <cfimap action="open" service="imap" connection="mailConnection" > server="#svr#" username="#uName#" password="#pWord#"> > > <cfimap action="listmail" connection="mailConnection" name="mail" > folder="Inbox"> > > <cfloop query="mail"> > <cfimap action="readmail" connection="mailConnection" folder="Inbox" > messageid="#mail.id#" name="message" attachmentsuri="#attachmentPath#"> > <!--- do a bunch of stuff with the message ---> > </cfloop> > > > > On Sunday, June 1, 2014 12:37:01 AM UTC-4, Rawk wrote: >> >> Thanks Al, >> >> The timing of the errors seems to vary. Sometimes the errors occur just >> a few hours apart. Sometimes, a few day apart. However, just as a test to >> rule it out, I will statically define these attributes for a while and see >> if the errors continue. >> >> >> On Friday, May 30, 2014 7:10:07 PM UTC-4, Al Holden wrote: >>> >>> Hi Rawk; >>> >>> I've been using OpenBD's CFIMAP tag to do something very similar (bounce >>> checking) - and have not seen the error you describe. >>> >>> But then, my tag has a plain text SERVER attribute - not a dynamically >>> generated one. So I would first suspect that your variable >>> application.systemConfig.emailServerIpAddress is occasionally null or blank. >>> >>> When? You could examine the timing of those errors again, and see if >>> they are spaced anywhere near or beyond your Application's timeout setting. >>> Could it be possible that - if this task were the first thing to "wake up" >>> your app from a timed-out state - this variable may not exist yet (or be >>> blank - if blank is a default in your code)? >>> >>> HTH, this was just the first thing I thought of... >>> >>> Al Holden >>> >>> -- > -- > online documentation: http://openbd.org/manual/ > http://groups.google.com/group/openbd?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "Open BlueDragon" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
