I have noticed the 'size' difference also, and have always questioned their "build/release" process based upon this fact.
I would shutter to think that the shared libs are maintained separately, without a common code source. Of course with that said, if they did a "make -ALL" which would build ALL components at the same build, then there would only be the one "version" of the libs as well. Also in the past (should go check now :-( ) there were different JDK versions with the various products (components) as well... Makes you go "hhuumm"... I know in the past, we had an issue, because we patched the server, but not the email engine on the same system (due to a file copy error unfortunately [read human mistake]) and well, windows was starting the email service before arserver, and well pulled in the older libs which arserver did not like running with. Resulted in a very unstable beast for a few days to determine what happened... So after that, I hacked the registry to have email dependant upon arserver, so it forced a proper startup sequence... Side Note <gripe> would it not be nice to have "per release" an already built "production, debug" binaries? I know you had to live many days waiting on the debug build, living with outages and such... After all how hard would it be to script a "make -ALL;make -DEBUG -ALL"... eh' sorry did not notice I woke up with new system settings... "Perfect_World_Mode = on;" today or something </gripe> Thanks-n-advance; HDT Platform Incident / Problem Manager & Architect Robert Molenda IT OS PA Tel: +1 408 503 2701 Fax: +1 408 503 2912 Mobile: +1 408 472 8097 [EMAIL PROTECTED] Quality begins with your actions. ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Friday, May 04, 2007 9:48 AM To: arslist@ARSLIST.ORG Subject: Re: 7.0.1 Patch2 Solaris - Problems ** The stack trace. At the bottom of the stack is 'SendNotification': ... RPC Id: 28155 RPC Call: 3 (CE) RPC Queue: 390620 ... Stacks: /prod/sys/remedy/bin/arserverd :DumpStackTrace+0x88 /prod/sys/remedy/bin/arserverd:SignalTrapProc+0x160 /usr/lib/libthread.so.1:0x15bac /usr/lib/libthread.so.1:0xf804 /usr/lib/libthread.so.1:0xf9b4 /usr/platform/sun4u-us3/lib/libc_psr.so.1:memset+0x140 [ Signal 11 (SEGV)] /prod/sys/remedy/bin/arserverd:SendNotification+0x41fc If I grep the filter and sql logs for the rpc id referenced in the stack trace, there is a group notification that is firing in every case that ends prematurely due to the server crashing (9 of 11 group members get the notification). Some oddities around the situation: - The group has a floating license pool - There are 15 group members, of which 11 have email as the notification method - The following files provided in the email patch do not match the size of the same files in the arserver patch: Email Patch2: 4934764 libarjni70.so 5917040 libarxmlutil.so 4553768 libar.a 2952488 libar.so ARServer Patch2: 4935032 libarjni70.so 5917164 libarxmlutil.so 4553828 libar.a 2952544 libar.so I saw the same thing in patch 1 with the different file sizes. I would REALLY REALLY like to witness the build process for these patches, because there are some very strange things coming out of it. To me, different sizes for a shared lib means one of two things is going on: - one product is built and the libs compiled, then the lib source is modified, then the next program is built and the libs recompiled - the same library is being maintained multiple times, once for each program, and they are not the same Axton Grams On 5/4/07, Ben Cantatore <[EMAIL PROTECTED]> wrote: ** Axton, funny you should mention the email relationship. I had plenty of these messages (see below) in my arerror.log which was caused by a bad filter, although I can't say I actually saw any direct correlation with fixing that filter and the problem going away. Like I said previously, I feel in my situation there was a combination of issues that caused the problem. Thu Mar 8 12:26:34 2007 SendEMail() Thu Mar 8 12:26:34 2007 390603 : Entry does not exist in database (ARERR 302) Thu Mar 8 12:26:34 2007 SendEMail() Thu Mar 8 12:26:34 2007 390603 : Entry does not exist in database (ARERR 302) Thu Mar 8 12:26:34 2007 SendEMail() Thu Mar 8 12:26:34 2007 390603 : Entry does not exist in database (ARERR 302) Thu Mar 8 12:26:34 2007 SendEMail() Thu Mar 8 12:26:35 2007 390603 : Entry does not exist in database (ARERR 302) Thu Mar 8 12:26:35 2007 SendEMail() Thu Mar 8 12:26:35 2007 390603 : Entry does not exist in database (ARERR 302) Thu Mar 8 12:26:35 2007 SendEMail() Thu Mar 8 12:26:37 2007 390603 : Entry does not exist in database (ARERR 302) What are you seeing that makes you think the email engine? Ben Cantatore Remedy Administrator Avon (914) 935-2946 Axton <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" <arslist@ARSLIST.ORG> 05/03/2007 06:33 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: 7.0.1 Patch2 Solaris - Problems I have not reverted back yet. I was provided a debug build to generate a useful core. After that core has been retrieved, I will roll back to patch 1. It looks to be related to the email engine in some way, but I am not sure how yet. When I get more information I will post it to this thread. Axton Grams On 5/3/07, Kathy Morris <[EMAIL PROTECTED]> wrote: > ** > > Axton, > > Did you have to reverse back to Patch1? Is there still problems with Patch2 > Solaris? > > > > > ________________________________ > See what's free at AOL.com. > __20060125_______________________This posting was > submitted with HTML in it___ ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
