[Red5] Red5 Digest, Vol 42, Issue 14
Ramadoss
ramadossc at yahoo.com
Mon Feb 2 15:57:19 PST 2009
Thanks all for the response.
I think I sort of getting a clue on what is happening. There are serils of events being called when you try to connect to Red5 from Flash client(viewer). So the /Idle request is being generated (by Flash Client? of Red5 itself?) that it tries to ping Red5 once in few seconds so after few(5-10 attempts) ping if client is still idle then it automatically kicked him out of session. So when you try to call getConnection from RTMPTManager for the current client id it returns null. So the question is who calls this event i.e. if you look at servletPath the events are /Open handled by handleOpen()immediately after that /Idle is requested which is handled by handleIdle(). So if the clientId is still idle after few ping then it automatically requests /Close - handleClose() that kills the session.
any idea how this events being generated and by whom (red5 itself - based on values specified in red5.properties OR flash client that ping Red5 periodically and eventually kills the session if client id is idle for over certain time) ?
Thanks,
Ram
--- On Mon, 2/2/09, red5-request at osflash.org <red5-request at osflash.org> wrote:
> From: red5-request at osflash.org <red5-request at osflash.org>
> Subject: Red5 Digest, Vol 42, Issue 14
> To: red5 at osflash.org
> Date: Monday, February 2, 2009, 3:18 PM
> Send Red5 mailing list submissions to
> red5 at osflash.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://osflash.org/mailman/listinfo/red5_osflash.org
> or, via email, send a message with subject or body
> 'help' to
> red5-request at osflash.org
>
> You can reach the person managing the list at
> red5-owner at osflash.org
>
> When replying, please edit your Subject line so it is more
> specific
> than "Re: Contents of Red5 digest..."
>
>
> Today's Topics:
>
> 1. Re: Error setting up context: /oflaDemo due to: null
> (abshirf2)
> 2. Re: Error setting up context: /oflaDemo due to: null
> (Art Clarke)
> 3. Re: Quick Question: Client vs Connection (Andy
> Shaules)
> 4. Re: Quick Question: Client vs Connection (Walter Tak)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 2 Feb 2009 14:43:15 -0800 (PST)
> From: abshirf2 <abshirf2 at yahoo.co.uk>
> Subject: Re: [Red5] Error setting up context: /oflaDemo due
> to: null
> To: Red5 at osflash.org
> Message-ID: <21800186.post at talk.nabble.com>
> Content-Type: text/plain; charset=UTF-8
>
>
> Thank you for the reply. I have just installed red5 from
> trunk (3494) and I
> got the same error as before.
>
> I think it must be due to my application? I have uploaded
> it as .tar file if
> you would like to have a look. Its exactly the same as
> oflaDemo but with an
> extra class "CustomFileGenerator".
>
> For red5 0.8, am I supposed to have the logback jar files
> in the lib folder?
> Will this cause the Error setting up context: /oflaDemo due
> to: null? I
> guess it shouldn't?
>
> Thank you for anymore help.
> http://www.nabble.com/file/p21800186/oflaDemo.tar
> oflaDemo.tar
>
>
> Art Clarke-2 wrote:
> >
> > Please upgrade to the lasted 0.8 RC2 candidate and try
> again:
> >
> http://blog.xuggle.com/2009/01/28/red5-08-rc2-first-candidate-build/
> >
> > - Art
> >
> > On Mon, Feb 2, 2009 at 1:34 PM, abshirf2
> <abshirf2 at yahoo.co.uk> wrote:
> >
> >>
> >> Hello all,
> >>
> >> I have just put a custom oflaDemo in the
> dist/webapps directory so that
> >> oflaDemo can stream to different directories.
> >>
> >> I started red5 and I got these errors. Can someone
> please help me
> >> troubleshoot this?
> >>
> >> 2009-02-02 22:21:12,834 [main] ERROR
> o.a.catalina.core.StandardContext -
> >> Context [/oflaDemo] startup failed due to previous
> errors
> >> 2009-02-02 22:21:13,076 [main] ERROR
> org.red5.server.tomcat.TomcatLoader
> >> -
> >> Error setting up context: /oflaDemo due to: null
> >>
> >> I am using Java 1.6 and I am using 0.8 RC 1 on a
> Fedora Core 10 machine.
> >>
> >> Thanks all
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Error-setting-up-context%3A--oflaDemo-due-to%3A-null-tp21798863p21798863.html
> >> Sent from the Red5 - English mailing list archive
> at Nabble.com.
> >>
> >>
> >> _______________________________________________
> >> Red5 mailing list
> >> Red5 at osflash.org
> >>
> http://osflash.org/mailman/listinfo/red5_osflash.org
> >>
> >
> >
> >
> > --
> > http://www.xuggle.com/
> > xu?ggle (z?' gl) v. To freely encode, decode, and
> experience audio and
> > video.
> >
> > Use Xuggle to get the power of FFMPEG in Java.
> >
> > _______________________________________________
> > Red5 mailing list
> > Red5 at osflash.org
> > http://osflash.org/mailman/listinfo/red5_osflash.org
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Error-setting-up-context%3A--oflaDemo-due-to%3A-null-tp21798863p21800186.html
> Sent from the Red5 - English mailing list archive at
> Nabble.com.
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 2 Feb 2009 14:52:46 -0800
> From: Art Clarke <aclarke at xuggle.com>
> Subject: Re: [Red5] Error setting up context: /oflaDemo due
> to: null
> To: red5 at osflash.org
> Message-ID:
> <824e8eb40902021452r5aa9a10ckc1f75be9e8e3cc6c at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi there,
>
> The log snipped you posted before claimed that startup was
> failing due to
> previous errors. Look further up in the log file and find
> the errors it's
> complaining about and that might give you a hint.
>
> Hope that helps,
>
> - Art
>
> On Mon, Feb 2, 2009 at 2:43 PM, abshirf2
> <abshirf2 at yahoo.co.uk> wrote:
>
> >
> > Thank you for the reply. I have just installed red5
> from trunk (3494) and I
> > got the same error as before.
> >
> > I think it must be due to my application? I have
> uploaded it as .tar file
> > if
> > you would like to have a look. Its exactly the same as
> oflaDemo but with an
> > extra class "CustomFileGenerator".
> >
> > For red5 0.8, am I supposed to have the logback jar
> files in the lib
> > folder?
> > Will this cause the Error setting up context:
> /oflaDemo due to: null? I
> > guess it shouldn't?
> >
> > Thank you for anymore help.
> > http://www.nabble.com/file/p21800186/oflaDemo.tar
> oflaDemo.tar
> >
> >
> > Art Clarke-2 wrote:
> > >
> > > Please upgrade to the lasted 0.8 RC2 candidate
> and try again:
> > >
> http://blog.xuggle.com/2009/01/28/red5-08-rc2-first-candidate-build/
> > >
> > > - Art
> > >
> > > On Mon, Feb 2, 2009 at 1:34 PM, abshirf2
> <abshirf2 at yahoo.co.uk> wrote:
> > >
> > >>
> > >> Hello all,
> > >>
> > >> I have just put a custom oflaDemo in the
> dist/webapps directory so that
> > >> oflaDemo can stream to different directories.
> > >>
> > >> I started red5 and I got these errors. Can
> someone please help me
> > >> troubleshoot this?
> > >>
> > >> 2009-02-02 22:21:12,834 [main] ERROR
> o.a.catalina.core.StandardContext -
> > >> Context [/oflaDemo] startup failed due to
> previous errors
> > >> 2009-02-02 22:21:13,076 [main] ERROR
> org.red5.server.tomcat.TomcatLoader
> > >> -
> > >> Error setting up context: /oflaDemo due to:
> null
> > >>
> > >> I am using Java 1.6 and I am using 0.8 RC 1
> on a Fedora Core 10 machine.
> > >>
> > >> Thanks all
> > >> --
> > >> View this message in context:
> > >>
> >
> http://www.nabble.com/Error-setting-up-context%3A--oflaDemo-due-to%3A-null-tp21798863p21798863.html
> > >> Sent from the Red5 - English mailing list
> archive at Nabble.com.
> > >>
> > >>
> > >>
> _______________________________________________
> > >> Red5 mailing list
> > >> Red5 at osflash.org
> > >>
> http://osflash.org/mailman/listinfo/red5_osflash.org
> > >>
> > >
> > >
> > >
> > > --
> > > http://www.xuggle.com/
> > > xu?ggle (z?' gl) v. To freely encode, decode,
> and experience audio and
> > > video.
> > >
> > > Use Xuggle to get the power of FFMPEG in Java.
> > >
> > > _______________________________________________
> > > Red5 mailing list
> > > Red5 at osflash.org
> > >
> http://osflash.org/mailman/listinfo/red5_osflash.org
> > >
> > >
> >
> > --
> > View this message in context:
> >
> http://www.nabble.com/Error-setting-up-context%3A--oflaDemo-due-to%3A-null-tp21798863p21800186.html
> > Sent from the Red5 - English mailing list archive at
> Nabble.com.
> >
> >
> > _______________________________________________
> > Red5 mailing list
> > Red5 at osflash.org
> > http://osflash.org/mailman/listinfo/red5_osflash.org
> >
>
>
>
> --
> http://www.xuggle.com/
> xu?ggle (z?' gl) v. To freely encode, decode, and
> experience audio and
> video.
>
> Use Xuggle to get the power of FFMPEG in Java.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://osflash.org/pipermail/red5_osflash.org/attachments/20090202/65c1c7b6/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 2 Feb 2009 14:55:33 -0800
> From: "Andy Shaules"
> <bowljoman at hotmail.com>
> Subject: Re: [Red5] Quick Question: Client vs Connection
> To: <red5 at osflash.org>
> Message-ID:
> <COL0-DAV1953094B2EA8BC43D4E90BBEC50 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I disagree 100%
> If you need to track clients like that, use a session of
> some sort, and set it as an attribute or what have you.
> Flash player itself is hardly setup to conglomerate
> connections and their client.handler without writing into
> place yourself.
> I personally prefer the current state of specific object
> references between the written lines of code on both ends.
>
> That said, this is what I dont understand..... The IClient
> has a Collection of connections..... But consider that I
> never change the scope by calling 'connect' more
> than once in the life cycle of the reference.... That may be
> the undelying use but I've not utilized it, only
> rewritten the Itereator access's.
>
>
> ----- Original Message -----
> From: Tyler Kocheran
> To: red5 at osflash.org
> Sent: Monday, February 02, 2009 2:26 PM
> Subject: Re: [Red5] Quick Question: Client vs Connection
>
>
> Oh, for sure! I know I could create a SharedObject to
> work around that, but I'm more talking about an
> automatic serverside scenario. I just think that the notion
> of an IClient should be representing one running instance of
> Flash Player connected to Red5 via one or more IConnection
> (NetConnection) implementations. Currently, whenever a
> connection is made to Red5, the appJoin(IClient client,
> IScope scope) method is fired, which is kind of weird, since
> if the client has already connected to the server, it gets
> called as many times as a conection is opened.
>
> What would be more effective in my mind would be to fire
> appJoin and roomJoin only once: upon a unique client
> connecting to the app/scope and not when any subsequent
> connection is made to the server. Does that make sense?
>
> I assumed that this was already so, but I did a little
> digging and I found out that appJoin is called upon every
> connection attempt to the server.
>
>
> On Mon, Feb 2, 2009 at 12:11 PM, Walter Tak
> <walter at waltertak.com> wrote:
>
> You can generate a unique ID , store it in a (Flash)
> local shared object and read that object (from the disk of
> the user) each time your 'application' starts.
> Cookies in browsers work as well, but are prone to
> deletion by ad/malware-scanners , can be blocked by paranoid
> users that don't allow all cookies or can be defeated if
> the user starts the application with as well Internet
> Explorer and Firefox simultaneous.
>
> Yes, users can empty those 'local shared
> objects' (Flash) but only in theory. In the real world
> you can track users until the end of days or until they
> install a new version of the Flash player. For the average
> identification of a single client it's enough.
>
> Anyway you should/could/might want to provide the user
> a token once they logged in on a backend server, pass that
> token to Flash, let Flash pass the token to the server
> (Red5) ; have Red5 validate the token against the backend
> and the user access or not. Once a token has been used it
> should be flagged so the user has to revalidate (get a new
> one) on the backend. If the user still has a proper session
> (like a php-session) then you could re-validate him
> automatically, give out a new token and let him reconnect
> with his client application (Flash/Flex) to your shiny
> Red5-server.
>
> You can make this as complicated as you like.
>
> Walter
>
> Doesn't Flash Player provide a unique id for the
> computer on which it's installed? I thought I heard
> something about that a while back...
>
>
> On Mon, Feb 2, 2009 at 9:27 AM, Michael Eckhoff
> <mreckhof at gmail.com> wrote:
>
> ... Proxy, NAT, terminal server, browser instance.
> I wouldn't be for trying to track anything by ip.
>
> Michael
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
>
>
>
> --
> And do this, knowing the time, that now it is high time
> to awake out of sleep;
> for now our salvation is nearer than when we first
> believed.
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://osflash.org/pipermail/red5_osflash.org/attachments/20090202/1c28f311/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 3 Feb 2009 00:17:59 +0100
> From: "Walter Tak" <walter at waltertak.com>
> Subject: Re: [Red5] Quick Question: Client vs Connection
> To: <red5 at osflash.org>
> Message-ID: <002001c9858c$7da857f0$1e0313ac at dc2140>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Well what if you have some app that wants to make multiple
> connections at once, for some reason ?
>
> Currently you can drop any new connections (on the
> serverside) if you think they're duplicates.
>
> I often test my apps by starting multiple swf's in my
> browser. Wouldn't be a good idea if Red5 would see them
> all as one client and not triggering events like appJoin.
>
> Unless I'm missing the point.
> Oh, for sure! I know I could create a SharedObject to
> work around that, but I'm more talking about an
> automatic serverside scenario. I just think that the notion
> of an IClient should be representing one running instance of
> Flash Player connected to Red5 via one or more IConnection
> (NetConnection) implementations. Currently, whenever a
> connection is made to Red5, the appJoin(IClient client,
> IScope scope) method is fired, which is kind of weird, since
> if the client has already connected to the server, it gets
> called as many times as a conection is opened.
>
> What would be more effective in my mind would be to fire
> appJoin and roomJoin only once: upon a unique client
> connecting to the app/scope and not when any subsequent
> connection is made to the server. Does that make sense?
>
> I assumed that this was already so, but I did a little
> digging and I found out that appJoin is called upon every
> connection attempt to the server.
>
>
> On Mon, Feb 2, 2009 at 12:11 PM, Walter Tak
> <walter at waltertak.com> wrote:
>
> You can generate a unique ID , store it in a (Flash)
> local shared object and read that object (from the disk of
> the user) each time your 'application' starts.
> Cookies in browsers work as well, but are prone to
> deletion by ad/malware-scanners , can be blocked by paranoid
> users that don't allow all cookies or can be defeated if
> the user starts the application with as well Internet
> Explorer and Firefox simultaneous.
>
> Yes, users can empty those 'local shared
> objects' (Flash) but only in theory. In the real world
> you can track users until the end of days or until they
> install a new version of the Flash player. For the average
> identification of a single client it's enough.
>
> Anyway you should/could/might want to provide the user
> a token once they logged in on a backend server, pass that
> token to Flash, let Flash pass the token to the server
> (Red5) ; have Red5 validate the token against the backend
> and the user access or not. Once a token has been used it
> should be flagged so the user has to revalidate (get a new
> one) on the backend. If the user still has a proper session
> (like a php-session) then you could re-validate him
> automatically, give out a new token and let him reconnect
> with his client application (Flash/Flex) to your shiny
> Red5-server.
>
> You can make this as complicated as you like.
>
> Walter
>
> Doesn't Flash Player provide a unique id for the
> computer on which it's installed? I thought I heard
> something about that a while back...
>
>
> On Mon, Feb 2, 2009 at 9:27 AM, Michael Eckhoff
> <mreckhof at gmail.com> wrote:
>
> ... Proxy, NAT, terminal server, browser instance.
> I wouldn't be for trying to track anything by ip.
>
> Michael
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
>
>
>
> --
> And do this, knowing the time, that now it is high time
> to awake out of sleep;
> for now our salvation is nearer than when we first
> believed.
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
>
> ------------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.552 / Virus Database: 270.10.16/1930 -
> Release Date: 02-02-09 07:51
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://osflash.org/pipermail/red5_osflash.org/attachments/20090203/855bfa2a/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
> End of Red5 Digest, Vol 42, Issue 14
> ************************************
More information about the Red5
mailing list