ewertonbermejo / merapi

Automatically exported from code.google.com/p/merapi
0 stars 0 forks source link

Big problems with flex-side message receiver #12

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Send a lot of (big) messages from Java to Air

What is the expected output? 
We should get every message sent from java-side

What do you see instead?

Some,initial bunch of messages is beeing processed; rest (due to 
DESERIALIZATION error) is dropped.
In my opinion error is caused by wrong assumption that every Java message 
could be processed before arrival of another one. And that's not true (as 
you can easy reproduce with my CrashTest example)

I've rewriten (and refactored for readability) a bit of merapi's core, to 
be more error-proof in that use case. Hovewer there is still one issue - 
memory leak caused by AMF3Reader. When we do a lot of bridge 
communication, great ammount of messages is beeing created, and i cannot 
figure out how to force them to vanish :/

Attached file contains sample CrashTest Flex+Java projects, along with my 
version of merapi's library, and patches

Original issue reported on code.google.com by strange3...@gmail.com on 20 Feb 2010 at 5:51

Attachments:

GoogleCodeExporter commented 8 years ago
Thanks for reporting this... quick question... did you patch based off of trunk 
or
the dev branch?

Original comment by adamfla...@gmail.com on 20 Feb 2010 at 6:26

GoogleCodeExporter commented 8 years ago
Patch is agains the trunk

Original comment by strange3...@gmail.com on 20 Feb 2010 at 11:52

GoogleCodeExporter commented 8 years ago
It may be that can't see obvious solution, but there's no way to force messages 
sent
from JAVA to be destroyed in FLEX.
There's steady leak at the flash runtime seal and no garbage collection action 
at the
horizon. It has something to do with ByteArray.readObject() method that 
reserves more
and more resources. 
One walk-around I could think of is to bypass AMF object deserialization (and
serialization at JAVA side), prevent new objects from being created, and reuse 
one
single object (Flyweight pattern) in whole framework. 
One could substitute the message type in runtime based on received raw data 
structure
(could be some predefined header specification), pass the message to dispatcher,
decode RAW data in handler(s), and feed view(s).

It could be tedious, but applicable, and much more efficient.
What do you think ?

Original comment by strange3...@gmail.com on 25 Feb 2010 at 1:42

GoogleCodeExporter commented 8 years ago
I know it is like 3 yesr later and may be it not worth to bring dead fromb the 
grave, but I agree, there are memory leaks in Merapi, especially when using 
flash.utils.ByteArray.readObject(), in my project memory usage leak big just 
becasue I sending alot of data bacj and forth....

Original comment by lytvyn...@gmail.com on 7 Aug 2013 at 4:46

GoogleCodeExporter commented 8 years ago
Yeah dead as a mammoth, but I remember myself stepping over this problem 
eventually. Or may only remember wrongly...
Anyway if you care for some solution here let me dig through my local codes for 
this project and maybe I will be able to restore.
I have no need of keeping it secret, so open to sharing with you, provided I 
find it. 3 years usually means 2-3 different workstations and a plenty of 
projects in meantime.

Otoh you are using this project in some professional work or only experimenting 
? I indeed thought that it was a nice tandem by that period, but couldn't find 
any real applications that would profit from it.

Original comment by strange3...@gmail.com on 7 Aug 2013 at 8:05