Java client: Issue with empty string("") when fetching records using query, batch(batch policy) or scan(scan policy)

Dear Aerospike team,

I have a complex object in aerospike(see json below). Using AQL, the fields with blank string (“”) is shown correctly. But when I fetch the records using either query, batch or scan, the fields with empty string(“”) are fetched with junk values. (Please see the fields ‘msTimezone’ and ‘anChargingVal’) in the Recordset dump. Also see attached image:

Record dump from java client(also see attached image): (gen:1),(exp:0),(bins:(ipCanSessions:[{activeFeatures=[{featureList=1, vendorId=10415, featureListId=1}], nxtPccRulePrec=130, sgsnMccMnc=30261, defBearerQos={arp={priorityLevel=15, preEmptionVuln=0, preEmptionCap=0}, defBearerQCI=8}, siteName=tpapps.realm, deviceId=unknown_hisingh_20180109140329971_7499||10000014528401, bcm=2, isTerminating=0, maxBwForAPN={downLinkBw=1410065408, upLinkBw=1410065408}, ipCanType=5, offline=0, isEmergency=0, nxtpktFilterId=1, ipv4ANGWAddr=[B@2eaebb48, eri=0, sgsnAddress=[B@6a50de44, anChargingAddr={addressValue=[B@411a4510, addressFamily=1}, diameterPeerId=-1634547950, msTimezone= , eventTriggers=1668, qosUpgrade=0, ratType=5, adjSessionData={maxBwForAPN={downLinkBw=1410065408, upLinkBw=1410065408}, defEPSBearQos={arp={priorityLevel=15, preEmptionVuln=0, preEmptionCap=0}, defBearerQCI=8}}, sessionId=pgw.diam.originRealm1.com;352851;2182910932, nrs=1, anChargingVal= [ , qosNegotiation=1, timeOfLastMsg=1515487329930, failedMsgCount=0, poTriRegistr=1668, activeWngCond={startOfRange=0}, nextRuleId=1, lastReauthTime=0, online=0, sbi={ipAddress=[B@43a6919a, apnId=imsvolte, subscriId=[{data=525037090631254, type=0}, {data=525037090631254, type=1}]}, ccReqNumber=1}])…)

My complex object when fetched using aql: [ { “ipCanSessions”: [ { “activeWngCond”: { “startOfRange”: 0 }, “activeFeatures”: [ { “vendorId”: 10415, “featureListId”: 1, “featureList”: 1 } ], “sgsnMccMnc”: “30261”, “lastReauthTime”: 0, “defBearerQos”: { “defBearerQCI”: 8, “arp”: { “priorityLevel”: 15, “preEmptionCap”: 0, “preEmptionVuln”: 0 } }, “eri”: 0, “eventTriggers”: 1668, “siteName”: “tpapps.realm”, “anChargingAddr”: { “addressFamily”: 1, “addressValue”: “8A 78 AA C5” }, “sgsnAddress”: “7F 00 00 05”, “qosUpgrade”: 0, “poTriRegistr”: 1668, “deviceId”: “unknown_hisingh_20180109141604980_11333||1000001b8b0401”, “nxtPccRulePrec”: 130, “ipCanType”: 5, “adjSessionData”: { “maxBwForAPN”: { “upLinkBw”: 1410065408, “downLinkBw”: 1410065408 }, “defEPSBearQos”: { “defBearerQCI”: 8, “arp”: { “priorityLevel”: 15, “preEmptionCap”: 0, “preEmptionVuln”: 0 } } }, “nextRuleId”: 1, “maxBwForAPN”: { “upLinkBw”: 1410065408, “downLinkBw”: 1410065408 }, “bcm”: 2, “isEmergency”: 0, “isTerminating”: 0, “sessionId”: “pgw.diam.originRealm1.com;352851;2183538729”, “diameterPeerId”: -1634547950, “offline”: 0, “nxtpktFilterId”: 1, “ipv4ANGWAddr”: “C0 A8 FF FE”, “msTimezone”: “”, “ratType”: 5, “nrs”: 1, “anChargingVal”: “”, “qosNegotiation”: 1, “timeOfLastMsg”: 1515488012397, “failedMsgCount”: 0, “online”: 0, “sbi”: { “subscriId”: [ { “data”: “525037090015231”, “type”: 0 }, { “data”: “525037090015231”, “type”: 1 } ], “ipAddress”: “0B 01 3C 7F”, “apnId”: “imsvolte” }, “ccReqNumber”: 1 } ], “peerIds”: [ -1634547950 ], “isFailOrTerm”: 0, “$dummy”: 0, “schemaVersion”: 18030000012, “timeOfOldest”: 9223372036854775807, “deviceId”: “unknown_hisingh_20180109141604980_11333||1000001b8b0401”, “sessionCounts”: [ 1, 0, 0, 0, 0, 0, 0, 0 ] } ]

Was this record written with a C client application? or AQL?

The C client writes strings exactly as they appear (stream of bytes). The server does alter this string a returns the string to the clients as is.

The java client (and all other clients) assumes the string is in UTF8 format. If the C client writes a string in unicode format, the java client will attempt to decode this string using UTF8.

If you are writing string using the C client and reading strings in other clients, it’s important to always write strings in UTF8 format.