Results 1 to 8 of 8

Thread: Wowza api support - is it reliable?

  1. Default Wowza api support - is it reliable?

    We've developed a lot around wowza. We have wowza installed on a couple of servers now.

    But, when it comes to support for API's, it sounds like your support team does not have much knowledge on it. We seem to be diverted to third party consultants and third party tools while our job relies on wowza development. This has happened atleast twice or thrice during our past communications with you. It's frustrating. Are you doing this to escape the burden of providing us support for your own API?

    Just so you know, We're not asking you to teach us JAVA. All our support issues are very specific to wowza API. The developers are also experienced JAVA developers, now much experienced with the wowza IDE as well.

    We have problems with two things right now :
    1. Using information written into wowza logs
    2. Disconnecting live streams of VOD



    UDP is generally unreliable but wowza implementation of logs over UDP is also NOT reliable because it automatically stops sending after a while.
    The problem is not the UDP packets but your logging over UDP. We need your support for our developers to fix these things. We're forced to restart our production servers because of this UDP logging flaw within wowza. If UDP logging is not the solution, then what is the solution for us to consume the data? We initially used it only after your advice that it's a better choice in terms of performance.

    Secondly, we need support for stopping live VOD streams since we need to rename VOD files. One solution that we currently have seems to require looping through every viewer. Your last email reply is suggesting us to use third party tools again. We are not looking for third party tools. We are building custom software using wowza and we need your support


    Please provide us with good support for customizing using wowza API as we continue to expand on wowza servers.

    Thanks.

  2. #2
    Join Date
    Apr 2012
    Posts
    133

    Default Disconnecting all vod streams?

    I followed the link that team gave(ticket #43703) http://www.wowza.com/forums/content....rs-to-a-stream,

    To stop a particular stream:
    String code = "NetStream.Play.Failed";
    String description = "ModuleLimitViewers: Over viewer limit["+this.maxStreamViewers+"]";
    getLogger().info(description);
    sendStreamOnStatusError(stream, code, description);
    It only stop a particular playing stream..

    So I have modified it to stop all the vod streams connected using a particular stream name like following:
    IApplicationInstance applicationInstance = client.getAppInstance();
    Iterator<IMediaStream> streamListIterator = applicationInstance.getPlayStreamsByName(streamName).iterator();
    while(streamListIterator.hasNext()) {
    IMediaStream stream = streamListIterator.next();
    String code = "NetStream.Play.Failed";
    sendStreamOnStatusError(stream, code, description);
    stream.getClient().setShutdownClient(true);
    }

    By this way only i can stop all vod streams to a particular stream name.As this is loop, it lowers the performance. When many clients are playing vod, it become a problem to use a loop to wait get all streams to stop and then renaming. How to stop vod file when playing? If we click stop in encoder, live streams are stopped using wowza . Likewise how to stop vod files using wowza.Please help us to solve this

    Thanks

  3. #3

    Default

    Hi,

    We are not in a position to provide custom development support directly. Due to the vast number of ways it is possible to do things in Wowza providing detailed support on custom code is just impossible.

    For example a method to stop people accessing a specific file, could be to use the AliasProvider with additional hooks to put in filenames which should no longer be accessed, so when the last remaining clients drop off it could be deleted. You have been pointed to a routine which will find and remove clients, again a reasonable way to do this. Iterating through the clients should not add any significant load.

    We can, and it appears, have provided direction how to solve the specific question you had and as you have significant Java expertise appears you have implmented it.

    Regarding the logging issue, without more details directly it is impossible to say, however I personally would log to each server then collate the logs after each 24 hours, or add in hooks for each event, onConnect/onPlay/onHTTPSessionCreate etc etc, which log to a specific location, lets say via a HTTP call. There are modules which provide this functionality (non Wowza ones) or given your obvious experience with Java add some very simple code in yourself.

    Andrew.

  4. #4
    Join Date
    Apr 2012
    Posts
    133

    Default

    Quote Originally Posted by andrew_k View Post

    onConnect/onPlay/onHTTPSessionCreate etc etc, which log to a specific location, lets say via a HTTP call.

    Andrew.
    I can understand that i have to use onConnect/onPlay/onHTTPSessionCreate etc etc which log to a specific location, lets say via a HTTP call. If I use like this, please clarify whether it affects wowza performance or streaming?


    Thanks.

  5. #5

    Default

    Quote Originally Posted by divyat View Post
    I can understand that i have to use onConnect/onPlay/onHTTPSessionCreate etc etc which log to a specific location, lets say via a HTTP call. If I use like this, please clarify whether it affects wowza performance or streaming?


    Thanks.
    Streaming to the client would not start until the HTTP call had been completed. You could write a thread which makes HTTP calls independently from a queue of data, such that onConnect/onPlay/onHTTPSession etc push data into a queue, so not stalling based on a HTTP request, then a seperate thread pushes this data to a HTTP call.

    If you are putting a HTTP call into these functions you need to make sure a timeout is added correctly, say 5 seconds, if the remote side (receiving the HTTP call ) does not respond the HTTP call fails correctly and the code continues without stalling out the client connected.

    Andrew

  6. #6
    Join Date
    Apr 2012
    Posts
    133

    Default

    Quote Originally Posted by andrew_k View Post
    Streaming to the client would not start until the HTTP call had been completed. You could write a thread which makes HTTP calls independently from a queue of data, such that onConnect/onPlay/onHTTPSession etc push data into a queue, so not stalling based on a HTTP request, then a seperate thread pushes this data to a HTTP call.

    If you are putting a HTTP call into these functions you need to make sure a timeout is added correctly, say 5 seconds, if the remote side (receiving the HTTP call ) does not respond the HTTP call fails correctly and the code continues without stalling out the client connected.

    Andrew

    I have lot of clients so there would be large data to send via http call. If any delay happened or any problem occuring when large data to send, then it affects streaming. So have to wait to solve udp appender to send log details.

    thanks

  7. #7

    Default

    Quote Originally Posted by divyat View Post
    I have lot of clients so there would be large data to send via http call. If any delay happened or any problem occuring when large data to send, then it affects streaming. So have to wait to solve udp appender to send log details.

    thanks
    OK.

    I personally would always go with TCP for logging as even without any bugs in the log4j package there is a chance UDP will be lost.

    Andrew.

  8. #8
    Join Date
    Apr 2012
    Posts
    133

    Default

    Quote Originally Posted by andrew_k View Post
    OK.

    I personally would always go with TCP for logging as even without any bugs in the log4j package there is a chance UDP will be lost.

    Andrew.

    How to enable TCP in log4j package to send log details.. If support team said this earlier, I might have used before going for udp. Is there any problem come in TCP?


    Thanks

Similar Threads

  1. Replies: 1
    Last Post: 01-28-2014, 08:31 AM

Posting Permissions

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