[Red5devs] Offer to the Red5 Community: Continuous building

Thu Oct 2 10:11:32 PDT 2008

Hi folks,

Quick progress report and a question: We now have 96% of all existing
JUnit tests passing successfully all of the time with tip of tree (out
of 126 tests still enabled; I removed some invalid tests and added a
few new ones).  I'll submit the patch later today (will do sooner if
people would rather see the changes to get 96% rather than waiting for
100%).

However, I am running into a lack of understanding on my part with one
of the AMF-IO tests.  In particular, a test that serializes an object
with a circular reference and then deserializes it fails
(AbstractIOTest.java#testCircularReference).  Why?  Because the AMF
reference ID it writes  to the stream for the self-reference is being
adjusted by -1 by the following code when deserializing, but there is
no equivalent adjustment when serializing:

org/red5/io/amf/Input.java: 562-568
	public Object readReference(Type target) {
		if (referenceMode == ReferenceMode.MODE_RTMP) {
			return getReference(buf.getUnsignedShort() - 1);
		} else {
			return getReference(buf.getUnsignedShort());
		}
	}

I've been through the AMF specs and can't figure out why we're doing
this.  However, this code has been in the tree since Joachim's initial
AMF3 implementation:
http://code.google.com/p/red5/source/detail?r=1660&path=/java/server/trunk/src/org/red5/io/amf/Input.java

So I'm assuming that the test is wrong and the server code is right,
but does anyone know why this behavior would be occurring (i.e.
adjusting the AMF's reference ID by -1 when deserializing, while not
doing a +1 when serializing)?

Any suggestions/tips appreciated.

- Art

On Wed, Oct 1, 2008 at 12:31 PM, Thijs Triemstra | Collab
<lists at collab.nl> wrote:
> Hi Art,
>
> I'm happy to do this as patches (although a sandbox area is a lot
> easier for me and keeps traffic off the devs list while I do it; still
> not a big deal).  Another suggestion I have is if someone on the red5
> team wants to be a point person for me I can go through them on
> submissions and avoid polluting the lists with interim patches.
>
> Please post the patches in our bugtracker on http://jira.red5.org to avoid
> 'polluting' the list.
> We now have a dedicated mailinglist for the red5 tickets which you'd might
> want to subscribe to:
> http://groups.google.com/group/red5tickets?hl=en
>
> That said, I disagree that continuous builds aren't really useful
> already for three reasons:
>  First: it did allow us to catch a bug that's been ignored for
> 13-days even with existing tests (ok, admittedly the tests I'm talking
> about checking in).
>
> ;)
>
>  Second: if we don't have anyway to enforce 100% test running the
> existing tests will fall out of compliance quickly.
>  Third: Having it sent up might encourage some folks (like, I don't
> know, maybe Robert and me) to submit tests as a best practice for any
> bugs we fix as part of our submission process.  How's that for
> enticement?
>
> Thijs, can we take offline the generous offer of the ubuntu server?
> I'd love it.  My e-mail is aclarke(at)vlideshow.com.   I would also
> prefer to set this up initially there (I agree it's much more reliable
> that way, plus it keeps non-donated code out of the question).  To get
> this to work no long-term root access is needed, but I will need a
> user account (I usually use 'hudson' for the continuous build), I do
> need to be able to bring up red5 on that server, so other applications
> should not be using ports 5080 and 1935 on that machine, and I will
> need to install hudson to run on startup on a given port (which you
> can specify).  Still, probably better to take this offline.
>
> Sounds good, I'll email you offline (that server in question isn't using
> port 1935, and if it did I could add a new dedicated IP for this builder.
>
>
> As for AsUnit, the trick is how to include the AsUnit ActionScript
> without infecting with GPL.  In our build system here we have the
> source code for AsUnit checked into a tainted tree, and then we
> compile the .as files for AsUnit directly into the resulting test swf
> file from there.  What I'll do for now is create something similar to
> a red5_example application that does everything and then send the
> patch to the list.  This will be a big patch once I get to it.  We can
> then figure out iteratively the best way to integrate it.
>
> Sounds good..
> Thanks,
> Thijs
>
> n Wed, Oct 1, 2008 at 11:57 AM, Thijs Triemstra | Collab
> <lists at collab.nl> wrote:
>
> Hi Art,
>
> Option A) I'd like a continuous Red5 build server that rebuilds the
>
> server whenever a check-in occurs and e-mails the person who checked
>
> in last if the build fails.
>
> Option B) I'd like someone to go through the "ant run-tests" tests and
>
> make them all run successfully
>
> The lack of unit tests has been an issue in Red5 since day one, and it's
>
> unlikely 'someone' will fix it. And continuous builds aren't really useful
>
> when there aren't any unit tests imo. Patches are always welcome! I think
>
> unit tests are more important then documentation at the moment.
>
> Option C) I'd like to have the continuous Red5 build server also run
>
> the Java tests and let folks know if they succeed or fail
>
> Again, there aren't (sufficient) unit tests to make continuous building
>
> useful.
>
> Option D) I'd like a set of standalone flash-based (not RTMP-Client)
>
> unit tests that test connecting to the server, playing back video
>
> files, publishing files, and calling a method on objects, as a way to
>
> do minimal end-to-end validation of a check-in.
>
> Option E) I'd like the continuous build server to execute those
>
> flash-based tests in a headless (i.e. no windows) environment
>
> Option F) I'd like world peace.
>
> :)
>
> Option G) I'd like the continuous build server to auto build of the
>
> javadoc for the server
>
> Good idea. We could do the same for nightly builds. I prefer buildbot
>
> (http://buildbot.net) but this might be less useful for java apps..
>
> If we end up decided to do any of these, all I ask for right now is a
>
> sandbox area I can check code into (asked for username: aclarke).  If
>
> you want grimy details on what I'm proposing, please ready on.
>
> I think it would be best to start out with supplying patches, and posting
>
> them on Jira. As soon as you start overwhelming us with patches, and it
>
> becomes a 'burden' for us, then commit access sounds like a good idea.
>
> <h2>Option A:</H2>
>
> Our continuous server is based on Hudson
>
> (https://hudson.dev.java.net/), and already builds and e-mails us if
>
> the red5 build breaks.  What I'm suggesting is that someone let me
>
> know the e-mails to add to the distribution list, and I'll make it
>
> send e-mails there as well when builds break.  I can also provide
>
> login-accounts for people to browse the hudson server, and will try
>
> initially setting it up so anonymous users can see the results of
>
> builds (but may need to curtail that if load is too high:  Right now
>
> this would be hosted off our dev-server (which is a Fedora 8 box
>
> sitting in my apartment) but if folks have a Linux environment that
>
> they wanted to volunteer I'd be happy to talk offline about making a
>
> more "hardy" version).
>
> I would be able to provide a ubuntu server that lives in a data-center. A
>
> dev-server in an apartment doesn't sound like a good long-term solution.
>
>
> <h2>Option B</h2>
>
> This will require some work but I think it's valuable.  Right now
>
> (after fixing the build file to compile the tests) 64% of unit tests
>
> pass.  My proposal is that we at Vlideshow go through the unit tests
>
> and get us to 100% by either (a) fixing the test (preferred) or (b)
>
> removing the test if it's beyond our ability to fix right now (I'll
>
> e-mail any such cases to the list).
>
> Sounds great. Again, please post patches to Jira so we can evaluate them.
>
> This option is a little tricky as asunit is GPL licensed.  What I'm
>
> proposing is that we make a top-level source directory
>
> svn/test/flash/trunk/autotest/ and in there we'd put our source code
>
> as well as a reference to ASUnit.  This part of the tree would be
>
> GPL-infected, but by organizing it in this way we can assure that
>
> people only get GPL-infected if they decided to go into this area.
>
> You can release the unit tests under the LGPL, like the rest of the
>
> codebase, and still use asunit afaik.
>
> Thanks for the help!
>
> Cheers,
>
> Thijs
>
> _______________________________________________
>
> Red5devs mailing list
>
> Red5devs at osflash.org
>
> http://osflash.org/mailman/listinfo/red5devs_osflash.org
>
>
>
> _______________________________________________
> Red5devs mailing list
> Red5devs at osflash.org
> http://osflash.org/mailman/listinfo/red5devs_osflash.org
>
>
> _______________________________________________
> Red5devs mailing list
> Red5devs at osflash.org
> http://osflash.org/mailman/listinfo/red5devs_osflash.org
>
>