Tja, cudno .... Je'l si probao da stavis da se tvoja aplikacija izvrsava u Multithreaded apartment rezimu ? To ti je atribut iznad Main metode, po defaultu je STAThread, prebaci na MTAThread. Ali, nesto sumnjam da je u tome problem ....

ma, ono sto nisam rekao jer mislim da je nebitno je da u stvari moja aplikacija i nije aplikacija vec
je to .NET COM komponeneta koja se dalje poziva od strane neke aplikacije.. mada mislim
da to ne mjenja stvar.

Jel COM deo zaista COM objekat ili je DCOM serverska komponenta koja radi u svom procesu?

bas COM :).
Samo da jos dodam:
isti sam problem imao prije par mjeseci, i koliko se sjecam
isti sam COM koristio iz drugog .NET DLL-a a taj ,NET DLL je opet koristen
iz trece testne win aplikacije i pozivao sam funkcije tog dll-a iz vise tredova i
isti problem sam izazvao. Tako sam skontao da je multithreading bio problem i
samo sam sveo na jedan thread i radilo je. Medjutim, sada nema vise
threadova a problem isti.

Pazi ovako, .NET interop assembly koji se kreira na AddReference kreira delegate i procesiranje eventa na osnovu event informacija iz type library-a i tu ne bi trebao da bude problem (niti mozes bas mnogo da utices direktno). Problem je verovatno u tome kako je event deklarisan u COM-u nasuprot tome kako se invokuje iz C++ koda. Deluje kao da je neki nestandardni asinhroni callback event koji .NET procesira kroz pooling a posto je pozivni thread usao u COM bude blokiran do procesiranja eventa, sto se ne desi jer se thread ne vrati u .NET kod. Ajd ako ti nije tesko izvuci tlb iz COM-a i okaci ga i daj kod tog C++ metoda koji invokuje event handler.

uh, evo cijeli dan se borim sa ovim COM-om.
Definitivno je problem u sljedecem:
- COM 'eskportuje' masu nekakvih stvari i koristim ga za pristup bazi preko specificnog frameworka (zato i psotoji ovaj COM),
za registraciju na server (aplikacija), za dobijanje informacija o statusu objekata o kojima server brine itd.
Danas sam pokusao debagiranje. Pogledam disassembly i imam situaciju da sve dok se vrti iz jednog threada ok je, cim
krenem pozivanje metoda iz drugog threada javi se problem... dodje do sporne funkcje koja zaglavljuje, udje u nju, odradi
par upisivanja u registre i onda dodje do tacke u kojoj COM funkcija poziva neku drugu funkciju i tu pada. Najcudnije mi
sto ne izbaci exception nego samo tu 'zaglavi'.

Zakljucak: kao da ima problem sa marshalizovanjem (jel moguce?), drugog objasnjenja nemam jer sve bude ok ako jedan tred
odradjuje posao, cim se upetlja neki thread sa strane (iako i taj thread koristi jednu te istu instancu klase koja dalje kominicira sa COMom)
jave s probemi.
Uzas.

Samo da dodem, nije problem da okacim tlb fajl, ali sam za sebe COM ne znaci nista
jer je dio okruzenja koji u sebi integrise jos x dll-ova itd. itd.

_{[Ovu poruku je menjao erkan dana 19.09.2007. u 23:09 GMT+1]}

Pa znaci da ti nisi ni dosao do pozivanja eventa koji se vraca u C#. Malo si nas zbunio sa time. To sto si ti sad opisao je definitivno thread locking. Ta funkcija koju C++ kod poziva, jel to funkcija iz drugog DLLa, iz tvog C++ koda ili iz drugog COMa? Jel mozes da debagujes i taj kod? U princip COM STA sinhronizacija blokira poziv dok prethodni poziv ne obavi posao. Ovo sto se tebi desava veoma lici na deadlock (metodi A i B su u STA modu i pozivaju jedan drugog, i dva threada jedan u i drugi u B zaglave cekajuci onog drugog da zavrsi)

ok, da malo detaljisem jos, da opisem komplet environment kod mene.
Java aplikacija treba da pristupi nekom velikom sistemu, nesto kao da
obezbjedi upravljanje nekim elementima u tom sistemu. Odluceno je da se
to radi u Javi.
Sa moje strane ja imam C++ COM komponentu koja je interface prema tom
sistemu. Napravio sam neki wrapper tog COM-a i koristim ga pored ovog
u jos jednom projektu za drugog customer-a.

Isti taj wrapper sada koristim kao interface koji ce Java aplikacija koristtiti
kako bi pristupila sistemu. Kako JAVA ne moze direktno da pristupi
mom.NET dll-u, bio sam prinudjen da napisem jedan .NET COM
koji preko JNI i ostalih cuda prilagodjavanja JAVI (uzas jedan), omogucava
Java aplikaciji da pristupi mom .NET wrapperu, a samim tim i C++ COM-u
sto znaci i sistemu. Sve je to divno i bajno dok iz jave ne krenuse da
koriste pozivanje COM metoda iz vise threadova.
Zadnje sto sam mogao da vidim u logu nakon dva dana smaranja sa ovim jeste
da Java poziva moju wrapper komponentu iz dva threada, prvi thread je STA
a drugi MTA i tu bi trebala biti kvaka.
Znaci, da mi je promjeniti ovaj prvi iz STA u MTA pa da probam.
Moguce da bi to bilo rjesenje problema.
Jesam se ispisao :)