Hi,
Sorry, did not see that as I only read the last post that I replied to...
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.
> Indeed. C-API As I stated. Indeed ARTermination. As I stated :).
> Meta-Update can have multiple sessions (and hence issue multiple
> ARTermination calls.
>
> Cheers Misi.
> Ben.
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[email protected]] On Behalf Of Misi Mladoniczky
> Sent: January-23-12 09:05
> To: [email protected]
> Subject: Re: Java API: how to really log out ? (v7.1)
>
> 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 app?s fault and not the API?s fault. You
>> must call the API?s 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"
>
> _______________________________________________________________________________
> 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"
