Hi Ben,
Are not MetaUpdate linked to the C-API?
In the C-API, you have to issue an ARTermination() or each session you
have created, which is typically one if you work against one server.
In the Java-API, I would expect that this is handled automatically when
your (single) server object is destroyed.
It seems difficult to write a Java-API-program that leaks sessions, unless
there is some problem with the Java-API itself.
On the other hand, it seems unlikely that BMC has left such a bug in the
Java-API.
Have you tried running a newer version of the Java-API?
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> I cannot comment on the logout leaking handles as Meta-Update issues
> logouts
> at end of job. Currently, a Meta-Update job is a single process that
> begins
> and ends. However, it can be very log lived and hammers on the API quite
> heavily. So, I can comment on leaks.
>
>
>
> Leaks are almost always the apps fault and not the APIs fault. You must
> call the APIs free() functions as required and your own as well. It is
> best to have a routine to dump allocated blocks at appropriate points and
> then go through them manually. This is part of a special version I build
> on
> Windows. gcc does not have equivalent functions without a special
> library.
> In this version, I replace the standard allocation functions with one that
> cuts a trace and calls the original functions. Then it is no problem to
> determine where the leaked memory was allocated (with the exception of API
> calls).
>
>
>
> The API is not completely documented on the subject of what arguments
> return
> allocated memory etc. I always have had grief with mixing memory
> allocation
> even for the same structure, so I have replicated the ARFree functions and
> use them for my own allocations and use the API for its allocations.
>
>
>
> There were some API leaks in older versions. I do not think 7.1 was one
> of
> them. There were patches applied. I think they were around the 5.2 area
> but have kept to formal logs on the subject. I know that huge jobs (50k
> records * 5 outputs etc) do not leak memory.
>
>
>
> Cheers
>
> Ben Chernys
>
>
> Senior Software Architect
> Description: logoSthInc-sm
>
> Canada / Deutschland / Germany
> Mobile: +49 171 380 2329 GMT + 1 + [ DST ]
> Email: Ben.Chernys _AT_ softwaretoolhouse.com
> Web: <http://www.softwaretoolhouse.com/>
> www.softwaretoolhouse.com
>
> Check out Software Tool House's free Diary Editor.
>
> Meta-Update, our premium ARS Data tool, lets you automate
> your imports, migrations, in no time at all, without programming,
> without staging forms, without merge workflow.
> <http://www.softwaretoolhouse.com/> http://www.softwaretoolhouse.com/
>
>
>
>
>
>
>
>
>
> From: Action Request System discussion list(ARSList)
> [mailto:[email protected]] On Behalf Of Thibaut Barrère
> Sent: January-22-12 12:30
> To: [email protected]
> Subject: Re: Java API: how to really log out ? (v7.1)
>
>
>
> ** Hi,
>
> On Tue, May 31, 2011 at 5:42 PM, Papolu, Appajee <[email protected]>
> wrote:
>
> AR API methoods in essense have a notion of establishing connection,
> authenticating, performing the eventual network api call to the Server and
> so on. That is why your subsequent ops after logout just work seamlessly.
> Of
> course all this noted additional work happens conditionally on as needed
> basis.
>
> So, be assured that -- if you do a login at first and logout at the very
> end, then expected logout semantics are upheld (i.e. this specific user's
> acquired license is released etc).
>
>
>
> Some extra feedback much later on, in case it helps someone (and I think
> we
> have some leaking somewhere).
>
>
>
> I must mention that earlier on, I faced the same situation with an ARS 5.1
> installation.
>
>
>
> What I diagnosed in the end (using tools like TaskInfo) is that the
> process
> was leaking 3 handles per login, but logout (with or without clear in 5.1)
> did not release the connections (using ARServerUser to login/logout).
>
>
>
> I'm concerned that this may be happening as well with 7.1 (although I
> cannot
> test right now).
>
>
>
> This is a bit of a concern for long running processes, such as job
> processing workers.
>
>
>
> I'd love to hear from others, in case someone has experimented more leaks
> on
> long running processes!
>
>
>
> -- Thibaut
>
> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
