Just what I said: It is not JNI's or GlassFish's fault, but it is the
fult of the JNI programmer that implemented that stuff. So the question
is not GlassFish related.
Regards
Markus
> -----Original Message-----
> From: Pete.Williams_at_Sun.COM [mailto:Pete.Williams_at_Sun.COM]
> Sent: Dienstag, 2. Juni 2009 06:39
> To: users_at_glassfish.dev.java.net
> Subject: Re: JNI/CompositeApp/Glassfish
>
> This is kind of an FYI or FWIW.
>
> I haven't implemented JNI code in a very long time. But back when I
> did, it was extremely easy to write code leaked memory if you weren't
> extremely careful with allocations involving objects allocated on the
> native side and objects passed across the interface (regardless of
> where
> they were allocated) and what was done with the on the other side.
> IIRC
> the JDK has very specific instructions on what you can and can't do
and
> how to handle these issues. If you know what objects are leaking,
find
> out where they were allocated and what is being done with them
> (especially if they are java objects being passed through JNI -- you
> may
> be doing something in the native code that is damaging the reference
> counts).
>
> -Peter
>
> Martin, Ray wrote:
> > This is just FYI:
> >
> > I wanted to see if I could get "the EJB" out of my problem space. I
> do
> > not know a a way to include a Java SE project into a composite app -
> a
> > service assembly. So, I created a WebApp and copied all my code
from
> my
> > EJBModule project. I removed all EJB references and created my own
> > EntityManager for persistence. I added the WebApp war file to the
> > service assembly in place of the EJBModule. NetBeans 'wired'
> together
> > the service assembly. I deployed what looks to me to be a POJO app
> to
> > Glassfish.
> >
> > Making the call to the JNI causes severe memory leak. Additionally,
> > which I had not mentioned prior, I cannot send any SOAP messages
> after
> > calling the JNI. This inability to send follow-on SOAP messages
> > invalidates my Glassfish show and tell.
> >
> > Anyway, this is just info. No response necessary. But, any useful
> > advice would be appreciated.
> >
> > Thanx.
> >
> > -----Original Message-----
> > From: Sanjeeb.Sahoo_at_Sun.COM [mailto:Sanjeeb.Sahoo_at_Sun.COM] On Behalf
> Of
> > Sahoo
> > Sent: Friday, May 29, 2009 8:49 AM
> > To: users_at_glassfish.dev.java.net
> > Subject: Re: JNI/CompositeApp/Glassfish
> >
> > Just because the spec says "don't do it" does not necessarily mean
> "it
> > will not work." I am not familiar with CompositeApps, so I can't
> comment
> > on that. What I understand from your problem description is your
main
> > issue is to call JNI from an EJB. I don't understand why that will
> not
> > work. Write a simple test program and see if it works. There are
> certain
> > things that does not work when it comes to shared libraries. A
shared
> > library can;t be confined to namespace of a classloader, so if you
> > deploy multiple same library multiple times, things may not work.
But
> > then, I don't think you are trying to do that.
> >
> > Secondly why do you care about memory leak if you are just showing
> some
> > feature? That can be independently addressed, no?
> >
> > Sahoo
> >
> > Martin, Ray wrote:
> >
> >> Yes, Mr. Chris suggested to use jmap and jhat to locate the leak.
> In
> >> my search for how to use those tools, I found that JNI is not
> supposed
> >>
> >
> >
> >> to work in EJB. So, I said to myself "wow, I am trying to do stuff
> >> that you are not even supposed to be doing. It does not really
> matter
> >> whether there appears to be a leak or not - the specs say don't do
> >> it." I will spend many weeks on classloaders and jhat and jmap
> and...
> >>
> >
> >
> >> I had a deadline to meet to show the great world of Glassfish SOA.
> >>
> >> I do not know how to deploy a POJO app (with a BPEL 'face') in a
> >> composite app. If I knew that, I could call the JNI from the POJO
> >> (staying out of that EJB world) and meet my deadline and put a
smile
> >> on my superiors faces. Then later, after my superiors agree that
my
> >> selection of Glassfish is marvelous, then I can look for memory
> leaks
> >> or whatever. But, right now, it's killing me.
> >>
> >> Thanx.
> >>
> >> -----Original Message-----
> >> From: Sanjeeb.Sahoo_at_Sun.COM [mailto:Sanjeeb.Sahoo_at_Sun.COM] On
Behalf
> >> Of Sahoo
> >> Sent: Friday, May 29, 2009 8:07 AM
> >> To: users_at_glassfish.dev.java.net
> >> Subject: Re: JNI/CompositeApp/Glassfish
> >>
> >> Martin,
> >>
> >> I am confused. What's your issue? In your first posting you
> mentioned
> >> that you were successful in running JNI code inside GlassFish
except
> >> that you suspected some memory leak for which Chris suggested to
use
> >> tools like hat. You were supposed to analyse the memory leak. Have
> you
> >>
> >
> >
> >> identified the cause? If yes, then tell us and tell us if it needs
a
> >> fix in GF.
> >>
> >> I have failed to identify if you have any other issue in this email
> >> thread. Personally, I have not come across many use cases where a
> J2EE
> >>
> >
> >
> >> app uses JNI. It appears that the spec discourages use of JNI. See
> [1]
> >>
> >
> >
> >> for some discussion. So, over all, it should work with some
> >>
> > limitations.
> >
> >> Thanks,
> >> Sahoo
> >>
> >> [1]
> >> http://www.theserverside.com/discussions/thread.tss?thread_id=14057
> >>
> >> Martin, Ray wrote:
> >>
> >>
> >>> i am readin' and scratchin' for JCA information - WOW. What a
> >>> complex
> >>>
> >>>
> >>
> >>
> >>> convoluted mechanism to merely call a tiny piece of code.
> >>>
> >>> i have many Glassfish instances running a variety of things as SOA
> >>> nodes. One of the things that one of the Glassfish nodes must do
> is
> >>> run a mathematical algorithm called a bayesian net.
> >>>
> >>> Why should it matter that that one instance is not portable? So,
> it
> >>> must run on a specific hardware platform, who cares? All that is
> >>> necessary is for the classloader to function properly to allow
this
> >>> particular non-portable code to run in a nice simplistic manner.
> >>>
> >>> But, no - i now am required to build my own EIS-like system to
> >>> contain
> >>>
> >>>
> >>
> >>
> >>> a daemon process to listen for commands to run a small algorithm.
> >>> Then i need to create an adapter. Then i need to create a
> connector.
> >>>
> >>>
> >>
> >>
> >>> Then i need to ... oh boy.
> >>>
> >>> And, there is something wrong with a system in which a Glassfish
> node
> >>>
> >
> >
> >>> performs some specialty algorithm? Hmm - yep, i am too dumb to
> >>> understand that.
> >>>
> >>>
-------------------------------------------------------------------
> --
> >>> -
> >>> --
> >>> *From:* Martin, Ray
> >>> *Sent:* Friday, May 29, 2009 6:22 AM
> >>> *To:* users_at_glassfish.dev.java.net
> >>> *Subject:* RE: RE: RE: JNI/CompositeApp/Glassfish
> >>>
> >>> i am too dumb to know that was a solution...
> >>>
> >>>
-------------------------------------------------------------------
> --
> >>> -
> >>> --
> >>> *From:* Markus Karg [mailto:karg_at_quipsy.de]
> >>> *Sent:* Friday, May 29, 2009 6:14 AM
> >>> *To:* users_at_glassfish.dev.java.net
> >>> *Subject:* RE: RE: JNI/CompositeApp/Glassfish
> >>>
> >>> The idea of EJB is to have a portable application which runs on
any
> >>> application server on any operating system on any hardware
> platform.
> >>> JNI works only with a particular operating system and hardware
> >>> platform. These two core ideas are absolutely not compatible. It
> just
> >>>
> >
> >
> >>> makes no sense to use EJB directly with JNI. If native stuff is
> >>> needed
> >>>
> >>>
> >>
> >>
> >>> in an enterprise application, it has to be provided in the form of
> a
> >>> JCA 1.5 adapter. This is the official Java EE solution to bind
> >>> portable applications (EJB) to platform-specific code (JNI). What
> >>> problem do you have with that?
> >>>
> >>>
> >>>
> >>> *From:* Martin, Ray [mailto:armart3_at_tycho.ncsc.mil]
> >>> *Sent:* Freitag, 29. Mai 2009 12:08
> >>> *To:* users_at_glassfish.dev.java.net
> >>> *Subject:* RE: JNI/CompositeApp/Glassfish
> >>>
> >>>
> >>>
> >>> Very smart people created JNI.
> >>>
> >>> Very smart people created EJB.
> >>>
> >>>
> >>>
> >>> These very smart people make sure that JNI cannot operate within
> EJB
> >>> -
> >>>
> >>>
> >>
> >>
> >>> why would people do something like that?
> >>>
> >>>
> >>>
> >>> i have fuddled for months building a system around glassfish - now
> it
> >>>
> >
> >
> >>> looks like i am back to ServiceMix, where i was a year ago
> >>>
> >>>
> >>>
> >>>
-------------------------------------------------------------------
> --
> >>> -
> >>> --
> >>>
> >>> *From:* Martin, Ray
> >>> *Sent:* Thursday, May 28, 2009 12:54 PM
> >>> *To:* users_at_glassfish.dev.java.net
> >>> *Subject:* JNI/CompositeApp/Glassfish
> >>>
> >>> Does anyone have a JNI application running in Glassfish?
> >>>
> >>>
> >>>
> >>> I have a third party JNI app (Netica). It runs fine from the
> command
> >>>
> >
> >
> >>> line.
> >>>
> >>>
> >>>
> >>> i have an EJBModule and a BPEL project added to a composite app.
> The
> >>>
> >
> >
> >>> composite app is deployed to Glassfish and runs fine - receiving
> and
> >>> responding to SOAP message.
> >>>
> >>>
> >>>
> >>> i then add the JNI app to the EJBModule and deploy the composite
> app
> >>> to Glassfish.
> >>>
> >>>
> >>>
> >>> there are two SOAP messages to the composite app - setup and
> >>>
> > activate.
> >
> >>>
> >>>
> >>> i issue the setup message - the request and response occur.
> >>>
> >>> i issue the activate message - the JNI app runs - all is good -
the
> >>> results are stored in the database.
> >>>
> >>> after the JNI app should be completed, the memory usage starts to
> >>>
> >>>
> >> climb.
> >>
> >>
> >>>
> >>>
> >>> any suggestions?
> >>>
> >>>
> >>>
> >>
--------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> >> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
> >>
> >>
> >>
--------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> >> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
> >>
> >>
> >>
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> > For additional commands, e-mail: users-help_at_glassfish.dev.java.net
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> > For additional commands, e-mail: users-help_at_glassfish.dev.java.net
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net