Earlier this year

• Oct 01, 2009

  issue 18 (Class Mapping with not-local classes is lost while deseriali...) changed by evertpot   -   You are correct. A fix is committed in r249. Thanks very much

  Status: Accepted

  Cc: evertpot

  You are correct. A fix is committed in r249. Thanks very much

  Status: Accepted

  Cc: evertpot
• Oct 01, 2009

  r249 (Fix for Issue 18 ) committed by evertpot   -   Fix for Issue 18

  Fix for Issue 18
• Oct 01, 2009

  issue 17 (Unable to have a single object as argument with AMF3) Status changed by evertpot   -   This is correct. I'm marking this as duplicate

  Status: Duplicate

  This is correct. I'm marking this as duplicate

  Status: Duplicate
• Oct 01, 2009

  issue 17 (Unable to have a single object as argument with AMF3) commented on by thepurpl...@gmail.com   -   I've just seen this issue has already been notified in Issue 13 http://code.google.com/p/sabreamf/issues/detail?id=13 Thus, a current workaround is to define a SABREAMF_AMF3_PRESERVE_ARGUMENTS constant somewhere before processing AMF request (this feature is only available in the latest SVN releases)

  I've just seen this issue has already been notified in Issue 13 http://code.google.com/p/sabreamf/issues/detail?id=13 Thus, a current workaround is to define a SABREAMF_AMF3_PRESERVE_ARGUMENTS constant somewhere before processing AMF request (this feature is only available in the latest SVN releases)
• Oct 01, 2009

  issue 18 (Class Mapping with not-local classes is lost while deseriali...) reported by thepurpl...@gmail.com   -   -- What steps will reproduce the problem? 1. Build a SabreAMF_OutputStream, with a SabreAMF_TypedObject object in it : $amfResponse = new SabreAMF_Message(); $amfResponse->addBody(array( 'target' => '/onResult', 'response' => '', 'data' => array( 'myobj' => new SabreAMF_TypedObject('my.path.to.classname', array('foo' => 'bar', 'baz' => 'foo')), 'foo' => 'bar' ) ); $amfOutputStream = new SabreAMF_OutputStream(); $amfResponse->serialize($amfOutputStream); 2. Build a SabreAMF_InputStream from this SabreAMF_OutputStream: $amfInputStream = new SabreAMF_InputStream($amfOutputStream->getRawData()); $amfResponse2 = new SabreAMF_Message(); $amfResponse2->deserialize($amfInputStream); 3. Watch the result : $bodies = $amfResponse2->getBodies(); var_dump($bodies[0]['data']->body); -- What is the expected output? What do you see instead? I'm expecting something like : array( 'myobj' => new SabreAMF_TypedObject('my.path.to.classname', array('foo' => 'bar', 'baz' => 'foo')), 'foo' => 'bar' ) But I get : array( 'myobj' => new SabreAMF_TypedObject(false, array('foo' => 'bar', 'baz' => 'foo')), 'foo' => 'bar' ) The class of the SabreAMF_TypedObject is set to false. -- What version of the product are you using? On what operating system? Windows XP, SabreAMF 1.3 -- Please provide any additional information below. I have a fix : In SabreAMF_AMF0_Deserializer::readTypedObject(), replace : if ($classname = $this->getLocalClassName($classname)) { $rObject = new $classname(); $isMapped = true; } else { $rObject = new SabreAMF_TypedObject($classname,null); } By : if ($localClassName = $this->getLocalClassName($classname)) { $rObject = new $localClassName(); $isMapped = true; } else { $rObject = new SabreAMF_TypedObject($classname,null); }

  -- What steps will reproduce the problem? 1. Build a SabreAMF_OutputStream, with a SabreAMF_TypedObject object in it : $amfResponse = new SabreAMF_Message(); $amfResponse->addBody(array( 'target' => '/onResult', 'response' => '', 'data' => array( 'myobj' => new SabreAMF_TypedObject('my.path.to.classname', array('foo' => 'bar', 'baz' => 'foo')), 'foo' => 'bar' ) ); $amfOutputStream = new SabreAMF_OutputStream(); $amfResponse->serialize($amfOutputStream); 2. Build a SabreAMF_InputStream from this SabreAMF_OutputStream: $amfInputStream = new SabreAMF_InputStream($amfOutputStream->getRawData()); $amfResponse2 = new SabreAMF_Message(); $amfResponse2->deserialize($amfInputStream); 3. Watch the result : $bodies = $amfResponse2->getBodies(); var_dump($bodies[0]['data']->body); -- What is the expected output? What do you see instead? I'm expecting something like : array( 'myobj' => new SabreAMF_TypedObject('my.path.to.classname', array('foo' => 'bar', 'baz' => 'foo')), 'foo' => 'bar' ) But I get : array( 'myobj' => new SabreAMF_TypedObject(false, array('foo' => 'bar', 'baz' => 'foo')), 'foo' => 'bar' ) The class of the SabreAMF_TypedObject is set to false. -- What version of the product are you using? On what operating system? Windows XP, SabreAMF 1.3 -- Please provide any additional information below. I have a fix : In SabreAMF_AMF0_Deserializer::readTypedObject(), replace : if ($classname = $this->getLocalClassName($classname)) { $rObject = new $classname(); $isMapped = true; } else { $rObject = new SabreAMF_TypedObject($classname,null); } By : if ($localClassName = $this->getLocalClassName($classname)) { $rObject = new $localClassName(); $isMapped = true; } else { $rObject = new SabreAMF_TypedObject($classname,null); }
• Oct 01, 2009

  issue 17 (Unable to have a single object as argument with AMF3) reported by thepurpleled   -   -- What steps will reproduce the problem? 1. Create a service method that receives an objet as argument, and prints it : public function test($obj) { print_r($obj); } 2. Call it with AMF3, with an object like {foo: "foo", bar:{baz: "bar"}} -- What is the expected output? What do you see instead? The printed thing is only the first property of the object ("foo"), whereas it should be the full object. -- What version of the product are you using? On what operating system? Windows XP, SabreAMF 1.3

  -- What steps will reproduce the problem? 1. Create a service method that receives an objet as argument, and prints it : public function test($obj) { print_r($obj); } 2. Call it with AMF3, with an object like {foo: "foo", bar:{baz: "bar"}} -- What is the expected output? What do you see instead? The printed thing is only the first property of the object ("foo"), whereas it should be the full object. -- What version of the product are you using? On what operating system? Windows XP, SabreAMF 1.3
• Sep 24, 2009

  issue 16 (SABREAMF_OBJECT_AS_ARRAY creates object with AMF0) commented on by evertpot   -   The behaviour is wrong for what the original goal of that setting was; however.. this might be yet another case where a BC break is not an option.

  The behaviour is wrong for what the original goal of that setting was; however.. this might be yet another case where a BC break is not an option.
• Sep 24, 2009

  issue 16 (SABREAMF_OBJECT_AS_ARRAY creates object with AMF0) commented on by msthornton   -   I'll write my unit test to test for the behavior that happens now. If the behavior is wrong then the tests and the code can be fixed.

  I'll write my unit test to test for the behavior that happens now. If the behavior is wrong then the tests and the code can be fixed.
• Sep 24, 2009

  issue 16 (SABREAMF_OBJECT_AS_ARRAY creates object with AMF0) commented on by msthornton   -   Yeah, seems so.

  Yeah, seems so.
• Sep 24, 2009

  issue 16 (SABREAMF_OBJECT_AS_ARRAY creates object with AMF0) commented on by evertpot   -   So it looks like it actually does the exact opposite of what it's supposed to do? :(

  So it looks like it actually does the exact opposite of what it's supposed to do? :(
• Sep 24, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by mike.benoit   -   Okay, I committed the change to remove the unnecessary check in isPureArray().

  Okay, I committed the change to remove the unnecessary check in isPureArray().
• Sep 24, 2009

  issue 16 (SABREAMF_OBJECT_AS_ARRAY creates object with AMF0) commented on by msthornton   -   "Fixing" this obviously breaks compatibility since most installs are expecting to get an array back.

  "Fixing" this obviously breaks compatibility since most installs are expecting to get an array back.
• Sep 24, 2009

  r248 (Remove uncessary (int) !== check from isPureArray for a ~5%...) committed by mike.benoit   -   Remove uncessary (int) !== check from isPureArray for a ~5% speed up

  Remove uncessary (int) !== check from isPureArray for a ~5% speed up
• Sep 24, 2009

  issue 16 (SABREAMF_OBJECT_AS_ARRAY creates object with AMF0) reported by msthornton   -   What is the expected behavior of this function? Right now it checks for SABREAMF_OBJECT_AS_ARRAY but casts as (object). Seems like it should by default cast to (object) and use array if SABREAMF_OBJECT_AS_ARRAY happens. I'm writing unit tests for the AMF0 Serializer/Desrialize and rand across this. public function readObject() { $object = array(); $this->refList[] =& $object; while (true) { $key = $this->readString(); $vartype = $this->stream->readByte(); if ($vartype==SabreAMF_AMF0_Const::DT_OBJECTTERM) break; $object[$key] = $this->readAmfData($vartype); } if (defined('SABREAMF_OBJECT_AS_ARRAY')) { $object = (object)$object; } return $object; }

  What is the expected behavior of this function? Right now it checks for SABREAMF_OBJECT_AS_ARRAY but casts as (object). Seems like it should by default cast to (object) and use array if SABREAMF_OBJECT_AS_ARRAY happens. I'm writing unit tests for the AMF0 Serializer/Desrialize and rand across this. public function readObject() { $object = array(); $this->refList[] =& $object; while (true) { $key = $this->readString(); $vartype = $this->stream->readByte(); if ($vartype==SabreAMF_AMF0_Const::DT_OBJECTTERM) break; $object[$key] = $this->readAmfData($vartype); } if (defined('SABREAMF_OBJECT_AS_ARRAY')) { $object = (object)$object; } return $object; }
• Sep 24, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by msthornton   -   Right, after running all the tests again (after fixing them), Fixed_isPureArray runs best in most cases. The only advantage of MT_isPureArray is that with small arrays it has a consistent time and usually a faster time on int arrays. However the average is poor compared to Fixed_isPureArray. The (int)$k !== $k isn't necessary because the $i !== $k checks the type to confirm that they are both ints and the same value.

  Right, after running all the tests again (after fixing them), Fixed_isPureArray runs best in most cases. The only advantage of MT_isPureArray is that with small arrays it has a consistent time and usually a faster time on int arrays. However the average is poor compared to Fixed_isPureArray. The (int)$k !== $k isn't necessary because the $i !== $k checks the type to confirm that they are both ints and the same value.
• Sep 24, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by mike.benoit   -   Running each test more times just helps if each iteration the times fluctuate wildly, which they would if you test with a smaller array (ie: 10,000 elements vs 100,000). But testing with a larger array will not only test the algorithms more for worst case scenarios, but it will also smooth out those fluctuations. Testing with 500,000 element array 10x each, I get between 50 and 100ms fluctuation on my average time between runs, so its pretty consistent. Anyways, the Fixed_isPureArray will likely work, off the top of my head I can't come up with a scenario where it fails, but I noticed the (int)$k !== $k check in Zend_AMF or AMFPHP if I recall, so I figured it was worth keeping given the 5% performance difference with such a huge array and all. I think your MT_isPureArray() and Hybrid approach, while interesting, isn't going to gain us anything, for the simple fact that MT_isPureArray() is slower than even isPureArray() in every test I can throw at it. I think if you reduce the times each test is run, you will find there is almost more overhead in calling the functions as the functions take to run themselves, again especially if your test array is so small.

  Running each test more times just helps if each iteration the times fluctuate wildly, which they would if you test with a smaller array (ie: 10,000 elements vs 100,000). But testing with a larger array will not only test the algorithms more for worst case scenarios, but it will also smooth out those fluctuations. Testing with 500,000 element array 10x each, I get between 50 and 100ms fluctuation on my average time between runs, so its pretty consistent. Anyways, the Fixed_isPureArray will likely work, off the top of my head I can't come up with a scenario where it fails, but I noticed the (int)$k !== $k check in Zend_AMF or AMFPHP if I recall, so I figured it was worth keeping given the 5% performance difference with such a huge array and all. I think your MT_isPureArray() and Hybrid approach, while interesting, isn't going to gain us anything, for the simple fact that MT_isPureArray() is slower than even isPureArray() in every test I can throw at it. I think if you reduce the times each test is run, you will find there is almost more overhead in calling the functions as the functions take to run themselves, again especially if your test array is so small.
• Sep 24, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by msthornton   -   Also, with 100,000 records and strict memory limits (16MB) the test runs out of memory. Trying to be polite with memory usage.

  Also, with 100,000 records and strict memory limits (16MB) the test runs out of memory. Trying to be polite with memory usage.
• Sep 24, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by msthornton   -   I fixed the Hybrid test, was missing the ++$i when I pasted it in. Ran with 1000 tests and 10,000 elements, the Fixed_isPureArray runs best on average. Running tests for isPureArray... - isPureArray with MixedArray : 1.5016 - isPureArray with IntArray : 7.3355 - isPureArray with SparseIntArray : 9.2348 - isPureArray with StringArray : 2.0071 - isPureArray with MixedAfterHalfArray : 4.4503 - isPureArray with SparseAfterHalfArray: 5.5540 Running validity tests... - isPureArray with MixedArray validity test PASSED - isPureArray with IntArray validity test PASSED - isPureArray with SparseIntArray validity test FAIL - isPureArray with StringArray validity test PASSED - isPureArray with MixedAfterHalfArray validity test PASSED - isPureArray with SparseAfterHalfArray validity test FAIL AVERAGE: 5.0139, min: 1.5016, max: 9.2348 ---------------------- Running tests for Fixed_isPureArray... - Fixed_isPureArray with MixedArray : 1.5369 - Fixed_isPureArray with IntArray : 7.5203 - Fixed_isPureArray with SparseIntArray : 1.2974 - Fixed_isPureArray with StringArray : 1.9026 - Fixed_isPureArray with MixedAfterHalfArray : 4.4443 - Fixed_isPureArray with SparseAfterHalfArray: 3.6789 Running validity tests... - Fixed_isPureArray with MixedArray validity test PASSED - Fixed_isPureArray with IntArray validity test PASSED - Fixed_isPureArray with SparseIntArray validity test PASSED - Fixed_isPureArray with StringArray validity test PASSED - Fixed_isPureArray with MixedAfterHalfArray validity test PASSED - Fixed_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 3.3967, min: 1.2974, max: 7.5203 ---------------------- Running tests for MT_isPureArray... - MT_isPureArray with MixedArray : 6.2092 - MT_isPureArray with IntArray : 5.7315 - MT_isPureArray with SparseIntArray : 5.3487 - MT_isPureArray with StringArray : 6.7606 - MT_isPureArray with MixedAfterHalfArray : 6.3581 - MT_isPureArray with SparseAfterHalfArray: 3.6392 Running validity tests... - MT_isPureArray with MixedArray validity test PASSED - MT_isPureArray with IntArray validity test PASSED - MT_isPureArray with SparseIntArray validity test PASSED - MT_isPureArray with StringArray validity test PASSED - MT_isPureArray with MixedAfterHalfArray validity test PASSED - MT_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 5.6745, min: 3.6392, max: 6.7606 ---------------------- Running tests for For_isPureArray... - For_isPureArray with MixedArray : 2.9505 - For_isPureArray with IntArray : 7.6639 - For_isPureArray with SparseIntArray : 2.2478 - For_isPureArray with StringArray : 3.3217 - For_isPureArray with MixedAfterHalfArray : 5.4210 - For_isPureArray with SparseAfterHalfArray: 4.3937 Running validity tests... - For_isPureArray with MixedArray validity test PASSED - For_isPureArray with IntArray validity test PASSED - For_isPureArray with SparseIntArray validity test PASSED - For_isPureArray with StringArray validity test PASSED - For_isPureArray with MixedAfterHalfArray validity test PASSED - For_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 4.3331, min: 2.2478, max: 7.6639 ---------------------- Running tests for Hybrid_isPureArray... - Hybrid_isPureArray with MixedArray : 1.4375 - Hybrid_isPureArray with IntArray : 6.9443 - Hybrid_isPureArray with SparseIntArray : 1.4479 - Hybrid_isPureArray with StringArray : 1.8540 - Hybrid_isPureArray with MixedAfterHalfArray : 7.5628 - Hybrid_isPureArray with SparseAfterHalfArray: 4.5184 Running validity tests... - Hybrid_isPureArray with MixedArray validity test PASSED - Hybrid_isPureArray with IntArray validity test PASSED - Hybrid_isPureArray with SparseIntArray validity test PASSED - Hybrid_isPureArray with StringArray validity test PASSED - Hybrid_isPureArray with MixedAfterHalfArray validity test PASSED - Hybrid_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 3.9608, min: 1.4375, max: 7.5628 ----------------------

  I fixed the Hybrid test, was missing the ++$i when I pasted it in. Ran with 1000 tests and 10,000 elements, the Fixed_isPureArray runs best on average. Running tests for isPureArray... - isPureArray with MixedArray : 1.5016 - isPureArray with IntArray : 7.3355 - isPureArray with SparseIntArray : 9.2348 - isPureArray with StringArray : 2.0071 - isPureArray with MixedAfterHalfArray : 4.4503 - isPureArray with SparseAfterHalfArray: 5.5540 Running validity tests... - isPureArray with MixedArray validity test PASSED - isPureArray with IntArray validity test PASSED - isPureArray with SparseIntArray validity test FAIL - isPureArray with StringArray validity test PASSED - isPureArray with MixedAfterHalfArray validity test PASSED - isPureArray with SparseAfterHalfArray validity test FAIL AVERAGE: 5.0139, min: 1.5016, max: 9.2348 ---------------------- Running tests for Fixed_isPureArray... - Fixed_isPureArray with MixedArray : 1.5369 - Fixed_isPureArray with IntArray : 7.5203 - Fixed_isPureArray with SparseIntArray : 1.2974 - Fixed_isPureArray with StringArray : 1.9026 - Fixed_isPureArray with MixedAfterHalfArray : 4.4443 - Fixed_isPureArray with SparseAfterHalfArray: 3.6789 Running validity tests... - Fixed_isPureArray with MixedArray validity test PASSED - Fixed_isPureArray with IntArray validity test PASSED - Fixed_isPureArray with SparseIntArray validity test PASSED - Fixed_isPureArray with StringArray validity test PASSED - Fixed_isPureArray with MixedAfterHalfArray validity test PASSED - Fixed_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 3.3967, min: 1.2974, max: 7.5203 ---------------------- Running tests for MT_isPureArray... - MT_isPureArray with MixedArray : 6.2092 - MT_isPureArray with IntArray : 5.7315 - MT_isPureArray with SparseIntArray : 5.3487 - MT_isPureArray with StringArray : 6.7606 - MT_isPureArray with MixedAfterHalfArray : 6.3581 - MT_isPureArray with SparseAfterHalfArray: 3.6392 Running validity tests... - MT_isPureArray with MixedArray validity test PASSED - MT_isPureArray with IntArray validity test PASSED - MT_isPureArray with SparseIntArray validity test PASSED - MT_isPureArray with StringArray validity test PASSED - MT_isPureArray with MixedAfterHalfArray validity test PASSED - MT_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 5.6745, min: 3.6392, max: 6.7606 ---------------------- Running tests for For_isPureArray... - For_isPureArray with MixedArray : 2.9505 - For_isPureArray with IntArray : 7.6639 - For_isPureArray with SparseIntArray : 2.2478 - For_isPureArray with StringArray : 3.3217 - For_isPureArray with MixedAfterHalfArray : 5.4210 - For_isPureArray with SparseAfterHalfArray: 4.3937 Running validity tests... - For_isPureArray with MixedArray validity test PASSED - For_isPureArray with IntArray validity test PASSED - For_isPureArray with SparseIntArray validity test PASSED - For_isPureArray with StringArray validity test PASSED - For_isPureArray with MixedAfterHalfArray validity test PASSED - For_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 4.3331, min: 2.2478, max: 7.6639 ---------------------- Running tests for Hybrid_isPureArray... - Hybrid_isPureArray with MixedArray : 1.4375 - Hybrid_isPureArray with IntArray : 6.9443 - Hybrid_isPureArray with SparseIntArray : 1.4479 - Hybrid_isPureArray with StringArray : 1.8540 - Hybrid_isPureArray with MixedAfterHalfArray : 7.5628 - Hybrid_isPureArray with SparseAfterHalfArray: 4.5184 Running validity tests... - Hybrid_isPureArray with MixedArray validity test PASSED - Hybrid_isPureArray with IntArray validity test PASSED - Hybrid_isPureArray with SparseIntArray validity test PASSED - Hybrid_isPureArray with StringArray validity test PASSED - Hybrid_isPureArray with MixedAfterHalfArray validity test PASSED - Hybrid_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 3.9608, min: 1.4375, max: 7.5628 ----------------------
• Sep 24, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by msthornton   -   The point was to get enough variation to eliminate CPU/RAM usage from the test. Running it more times than 10 provides better timing results. Try 1000 times with 10,000 elements. Sorry, didn't notice the FAILED on Hybrid, changed the text to "FAIL" to make it more clear and investigating.

  The point was to get enough variation to eliminate CPU/RAM usage from the test. Running it more times than 10 provides better timing results. Try 1000 times with 10,000 elements. Sorry, didn't notice the FAILED on Hybrid, changed the text to "FAIL" to make it more clear and investigating.
• Sep 24, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by mike.benoit   -   Your benchmark is a little confusing, it runs each test 10,000 times with a 1000 element array. I don't see the point in running each test that often, so I changed it to run each test 10x with a 100,000 element array instead. Hybrid_isPureArray fails the IntArray test, and I'm not convinced that your Fixed_isPureArray is fully bug proof either, I will do more testing...

  Your benchmark is a little confusing, it runs each test 10,000 times with a 1000 element array. I don't see the point in running each test that often, so I changed it to run each test 10x with a 100,000 element array instead. Hybrid_isPureArray fails the IntArray test, and I'm not convinced that your Fixed_isPureArray is fully bug proof either, I will do more testing...
• Sep 24, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by msthornton   -   I see comment #19 now. The or isn't actually needed since `if ( $k !== $i )` is sufficient.

  I see comment #19 now. The or isn't actually needed since `if ( $k !== $i )` is sufficient.
• Sep 24, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by msthornton   -   I'm running it 10000 times with 1000 elements. Only running once with 1000 elements doesn't offer much time to judge by.

  I'm running it 10000 times with 1000 elements. Only running once with 1000 elements doesn't offer much time to judge by.
• Sep 24, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by mike.benoit   -   isPureArray actually had a bug in it that was pointed out by me in comment #19, but unfortunately never got fixed when the patch was committed to SVN. I have committed a fix for it now. I will look over your benchmark, something seems strange with it though, as in my tests isPureArray never took anywhere near 2 seconds to run.

  isPureArray actually had a bug in it that was pointed out by me in comment #19, but unfortunately never got fixed when the patch was committed to SVN. I have committed a fix for it now. I will look over your benchmark, something seems strange with it though, as in my tests isPureArray never took anywhere near 2 seconds to run.
• Sep 24, 2009

  r247 (Fix bug in isPureArray mentioned in comment #19 of issue #14...) committed by mike.benoit   -   Fix bug in isPureArray mentioned in comment #19 of issue #14 that slipped by in all the discussion.

  Fix bug in isPureArray mentioned in comment #19 of issue #14 that slipped by in all the discussion.
• Sep 24, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by msthornton   -   So I was talking about different issues. I'm mainly focusing on AMF3. The isPureArray has a bug for detecting sparse arrays, and it can be quite slow with large sets of int arrays. I've attached a fix and tests with several approaches to performance. The Hybrid approach turns out to be the best in all cases. Here are my results: Running tests for isPureArray... - isPureArray with MixedArray : 1.0467 - isPureArray with IntArray : 6.7537 - isPureArray with SparseIntArray : 7.6607 - isPureArray with StringArray : 1.0184 - isPureArray with MixedAfterHalfArray : 3.9293 - isPureArray with SparseAfterHalfArray: 5.3279 Running validity tests... - isPureArray with MixedArray validity test PASSED - isPureArray with IntArray validity test PASSED - isPureArray with SparseIntArray validity test FAILED - isPureArray with StringArray validity test PASSED - isPureArray with MixedAfterHalfArray validity test PASSED - isPureArray with SparseAfterHalfArray validity test FAILED AVERAGE: 4.2895, min: 1.0184, max: 7.6607 ---------------------- Running tests for Fixed_isPureArray... - Fixed_isPureArray with MixedArray : 0.9917 - Fixed_isPureArray with IntArray : 6.5822 - Fixed_isPureArray with SparseIntArray : 0.7397 - Fixed_isPureArray with StringArray : 1.0283 - Fixed_isPureArray with MixedAfterHalfArray : 3.8250 - Fixed_isPureArray with SparseAfterHalfArray: 3.4929 Running validity tests... - Fixed_isPureArray with MixedArray validity test PASSED - Fixed_isPureArray with IntArray validity test PASSED - Fixed_isPureArray with SparseIntArray validity test PASSED - Fixed_isPureArray with StringArray validity test PASSED - Fixed_isPureArray with MixedAfterHalfArray validity test PASSED - Fixed_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 2.7766, min: 0.7397, max: 6.5822 ---------------------- Running tests for MT_isPureArray... - MT_isPureArray with MixedArray : 4.5757 - MT_isPureArray with IntArray : 4.6140 - MT_isPureArray with SparseIntArray : 4.5444 - MT_isPureArray with StringArray : 5.5690 - MT_isPureArray with MixedAfterHalfArray : 5.0308 - MT_isPureArray with SparseAfterHalfArray: 2.8704 Running validity tests... - MT_isPureArray with MixedArray validity test PASSED - MT_isPureArray with IntArray validity test PASSED - MT_isPureArray with SparseIntArray validity test PASSED - MT_isPureArray with StringArray validity test PASSED - MT_isPureArray with MixedAfterHalfArray validity test PASSED - MT_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 4.5341, min: 2.8704, max: 5.5690 ---------------------- Running tests for For_isPureArray... - For_isPureArray with MixedArray : 2.2816 - For_isPureArray with IntArray : 7.2355 - For_isPureArray with SparseIntArray : 1.6775 - For_isPureArray with StringArray : 2.5190 - For_isPureArray with MixedAfterHalfArray : 4.7890 - For_isPureArray with SparseAfterHalfArray: 3.8579 Running validity tests... - For_isPureArray with MixedArray validity test PASSED - For_isPureArray with IntArray validity test PASSED - For_isPureArray with SparseIntArray validity test PASSED - For_isPureArray with StringArray validity test PASSED - For_isPureArray with MixedAfterHalfArray validity test PASSED - For_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 3.7267, min: 1.6775, max: 7.2355 ---------------------- Running tests for Hybrid_isPureArray... - Hybrid_isPureArray with MixedArray : 0.9936 - Hybrid_isPureArray with IntArray : 0.9236 - Hybrid_isPureArray with SparseIntArray : 0.9323 - Hybrid_isPureArray with StringArray : 1.0336 - Hybrid_isPureArray with MixedAfterHalfArray : 0.8976 - Hybrid_isPureArray with SparseAfterHalfArray: 0.6206 Running validity tests... - Hybrid_isPureArray with MixedArray validity test PASSED - Hybrid_isPureArray with IntArray validity test FAILED - Hybrid_isPureArray with SparseIntArray validity test PASSED - Hybrid_isPureArray with StringArray validity test PASSED - Hybrid_isPureArray with MixedAfterHalfArray validity test PASSED - Hybrid_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 0.9002, min: 0.6206, max: 1.0336 ----------------------

  So I was talking about different issues. I'm mainly focusing on AMF3. The isPureArray has a bug for detecting sparse arrays, and it can be quite slow with large sets of int arrays. I've attached a fix and tests with several approaches to performance. The Hybrid approach turns out to be the best in all cases. Here are my results: Running tests for isPureArray... - isPureArray with MixedArray : 1.0467 - isPureArray with IntArray : 6.7537 - isPureArray with SparseIntArray : 7.6607 - isPureArray with StringArray : 1.0184 - isPureArray with MixedAfterHalfArray : 3.9293 - isPureArray with SparseAfterHalfArray: 5.3279 Running validity tests... - isPureArray with MixedArray validity test PASSED - isPureArray with IntArray validity test PASSED - isPureArray with SparseIntArray validity test FAILED - isPureArray with StringArray validity test PASSED - isPureArray with MixedAfterHalfArray validity test PASSED - isPureArray with SparseAfterHalfArray validity test FAILED AVERAGE: 4.2895, min: 1.0184, max: 7.6607 ---------------------- Running tests for Fixed_isPureArray... - Fixed_isPureArray with MixedArray : 0.9917 - Fixed_isPureArray with IntArray : 6.5822 - Fixed_isPureArray with SparseIntArray : 0.7397 - Fixed_isPureArray with StringArray : 1.0283 - Fixed_isPureArray with MixedAfterHalfArray : 3.8250 - Fixed_isPureArray with SparseAfterHalfArray: 3.4929 Running validity tests... - Fixed_isPureArray with MixedArray validity test PASSED - Fixed_isPureArray with IntArray validity test PASSED - Fixed_isPureArray with SparseIntArray validity test PASSED - Fixed_isPureArray with StringArray validity test PASSED - Fixed_isPureArray with MixedAfterHalfArray validity test PASSED - Fixed_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 2.7766, min: 0.7397, max: 6.5822 ---------------------- Running tests for MT_isPureArray... - MT_isPureArray with MixedArray : 4.5757 - MT_isPureArray with IntArray : 4.6140 - MT_isPureArray with SparseIntArray : 4.5444 - MT_isPureArray with StringArray : 5.5690 - MT_isPureArray with MixedAfterHalfArray : 5.0308 - MT_isPureArray with SparseAfterHalfArray: 2.8704 Running validity tests... - MT_isPureArray with MixedArray validity test PASSED - MT_isPureArray with IntArray validity test PASSED - MT_isPureArray with SparseIntArray validity test PASSED - MT_isPureArray with StringArray validity test PASSED - MT_isPureArray with MixedAfterHalfArray validity test PASSED - MT_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 4.5341, min: 2.8704, max: 5.5690 ---------------------- Running tests for For_isPureArray... - For_isPureArray with MixedArray : 2.2816 - For_isPureArray with IntArray : 7.2355 - For_isPureArray with SparseIntArray : 1.6775 - For_isPureArray with StringArray : 2.5190 - For_isPureArray with MixedAfterHalfArray : 4.7890 - For_isPureArray with SparseAfterHalfArray: 3.8579 Running validity tests... - For_isPureArray with MixedArray validity test PASSED - For_isPureArray with IntArray validity test PASSED - For_isPureArray with SparseIntArray validity test PASSED - For_isPureArray with StringArray validity test PASSED - For_isPureArray with MixedAfterHalfArray validity test PASSED - For_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 3.7267, min: 1.6775, max: 7.2355 ---------------------- Running tests for Hybrid_isPureArray... - Hybrid_isPureArray with MixedArray : 0.9936 - Hybrid_isPureArray with IntArray : 0.9236 - Hybrid_isPureArray with SparseIntArray : 0.9323 - Hybrid_isPureArray with StringArray : 1.0336 - Hybrid_isPureArray with MixedAfterHalfArray : 0.8976 - Hybrid_isPureArray with SparseAfterHalfArray: 0.6206 Running validity tests... - Hybrid_isPureArray with MixedArray validity test PASSED - Hybrid_isPureArray with IntArray validity test FAILED - Hybrid_isPureArray with SparseIntArray validity test PASSED - Hybrid_isPureArray with StringArray validity test PASSED - Hybrid_isPureArray with MixedAfterHalfArray validity test PASSED - Hybrid_isPureArray with SparseAfterHalfArray validity test PASSED AVERAGE: 0.9002, min: 0.6206, max: 1.0336 ----------------------
• Sep 23, 2009

  issue 15 (Expose additional request information to the callback functi...) commented on by evertpot   -   I was actually really just talking about that one class. I must say I have interest in a possible 2.0 version, but I don't see this happening within the next 6 months. As of right now I only want to fix bugs, and not add on any new features. If you strongly feel the need to fork the current codebase to add things like AMFEXT, I would be in no way offended as I understand how annoying this must be. I personally just feel I can't spend the time working on this project unfunded in the short-term. I do feel strongly about keeping the current codebase as-is, and staying in control of it. I'm hesitant making even small changes, because I don't have the time and resources to do any real testing.

  I was actually really just talking about that one class. I must say I have interest in a possible 2.0 version, but I don't see this happening within the next 6 months. As of right now I only want to fix bugs, and not add on any new features. If you strongly feel the need to fork the current codebase to add things like AMFEXT, I would be in no way offended as I understand how annoying this must be. I personally just feel I can't spend the time working on this project unfunded in the short-term. I do feel strongly about keeping the current codebase as-is, and staying in control of it. I'm hesitant making even small changes, because I don't have the time and resources to do any real testing.
• Sep 23, 2009

  issue 15 (Expose additional request information to the callback functi...) commented on by mike.benoit   -   Are you proposing that SabreAMF is effectively "dead" when it comes to additional features? Do you suggest that we fork SabreAMF into an entirely new project in order to further enhance and improve it? The patches we have submitted so far are just the tip of the iceberg, we have many more already completed and are starting to look at other more intrusive things like supporting AMFEXT and such. We very much consider this to be a long-term on-going project. We would much rather work with you and contribute these changes back to SabreAMF, but I can understand if this is not your plan for it.

  Are you proposing that SabreAMF is effectively "dead" when it comes to additional features? Do you suggest that we fork SabreAMF into an entirely new project in order to further enhance and improve it? The patches we have submitted so far are just the tip of the iceberg, we have many more already completed and are starting to look at other more intrusive things like supporting AMFEXT and such. We very much consider this to be a long-term on-going project. We would much rather work with you and contribute these changes back to SabreAMF, but I can understand if this is not your plan for it.
• Sep 23, 2009

  issue 15 (Expose additional request information to the callback functi...) commented on by evertpot   -   I would say just fork the class.. I understand where you're coming from, but I'd really like to try to keep changes to an absolute minimum.

  I would say just fork the class.. I understand where you're coming from, but I'd really like to try to keep changes to an absolute minimum.
• Sep 23, 2009

  issue 15 (Expose additional request information to the callback functi...) commented on by mike.benoit   -   We would need to overload the Exec() and invokeService() functions to do this though, and that contains a significant portion (over 60%) of the code in the CallBack server class. It would be much easier to maintain our own fork with the attached 3 line patch. I was trying to see if there was a way to access the SabreAMF object and obtain the information directly from the callback function, but I wasn't able to come up with anything as clean as the attached patch. I mean we could refactor Exec() slightly to put another function between it and invokeService, to it could then be easily overloaded, but we still need to expose that data at some point. This method seems like it would take more code and be slower than the attached patch. Do you have any other ideas perhaps? There is actually quite a bit of information contained in the AMF protocol that is exposed and easily accessible from Flex that can be incredibly useful. messageId is just one of those values that is most useful to us at this point, but it just seems to make sense that if Flex can access this information that the server should be able to as well.

  We would need to overload the Exec() and invokeService() functions to do this though, and that contains a significant portion (over 60%) of the code in the CallBack server class. It would be much easier to maintain our own fork with the attached 3 line patch. I was trying to see if there was a way to access the SabreAMF object and obtain the information directly from the callback function, but I wasn't able to come up with anything as clean as the attached patch. I mean we could refactor Exec() slightly to put another function between it and invokeService, to it could then be easily overloaded, but we still need to expose that data at some point. This method seems like it would take more code and be slower than the attached patch. Do you have any other ideas perhaps? There is actually quite a bit of information contained in the AMF protocol that is exposed and easily accessible from Flex that can be incredibly useful. messageId is just one of those values that is most useful to us at this point, but it just seems to make sense that if Flex can access this information that the server should be able to as well.
• Sep 23, 2009

  issue 15 (Expose additional request information to the callback functi...) commented on by evertpot   -   Hi Mike, Since this is a pretty easy change, and right near the edge of the system (callbackserver), I would suggest just subclassing the callbackserver, and overriding this function. I don't really see a need to add this for everybody..

  Hi Mike, Since this is a pretty easy change, and right near the edge of the system (callbackserver), I would suggest just subclassing the callbackserver, and overriding this function. I don't really see a need to add this for everybody..
• Sep 23, 2009

  issue 13 (Send arrays and call_user_func_array() conflict?) commented on by evertpot   -   Saw it, thanks!

  Saw it, thanks!
• Sep 23, 2009

  issue 15 (Expose additional request information to the callback functi...) reported by mike.benoit   -   With our project we need to carry out a lot of async calls to the server, so the server needs to utilize shared memory to share data between these calls in many cases. As an example, our Flex client will often request the server to carry out a lengthly process in one connection, then constantly check the progress of it in another connection to report back to the user. Luckily AMF3 attaches a GUID to each request/message, which is ideally suited for this situation as the both the client and server know the messageId and thus can be used as a basis for a unique lookup key. However SabreAMF doesn't expose that information through the invokeService callback function. As such I propose adding an additional "$extras" argument to invokeService where we can pass any additional information that we need to now, and in the future. I did some quick testing and it appears as though call_user_func_array() will ignore additional arguments, so this change should be 100% backwards compatible. In the attached patch for review, my question is if I should restrict what data is passed along as the "$extras" array, should we send along as much information as possible now, or should we take an entirely different approach to exposing this information?

  With our project we need to carry out a lot of async calls to the server, so the server needs to utilize shared memory to share data between these calls in many cases. As an example, our Flex client will often request the server to carry out a lengthly process in one connection, then constantly check the progress of it in another connection to report back to the user. Luckily AMF3 attaches a GUID to each request/message, which is ideally suited for this situation as the both the client and server know the messageId and thus can be used as a basis for a unique lookup key. However SabreAMF doesn't expose that information through the invokeService callback function. As such I propose adding an additional "$extras" argument to invokeService where we can pass any additional information that we need to now, and in the future. I did some quick testing and it appears as though call_user_func_array() will ignore additional arguments, so this change should be 100% backwards compatible. In the attached patch for review, my question is if I should restrict what data is passed along as the "$extras" array, should we send along as much information as possible now, or should we take an entirely different approach to exposing this information?
• Sep 23, 2009

  issue 13 (Send arrays and call_user_func_array() conflict?) commented on by mike.benoit   -   This is committed as #246: http://code.google.com/p/sabreamf/source/detail?r=246

  This is committed as #246: http://code.google.com/p/sabreamf/source/detail?r=246
• Sep 23, 2009

  r246 (Reference to Issue 13: Add SABREAMF_AMF3_PRESERVE_ARGUMENTS ...) committed by mike.benoit   -   Reference to Issue 13: Add SABREAMF_AMF3_PRESERVE_ARGUMENTS define argument to allow arrays to be passed directly to call_user_func_array without losing the first level of keys. Default to disabled to preserve backwards compatibility.

  Reference to Issue 13: Add SABREAMF_AMF3_PRESERVE_ARGUMENTS define argument to allow arrays to be passed directly to call_user_func_array without losing the first level of keys. Default to disabled to preserve backwards compatibility.
• Sep 22, 2009

  issue 13 (Send arrays and call_user_func_array() conflict?) commented on by evertpot   -   I added you to the contributor list! thank you sir!

  I added you to the contributor list! thank you sir!
• Sep 22, 2009

  issue 13 (Send arrays and call_user_func_array() conflict?) commented on by mike.benoit   -   It definitely would be if you'd prefer to have me directly check-in my changes rather than post the patches here.

  It definitely would be if you'd prefer to have me directly check-in my changes rather than post the patches here.
• Sep 22, 2009

  issue 13 (Send arrays and call_user_func_array() conflict?) commented on by evertpot   -   Also.. would it be helpful for you to have svn access?

  Also.. would it be helpful for you to have svn access?
• Sep 22, 2009

  issue 13 (Send arrays and call_user_func_array() conflict?) commented on by evertpot   -   yes! SABREAMF_AMF3_PRESERVE_ARGUMENTS

  yes! SABREAMF_AMF3_PRESERVE_ARGUMENTS
• Sep 22, 2009

  issue 13 (Send arrays and call_user_func_array() conflict?) commented on by mike.benoit   -   Thats better than any of my suggestions so far, do you prefer any of these: SABREAMF_AMF3_PRESERVE_ARRAYS SABREAMF_AMF3_PRESERVE_ARGUMENTS I don't really care either way, it would just be nice to come up with a name that suits the function as close as possible.

  Thats better than any of my suggestions so far, do you prefer any of these: SABREAMF_AMF3_PRESERVE_ARRAYS SABREAMF_AMF3_PRESERVE_ARGUMENTS I don't really care either way, it would just be nice to come up with a name that suits the function as close as possible.
• Sep 22, 2009

  issue 13 (Send arrays and call_user_func_array() conflict?) commented on by evertpot   -   Mike, I tend to agree with you; but for the same reason you mentioned I'd also prefer staying consistent. If you'd look at some of my newer code, you wouldn't find any defines. Since the bug is basically not getting the 'true' list of arguments (e.g.: wrapped in an array) in AMF3, how about something like: How about SABREAMF_AMF3_ALL_ARGUMENTS

  Mike, I tend to agree with you; but for the same reason you mentioned I'd also prefer staying consistent. If you'd look at some of my newer code, you wouldn't find any defines. Since the bug is basically not getting the 'true' list of arguments (e.g.: wrapped in an array) in AMF3, how about something like: How about SABREAMF_AMF3_ALL_ARGUMENTS
• Sep 22, 2009

  issue 13 (Send arrays and call_user_func_array() conflict?) commented on by mike.benoit   -   Okay, I'm not a big fan of using defines like this, rather than just setting an object variable, but sometimes its just better to keep things consistent. Any suggestions for a name? SABREAMF_CALL_USER_FUNC_ARRAY SABREAMF_CALL_USER_FUNC_COMPAT SABREAMF_RAW_ARRAY SABREAMF_RAW_ARRAY_HANDLING

  Okay, I'm not a big fan of using defines like this, rather than just setting an object variable, but sometimes its just better to keep things consistent. Any suggestions for a name? SABREAMF_CALL_USER_FUNC_ARRAY SABREAMF_CALL_USER_FUNC_COMPAT SABREAMF_RAW_ARRAY SABREAMF_RAW_ARRAY_HANDLING
• Sep 22, 2009

  issue 4 (Feature request: AMFEXT) commented on by evertpot   -   I have personally simply lost interest in adding any new features. A feature as big as this will definitely take some time I just can't afford at this moment. I've committed to fix bugs as they come along, as a big thank you for the people using it; but the addition of AMFEXT is just too big for me right now.

  I have personally simply lost interest in adding any new features. A feature as big as this will definitely take some time I just can't afford at this moment. I've committed to fix bugs as they come along, as a big thank you for the people using it; but the addition of AMFEXT is just too big for me right now.
• Sep 22, 2009

  issue 13 (Send arrays and call_user_func_array() conflict?) commented on by evertpot   -   Mike, SabreAMF already has one other behaviour changing option, namely: SABREAMF_OBJECT_AS_ARRAY if this is set, it will treat objects as arrays. If you want to do a similar approach for this different array behaviour, I'll accept the patch. If there's ever going to be a 2.0, the behaviour you're looking for will definitely be the default.

  Mike, SabreAMF already has one other behaviour changing option, namely: SABREAMF_OBJECT_AS_ARRAY if this is set, it will treat objects as arrays. If you want to do a similar approach for this different array behaviour, I'll accept the patch. If there's ever going to be a 2.0, the behaviour you're looking for will definitely be the default.
• Sep 22, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by evertpot   -   Mike: Committed the latest patch

  Mike: Committed the latest patch
• Sep 22, 2009

  r245 (Adding PureArray patch to AMF0 as well. 'nother patch from m...) committed by evertpot   -   Adding PureArray patch to AMF0 as well. 'nother patch from mike

  Adding PureArray patch to AMF0 as well. 'nother patch from mike
• Sep 18, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by msthornton   -   Sorry, I jumped the gun and was fixing a symptom of a different problem. Your fix works much better, thanks!

  Sorry, I jumped the gun and was fixing a symptom of a different problem. Your fix works much better, thanks!
• Sep 18, 2009

  issue 4 (Feature request: AMFEXT) commented on by mike.benoit   -   Has there been any additional progress made on this front? I'm really interested in getting SabreAMF to work with AMFEXT as well.

  Has there been any additional progress made on this front? I'm really interested in getting SabreAMF to work with AMFEXT as well.
• Sep 18, 2009

  issue 13 (Send arrays and call_user_func_array() conflict?) commented on by mike.benoit   -   Looking at this issue a little more it appears that SabreAMF goes out of its way to make array handling incompatible with call_user_func_array() by silently dropping data. I'm not sure we can support both the existing case and the proposed new behavior automatically without adding a bunch more overhead, so instead would you be willing to compromise on a config setting that would make array handling compatible with call_user_func_array? This way we can preserve 100% backward compatibility and at least give others the option. I can't see any non-SabreAMF work-around that isn't going to be slow or error prone. The question is what is the best method to have the developer set this option and get it passed through to the message handler? Should we just duplicate the same method that onInvoiceService is set?

  Looking at this issue a little more it appears that SabreAMF goes out of its way to make array handling incompatible with call_user_func_array() by silently dropping data. I'm not sure we can support both the existing case and the proposed new behavior automatically without adding a bunch more overhead, so instead would you be willing to compromise on a config setting that would make array handling compatible with call_user_func_array? This way we can preserve 100% backward compatibility and at least give others the option. I can't see any non-SabreAMF work-around that isn't going to be slow or error prone. The question is what is the best method to have the developer set this option and get it passed through to the message handler? Should we just duplicate the same method that onInvoiceService is set?
• Sep 18, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by mike.benoit   -   Attached is the patch to factor out isPureArray to the main serializer class so it can be used by both AMF0 and AMF3 in the same way. It also includes a minor change (okay, I admit I can be picky sometimes) to the AMF3 writeArray function so the IF statement is a positive rather then negative check. No behavior should change due to this patch, other than making AMF0 be consistent with the way AMF3 works.

  Attached is the patch to factor out isPureArray to the main serializer class so it can be used by both AMF0 and AMF3 in the same way. It also includes a minor change (okay, I admit I can be picky sometimes) to the AMF3 writeArray function so the IF statement is a positive rather then negative check. No behavior should change due to this patch, other than making AMF0 be consistent with the way AMF3 works.
• Sep 18, 2009

  issue 14 (Bug in handling sparse associative arrays.) commented on by evertpot   -   Sounds good!

  Sounds good!