APR means 'Apache Portable Runtime', which is a C-based library that provides various operations in an O/S independent way. Tomcat project implemented JNI bridge to this library so we used it to use APR networking API to implement a new Socket transport, which might perform better in some platforms.
HTH, Trustin On Nov 22, 2007 1:26 PM, T TWO <[EMAIL PROTECTED]> wrote: > Hi Trustin, > > I hope you could guide me on the below very simple question: > > What is APR transport? ( What is APR? ) > > Sorry din added this question to the user group. > > regards, > Ka Ju. > > > > > ---------- Forwarded message ---------- > From: Tan Ka Ju <[EMAIL PROTECTED]> > Date: Nov 22, 2007 12:13 PM > Subject: Fwd: Re: APR Transport is ready to rock! > To: "juju.pc"@gmail.com > > > > > ---------- Forwarded message ---------- > From: "Trustin Lee" < [EMAIL PROTECTED]> > To: [email protected] > Date: Thu, 22 Nov 2007 13:14:47 +0900 > Subject: Re: APR Transport is ready to rock! > On Nov 21, 2007 7:25 PM, Mladen Turk < [EMAIL PROTECTED]> wrote: > > Trustin Lee wrote: > > >> > > >>> You might encounter segfault due to a bug of the current > > >>> implementation because we are using tomcat-native bridge for APR 1.2. > > >>> Any feed back is welcome! > > >>> > > >> The problem is probably with shutting down the APR library. > > >> Tomcat-native is very thin JNI layer for APR, so some > > >> precautions must be taken, like implementing shutdown hooks. > > > > > > Yes, I found segfault happens when I try to close socket more than once. > :) > > > > > > > Right. All native 'objects' are long (actually pointers to the native > memory), > > and the only check that is done is test for zero (NULL). > > It's the same as if you would call free() twice. The second call will > probably > > core dump cause it references already deallocated memory. > > So, although harder to program correctly, it offers zero GC, cause no > > Java objects gets created. The same thing is done within core Java > (rt.jar) > > where actual class implementation takes care of underlaying JNI safety. > > I was thinking to add the higher API over this thin layer that would > > allow Java programmers to use it more comfortably, but then extra Java > > objects would be created, and memory usage as well as GC would rise. > > So, when using tomcat-native, think as a C not as Java programmer ;) > > Yes, playing with APR reminded me of the old days. :D > > > Next, the major problem is in threaded environment where you can call > > global Pool destroy (shutting down the Library) while there is still > native > > call in progress. > > > > First thing I would add would be the unlock for Socket.accept > > (something each Acceptor, not only APR should have) > > and make sure that Socket.close for the acceptor socket is called even > > on the CTRL+C. After all native calls are exited, then you can safely > > call the Library.shutdown > > Doesn't OS release any resources allocated by a process when the > process quits or dies? Do I really need to call Library.shutdown()? > Am I missing something? > > Thanks again for the feed back, > Trustin > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 > > > > > -- > Warm Rgds, > Ka Ju > > Nike => Just Do It! -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
