Process Mapping Logo

Process Mapping - Forums

Sharing 19 years of knowledge and experience

 
Metastorm BPM forums
Sign up Latest Topics
 
 
 


Reply
  Author   Comment  
paulsiu

Senior Member
Registered:
Posts: 57
Reply with quote  #1 
Hi,

We recently upgrade our Metastorm from SR2 to SR4. The server kept going down with a COM+ error when the user performs an action:

Event Type:        Error

Event Source:    COM+

Event Category:                Unknown

Event ID:              4786

Date:                     10/1/2012

Time:                     2:55:45 PM

User:                     N/A

Computer:          PRDE3MET005

Description:

The system has called a custom component and that component has failed and generated an exception. This indicates a problem with the custom component. Notify the developer of this component that a failure has occurred and provide them with the information below.

Component Prog ID:

Server Application ID: {C4E0FA00-475D-11D4-85D6-00105AD8842F}

Server Application Instance ID:

{74FCAA20-D3DB-46F6-8A09-B427841855FE}

Server Application Name: Metastorm Process Engine

The serious nature of this error has caused the process to terminate.

Exception: C0000005

Address: 0x7C42E2C5

Call Stack:

MSVCP80!std::basic_streambuf<wchar_t,struct std::char_traits<wchar_t> >::xsputn(wchar_t const *,int) + 0x59

MSVCP80!std::basic_ostream<char,struct std::char_traits<char> >::write(char const *,int) + 0x48

EDatabaseConnector!DllUnregisterServer + 0x17e2a

+ 0x310034

The COM+ of course, takes down the engine.

We looked at some or the obvious, if there's a bad flag somewhere. We had to revert back to SR2 for now, but any idea why this may be happening. Any tips on how to go about finding out the root cause.There does not appear to be any entry in elog and the event log doesn't say anything else other than the COM+.

Paul

0
paulsiu

Senior Member
Registered:
Posts: 57
Reply with quote  #2 
After a week or so of debugging, it appears to be generated when an attachment of roughly 500K or above is opened. What is weird is that the error only affects attachment that were uploaded prior to the SR4 upgrade. So the 500K+ attachment can be opened in SR2, but when you upgrade it to SR4, you get a COM+ error. Now if you were to upload the same attachment into the SR4, it will open without any issues. It is af if there was some sort of format change in the attachment  between SR2 and SR4. As far as I can tell, the econtent field is just a blob, so why would the upgrade affect that. I don't see any schema changes on eattachment between SR2 and SR4.

What's going on?

Paul
0
paulsiu

Senior Member
Registered:
Posts: 57
Reply with quote  #3 
Examining the size field on the eattachment, it would appeared that something has changed.

We started out with a 74502 byte PDF file. If we upload this to a SR2 system, it stores it as a 1958750 bytes file (probably a lot of overhead). The same file uploaded to SR4 is 979374 bytes. It's like half the size. What's going on?

Paul

0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #4 
it looks like it may be translating it to Unicode. That would be completely redundant, and may possibly be an error in SR4.

Attachments are stored by translating the file into an ascii pair for each byte, and then storing that as a CLOB (despite what the field type is). It also has some prefix to describe the length IIRC. A little thought would tell you that as each ASCII char could only be 0-9 and A-F, there is absolutely no point storing this as Unicode, but I am pretty certain metatsorm do have a Unicode field type. The problem may be that pre-existing attachments are not upgraded, and the engine is expecting the new format.

make sure you have run the eworkprocedures SQL file just in case, but it could be a fault in that release.

__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #5 
reading that again, as the new attachments are half the size, the problem may have been 'fixed', but existing attachments were stored incorrectly due to a previous version. I could not say why 500k would be a limit, however.
__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
paulsiu

Senior Member
Registered:
Posts: 57
Reply with quote  #6 
OK, more messed up items.

If I use NewAttachment to upload a file from Metatorm, it will upload it in the same format as SR2 so the file will be twice the size as if I manually uploaded it using the attachment control. When we open it, we get a COM+ error.

Something is screwy if two different Metastorm API return different results.

I am thinking the 500K may come from Metastorm code trying to read legacy attachment and getting an exception in some particular situation. Without access to their code, we really can't say.


Paul
0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #7 
You need Metastorm to look at this problem. I suspect there was something wrong with your original install or your upgrade.

Also, I repeat:
Quote:
make sure you have run the eworkprocedures SQL file just in case

__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
paulsiu

Senior Member
Registered:
Posts: 57
Reply with quote  #8 
Jerome,

eworkprocedures.sql  have been run according to the install instruction and we have rolllback and re-installed it several times. We have posted a ticket with Metastorm over a week ago and still haven't resolve the issue. They have had us try several different things mostly dealing with COM+ component permission settings.

Paul
0
paulsiu

Senior Member
Registered:
Posts: 57
Reply with quote  #9 
After more testing, it appeared that SR4 is not the cause of the problem, but the first hotfix for SR4. After the hotfix, the issue started developing and doesn't go away after the latest hotfix (#3). Metastorm has been informed.

Paul
0
abeebe

Member
Registered:
Posts: 29
Reply with quote  #10 

Jerome and others, I work with Paul and this came down to the SR4 Hot Fix 1 and I agree it looks to be they fixed something, but none of the existing data was changed or updated.

Unfortunately this caused a lot of embarrassment for our company with regards to our customer.  This problem has been escalated to a priority 1 at Metastorm and hopefully they will have a fix soon.  This won't fix any problems with our customer, but was an unfortunate experience for us all.

Just to clarify, we even installed a new server system and upgraded it directly to SR4 Hot Fix 2 and the error was still there.  We re-ran all required scripts (many times) and the error still shows up.  We have a Metastorm employee on our staff, and he couldn't see how we did anyting wrong.  We have also been able to duplicate the exact problem in all of our environments (which we originally could not do until we determined the sympton) and this helped us with our troublshooting efforts.

Hopefuly if someone sees something similar, they don't waste over 1,000 man hours trying to find the problem, and that Metastorm will have a fix by the time anyone else sees it.

Thanks

Alan

0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #11 
It is a great shame that these things keep happening. For as long as I can remember it has been so. I hope it changes soon...
__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!