[
https://issues.apache.org/jira/browse/CB-9353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14633743#comment-14633743
]
Chris Brody commented on CB-9353:
---------------------------------
Thanks for looking at this. IIRC I had already tried both GSON and Jackson
libraries and got a similar memory problem with both. I think this is confirmed
by a comment to an answer to the stackoverflow question: "Sure enough, calling
new String(String string) does NOT create a newly allocated String in memory,
it only points to the backing char[]. public String(String string) { value =
string.value; offset = string.offset; count = string.count; }"
There are two things I do not like about changing the JSON library/API:
- I really do not like the idea of breaking all plugins so drastically
- If I am not mistaken, Jackson and LoganSquare seem to force the programmer to
define the JSON object data type. But my sqlite plugin and perhaps some other
plugins expect and depend on a more flexible JSON interface, to pass options
objects or an array of arbitrary data types, for example.
Also, I do not see this issue as critical for my own sqlite plugin since I have
already implemented a workaround, as I explained in the description.
Another idea could be to add new functions to the Cordova plugin interface that
allows the programmer to receive the JSON parameters as a string, and use
his/her own JSON library to parse the JSON arguments and format the JSON
response string. The wp8 version seems to do this.
FYI someone also mentioned IG-JSON (by Instragram), which also seems to require
defined JSON object data types.
> Memory issue in Android version when passing a large number of JSON objects
> in either direction
> -----------------------------------------------------------------------------------------------
>
> Key: CB-9353
> URL: https://issues.apache.org/jira/browse/CB-9353
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
> Reporter: Chris Brody
> Assignee: Joe Bowser
> Priority: Critical
> Fix For: 5.0.0
>
>
> As reported in
> https://github.com/litehelpers/Cordova-sqlite-storage/issues/18: when an
> array with a very large number of JSON objects is sent from Javascript to
> Java, I would encounter a memory problem in JSON as called by
> CordovaPlugin.execute():
> E/art (22291): Throwing OutOfMemoryError "Failed to allocate a 28 byte
> allocation with 20 free bytes and 20B until OOM" (recursive case)
> E/art (22291): "JavaBridge" prio=5 tid=25 Runnable
> E/art (22291): | group="main" sCount=0 dsCount=0 obj=0x12de6820
> self=0xb73ae620
> E/art (22291): | sysTid=22377 nice=0 cgrp=apps sched=0/0
> handle=0xb73aead8
> E/art (22291): | state=R schedstat=( 0 0 0 ) utm=653 stm=94 core=1
> HZ=100
> E/art (22291): | stack=0xa4ee1000-0xa4ee3000 stackSize=1036KB
> E/art (22291): | held mutexes= "mutator lock"(shared held)
> E/art (22291): at
> java.util.LinkedHashMap.addNewEntry(LinkedHashMap.java:195)
> E/art (22291): at java.util.HashMap.put(HashMap.java:403)
> E/art (22291): at org.json.JSONObject.put(JSONObject.java:264)
> E/art (22291): at org.json.JSONTokener.readObject(JSONTokener.java:385)
> E/art (22291): at org.json.JSONTokener.nextValue(JSONTokener.java:100)
> E/art (22291): at org.json.JSONTokener.readArray(JSONTokener.java:430)
> E/art (22291): at org.json.JSONTokener.nextValue(JSONTokener.java:103)
> E/art (22291): at org.json.JSONTokener.readObject(JSONTokener.java:385)
> E/art (22291): at org.json.JSONTokener.nextValue(JSONTokener.java:100)
> E/art (22291): at org.json.JSONTokener.readArray(JSONTokener.java:430)
> E/art (22291): at org.json.JSONTokener.nextValue(JSONTokener.java:103)
> E/art (22291): at org.json.JSONArray.<init>(JSONArray.java:92)
> E/art (22291): at org.json.JSONArray.<init>(JSONArray.java:108)
> E/art (22291): at
> org.apache.cordova.CordovaPlugin.execute(CordovaPlugin.java:64)
> E/art (22291): at
> org.apache.cordova.PluginManager.execHelper(PluginManager.java:242)
> E/art (22291): at
> org.apache.cordova.PluginManager.exec(PluginManager.java:227)
> E/art (22291): at
> org.apache.cordova.ExposedJsApi.exec(ExposedJsApi.java:53)
> E/art (22291): at
> org.chromium.base.SystemMessageHandler.nativeDoRunLoopOnce(Native method)
> E/art (22291): at
> org.chromium.base.SystemMessageHandler.handleMessage(SystemMessageHandler.java:53)
> E/art (22291): at android.os.Handler.dispatchMessage(Handler.java:102)
> E/art (22291): at android.os.Looper.loop(Looper.java:135)
> E/art (22291): at android.os.HandlerThread.run(HandlerThread.java:61)
> The workaround, which took me some hard work to develop and test, is to send
> my data as a flat array which the Java code has to interpret very carefully.
> In addition, in case the Java code attempts to create an array with a very
> large number of JSON objects in order to send a response I get similar
> problem. The workaround was again to format the response data as a flat array
> and interpret it very carefully on the Javascript side.
> While I do have a workaround I find this to be very clumsy and hope we can
> find a better solution. I am happy to make an isolated test plugin to
> reproduce and demonstrate this issue if the Apache Cordova project is serious
> about trying to fix it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
