Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: Strange Migration from W2->W3 Problem

  1. #1
    Join Date
    Mar 2011
    Posts
    21

    Question Strange Migration from W2->W3 Problem

    Hi,

    we are runnung a video portal at our university and are on our way to migrate from Wowza2 to Wowz 3.

    Therefore we have some serverside code that worked fine on Wowza2 and also runs perfectly on my own developer Wowza3 servers (Version 3.1.1, one on Mac and one in an Ubuntu VirtualBox), but it makes some trouble on the licenced Wowza3 of our computer center (running in a virtual Machine, OS: Suse Linux Enterprise).

    The Problem:
    It seems as if some operations on shared objects do not perform correct, I get different change events (and expecially less change events) on this Wowza3 than on my own test systems.

    As I only have very limited access to this virtual machine I have to send my ideas for this odd behavoir to an employee at the computer center that performs the changes and reports the results to me. But now I am at a point where I donīt have any clues about what could be a reason.

    So:
    Can anybody give me some ideas? The Version of the server is everywhere 3.1.1, the rights for the directories are identical with our old Wowza3, the Application.xmls are the same as on my (working) testservers, as well as my jar.

    What else could that be? Where are some important settings to check?

    Thanks for every help I can get,

    Treb

  2. #2
    Join Date
    Dec 2007
    Posts
    22,013

    Default

    Treb,

    What kind of difference do you see?

    Richard

  3. #3
    Join Date
    Mar 2011
    Posts
    21

    Default

    For example: There should be a "clear" from the Shared Object (which in fact is received from all other Wowza-Instances), but there is none from this SLES-Wowza. And some changs, which should be made on the SO are not reported to the client (and are maybe not done, unfortunatelly this server is a blackbox for me, I cantīt see whatīs happening there).

    Do you have any ideas?

    Thanks,

    Rob

  4. #4
    Join Date
    Dec 2007
    Posts
    22,013

    Default

    Rob,

    No, I don't know. It could be network problems. If the server is a black-box to you then you can only debug from the client-side.

    For reference there is a sharedObject example in the examples folder that ships with Wowza, and there is this article:
    http://www.wowza.com/forums/content....a-SharedObject

    Richard

  5. #5
    Join Date
    Mar 2011
    Posts
    21

    Default

    Richard,

    now I finally gained SSH-access zu the Server: It seems as if the code is executed properly, no errors are thrown in the debug mode, the execution sequence seems to be correct.

    I did some deeper research in "what is the difference in the server responses":
    In fact, despite my first analysis no message of the SO is lost - they just arrive in a completely different order. This order seems to be deterministic, it is always the same - so it should not be not the result of some runtime condition. But I see no sense in this order: if the original sequence is 1,2,3,4,5,6,7,8,9,10,11 the consistent "wrong" sequence is always 7,8,1,10,4,9,3,5,2,11,6.

    The problem: My jar needs to get the code in correct order...

    What could be the reason for such an chatoic new sequence? Do you have any hint for debuging with my new "root-Powers"?

    Thanks,

    Treb

  6. #6
    Join Date
    Dec 2007
    Posts
    22,013

    Default

    Where/how is the sequence generated, and where/how being read? There may not be a way to change this.

    There is another approach (instead of sharedobjects) for Flash RTMP clients using a mix of NetConnection.call and NetStream.send in the client, and IClient.call, IApplicationInstance.broadcastMsg, and IMediaStream.send (or .sendDirect to record data)

    Take a look at the ServerSideModules example that ships with Wowza, and includes a Flash RTMP client and application module, that is a working reference for Flash RTMP <> Wowza communications.

    Richard

  7. #7
    Join Date
    Mar 2011
    Posts
    21

    Default

    Richard,

    thanks for your quick reply!

    The ServerSideModules example was the blueprint for my serverside module - and the communication works perfectly on Wowza2 and all my own Wowza3 test instances. So the error should not be here.

    The sequence is generated like this:
    SO.lock(); 				
    try {		
    SO.setProperty(PROPERTY_NAME, property_content);
    SO.setProperty(PROPERTY_NAME, property_content);
    .....
    }
    Interesting, but also a bit disturbing: The sequence in which the propertis are set is again different from the client side received sequences (both "right" and "wrong"). But as the order in which Wowza sent the property changes was always the same, this did not cause any trouble.

    It is read by my eventhandler in my Flex-App

    SO.addEventListener( SyncEvent.SYNC, SOSyncHandler);
    A complete rewrite of my code is only the last option - I am working at university and developing code is not my main task. Therefore I hope that the most efficent way to solve this problem is to find the reason why ONLY ONE server sends the SyncEvents in the wrong sequence instead of creating a workaround that has maybe problems with the next Server/Wowza upgrade.

    It seems, that it is the first time, that you encounted such a problem?

    Thanks very much for your thoughts,

    Treb

  8. #8
    Join Date
    Dec 2007
    Posts
    22,013

    Default

    Treb,

    No, I haven't heard any similar reports. If it is one server and others are okay, I would try to compare to debug. Rebuild the app. Perhaps just re-starting Wowza or rebooting the server.

    Richard

  9. #9
    Join Date
    Mar 2011
    Posts
    21

    Default

    Richard,

    ok, Iīll try on - Iīll report when I (hopefully) found the problem.

    Thanks for your suggestions,

    Treb

  10. #10
    Join Date
    Mar 2011
    Posts
    21

    Default

    Richard,

    I think I found the reason for this behavior: A Wowza installed on a Suse Linux Enterprise Server 11.2 seems to send changes on Shared Objects in a different order to the client than a Wowza installed on an Ubuntu Server or a Mac.

    I can easily replicate this behavior by comparing a standard installation of SLES 11.2 (added only the IBM Java Package) an Ubuntu server 12.04. A Wowza 3.1.2 was installed on both systems. All configurations are the same.

    Do you have an explanation for this? Maybe I am not the only one having problems with this behavior.

    Treb

    PS: I tried it on Windows - it has the "Mac/Ubuntu sequence"
    Last edited by TrebWalker; 07-26-2012 at 08:21 AM.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •