```2024-07-30 13:32:47,657 [ajp-nio-127.0.0.1-8016...
# cfml-general
a
Copy code
2024-07-30 13:32:47,657 [ajp-nio-127.0.0.1-8016-exec-3] AXIS2 ERROR org.apache.axis2.rpc.receivers.RPCMessageReceiver - Index 7 out of bounds for length 7
java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
	at org.apache.axis2.databinding.utils.BeanUtil.deserialize(BeanUtil.java:812) ~[axis2-adb-1.7.0.jar:1.7.0-SNAPSHOT]
	at org.apache.axis2.rpc.receivers.RPCUtil.processRequest(RPCUtil.java:197) ~[axis2-adb-1.7.0.jar:1.7.0-SNAPSHOT]
	at org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:250) ~[axis2-adb-1.7.0.jar:1.7.0-SNAPSHOT]
b
Can you share the function's code?
a
I don't think it has anything to do with the code inside the function as I encountered the problem with relatively no function body at all. Also, it works fine in our dev and production server. It's just on our local sandboxes and qa servers where they don't work consistently. They'll work for a few hours and then with no changes at all start giving that array oob error. Only thing I've come up with is that the local/qa servers don't have publicly addressable IPs or domain names, so you must be on the vpn to connect to them. Also, they have self signed SSL certs. It seems like since they work perfectly fine in our environments that are publicly accessible IPs and have legit SSL certs, it must be something with that.
Copy code
<cffunction name="UpdateJob" access="remote" returntype="struct" returnformat="wddx" output="false" httpMethod="POST" description="Update Job data after validation">
		<cfargument name="JobID" type="string" required="yes">
		<cfargument name="ScheduledCutDate" type="date" required="no" default="1/1/1900" hint="Pass 1/1/1901 to Clear Date">
		<cfargument name="ConfirmDate" type="date" required="no" default="1/1/1900" hint="Pass 1/1/1901 to Clear Date">
		<cfargument name="MaterialAvailableDate" type="date" required="no" default="1/1/1900" hint="Pass 1/1/1901 to Clear Date">
		<cfargument name="CADCompleteDate" type="date" required="no" default="1/1/1900" hint="Pass 1/1/1901 to Clear Date">
		<cfargument name="UpdatedBy" type="numeric" required="no" default="-22">
		<cfargument name="RemoteIP" type="string" required="no" default="#CGI.REMOTE_ADDR#">
		<cfargument name="EventID" type="string" required="no" default="#CreateUUID()#">

		<cfset var stReturn = StructNew()>

		<cfreturn stReturn>
	</cffunction>
b
The number of arguments seems to play a role. So I thought we could have another look at the function just to rule things out. For example, "1/1/1900" is not a date-time object. So, might
type="date" default="1/1/1900"
be a gremlin? What happens when you replace
default="1/1/1900"
with
default="#createdate(1900,1,1)#"
? An alternative test: use
type="string" default="1/1/1900"
instead.
a
Interesting point. I’ll play around with that and see if there’s any difference. In production we’ve had 3 of those date args for about a year. The 4th was added for this feature improvement.