Error calling remote component

Hi,

We have an IIS4 web server that makes calls via ASP to an MTS remote component. The source component resides on another NT4/MTS box that is the other side of our firewall (the component is produced by SAP's DCOM builder).

The problem is this - intermittently (though more or less every day), calls to the remote component return an ASP error ('The RPC Server Is Unvailable') which can be fixed by shutting down the server processes on the MTS machine using the MMC. Any subsequent calls to this component get the same error until this fix is done.

There is also an Event Viewer application log entry on the IIS server with the following data:

Failed on creation from object context: CoGetClassObject (ProgId: C11.Test38a.1) (CLSID: {7EDA40DA-7AB9-11D5-980E-0000F6EFC00C}) (Interface: IClassFactory) (IID: {00000001-0000-0000-C000-000000000046}) (Microsoft Transaction Server Internals Information: File: i:\viper\src\runtime\context\ccontext.cpp, Line: 1355)

Does anybody have any ideas as to why this is happening? No changes are made to the configuration of either box between these incidents.

Any help would be very, very much appreciated,

Vip
tin-cup@cyberdude.com
vahlawatAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
SpideyModConnect With a Mentor Commented:
per recommendation

SpideyMod
Community Support Moderator @Experts Exchange
0
 
DirkVeCommented:
1) Verify that the component DLL exists and is registered correctly and that it's added into a package into MTS.

2)Verify that the identity account for the package has sufficient permissions on the system. If the identity is set to "Interactive User", make sure that someone is always logged on at the console of the server.
0
 
vahlawatAuthor Commented:
Thanks for the suggestions - I have checked these things and they are OK.  The component can be called with no problems nearly all of the time.  The main problem is that when is does fall over as I described above, it will not work again until I manually intervene by shutting down the server processes.

Cheers,
Vip
0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
KelmenCommented:
Check out the MSDN Q241057. Relevant to your problem.

<!--snipped-->
RESOLUTION
Set the package identity to a specific user.

STATUS
This behavior is by design.
<!--snipped-->
0
 
vahlawatAuthor Commented:
Thanks for that - I'm afraid that's not the solution either.  The package containing the component is set to run as a specific user with administrator priveliges, the same as for other packages that are not exhibiting this behaviour.

Cheers,
Vip
0
 
krispolsCommented:
0
 
Michel SakrCommented:
it might be that the component threads stay resident in memory.. try to set component thread destroy time to 1-2 minutes..
0
 
vahlawatAuthor Commented:
Thanks - the KB article doesn't help because we are not using NAT and DCOM works fine generally.

How do I set the component thread destroy time?

Cheers,
Vip
0
 
MCMCommented:
I had a similar problem after installing NT sp6a and the MS hotfix that was supposed to prevent Code Red. It went away again after I installed latest sp of MDAC 2.5 (not 2.6, although this might work too) AND the latest Jet 4.0 release. No idea why these worked, or if they'll work for you, but you can get them at www.microsoft.com/data.
0
 
vahlawatAuthor Commented:
Thanks for that, I'll give it a try and let you know.

Cheers,
Vip
0
 
Michel SakrCommented:
in MTS in the package propreties.. but also are you destroying your components objects in the script??
Set ComObjectVariable = nothing
0
 
KelmenCommented:
Just a suggestion, as I would probably try this:

I would try to simulate the testing environment but taking out the firewall, this is to pinpoint the scope of the error cause. As your problem is on-and-off, which highly indicate non-programming-related problem (hardware, service pack, networking etc).

We actually had faced a problem with ADSL, and doing the similar testing had help us pinpoint our error cause to an "abandoned" WINS server.

HTH.
0
 
hongjunCommented:
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:
[PAQ with NO REFUND]

Please leave any comments here within the next seven days.

PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!

hongjun
EE Cleanup Volunteer
0
All Courses

From novice to tech pro — start learning today.