BUTHRAKAUR: Ten token sam o sobe zadny ID neobsahuje. ID uzivatele mam zapsany ve dvojici s tim loginTokenem ted na serveru v Cache. Ale trida Cache neni urcena pro takovyhle veci (a tak se lehce stane, ze ten loginToken z pameti zmizi).

BUTHRAKAUR: Zajimavej napad, zamyslim se nad tim.

TENCOKACISTROMY: slo mi o to, ze pak nemusis resit ten persistentni stav sluzby/session, ale jednoduse si pokazdy z tokenu desifrujes to userId..

TENCOKACISTROMY: ja myslel sifrovat ciste jen ten token - to prece nebude nic vypocetne narocnyho, kdyz obsahuje jen to userId..

NECROMAN: zalezi, jak presne pracujes s tema WCF client proxy - zpusobu je vic a ja to ted z hlavy neznam, protoze to nepouzivam primo. hledal bych ale spis problem v tom WCF volani nez MVC.. + to, co jsi psal s tim lockovanim jsem nejak nepochopil. jestli tam nejak sam resis vlakna, tak to muze bejt taky problem :)

BUTHRAKAUR: nejakymu komplikovanymu sifrovani bych se rad vyhnul, protoze mi to sezere nejakej ten CPU cas a ty data, ktery se preposilaj nejsou nijak extra zvlast citlivy.

BUTHRAKAUR: ja to prave volam synchronne, zadne callbacky, ale proste mi to zahadne vytuhne vzdy, kdyz se mi zpracovavaji tri vlakna a v jednom volam tu metodu z WCF proxy objektu :-|

TENCOKACISTROMY: aha, tak potom asi vazne budes muset pouzit tu DB nebo jiny persistentni uloziste + cache ;( leda si ten token nejakym svym obousmernym algoritmem generovat, sifrovanej davat klientovi a v service si ho zase zpatky rozebirat..

BUTHRAKAUR: Na komunikaci vyuzivam protokol AMF (klientem je Flash/Flex aplikace - online hra), v hlavicce si nic takovyho neposlu :|. Tech requestu je pomerne hodne (nekolik za minutu).

Nekdy v budoucnu bych rad byl schopnej udelat web-garden (predpokladame X tisic aktivnich klientu najednou).

A souhlasim s tim, ze bych ty sluzby chtel mit state-less.

NECROMAN: a proc tu WCF nevolas synchronne? stejne musis na vysledek v tom action-vlakne cekat, ne? btw vytvaret WCF konekci pri kazdym zavolani akce muze byt pomerne zdlouhavy..

jinak na WCF doporucuju Castle WCF Facility - super nastroj na utiseni WCF bolesti se spravou tech pripojeni apod :)

TENCOKACISTROMY: pokud vim, tak best practice SOA/WCF je posilat auth udaje v headeru kazdy zpravy.. jestli to dobre chapu, tak ty v podstate uchovavas "session" state mezi requestama (tu vazbu loginToken-Account.Id), coz neni uplne cisty reseni. sluzby by mely byt state-less.

Mam WCF sluzbu hostovanou v IIS. Po overeni uzivatele (hash(username+password) nebo facebookid) vygeneruju jedinecnou hodnotu pro jeho identifikaci (loginToken).

K tomuhle loginTokenu si priradim ID uzivatele (hodnota z tabulky "Account" v databazi). Tenhle loginToken mi ten uzivatel posila, kdyz vola WCF operace.

Kam bych si mel ten loginToken ukladat, kdyz chci aby vydrzel i recyklaci procesu?
Jako nejlepsi reseni se mi jevi to ukladat do databaze + mit v ty WCF sluzbe singleton, kterej ma tyhle hodnoty nacachovany + ma SqlDependency na db tabulku s tema loginTokenama.

Nemam tam nejakou chybu v tomhle konceptu? Existuje lepsi reseni? Je uz neco takovyho hotovyho?

LZe zmenit nastaveni podle tohoto navodu dole, aniz by clovek musel prepisovat sytemovy soubor machine.config? Kdyz dam primo do appconfigu sve aplikace treba toto:

<processModel maxWorkerThreads="96" minWorkerThreads="8" maxIoThreads="96" minIoThreads="8" />

tak mi to hlasi, ze nelze menit to, co lze nastavit jen v machine.config
http://blog.stevensanderson.com/2010/01/25/measuring-the-performance-of-asynchronous-controllers/

ze by?
Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications
http://support.microsoft.com/kb/821268

JACHYMKO: v Akci na stazeni obrazku vytvarim konekci na WCF sluzbu, ktera vraci onen soubor, coz je vlakno navic. Pokud mam jednu aktivni akci a dve cekajici na locku, tak mi to deadlockne, protoze to odmitne vytvorit ctvrte vlakno pro to WCF spojeni.

NECROMAN: nebo jinak, jak nastavit seriove provadeni akci volanych z view v MVC 3 namisto paralelnio zpracovani, popripade jak zmenit max pocet paralelnich akci najednou?

Potrebuju radu - v MVC 3 aplikaci je nekde limit na max zpracovani 3 vlaken najednou, i kdyz mam treba na strance ve view 10x "@Url.Action("Image", "Product", neco)
Ted mi nastava deadlock, kdyz se mi vytvori 3x vlakno pro nacteni toho Image, ale kazde z techto vlakne potrebuje vytvorit jeste jedno vlakno navic. I kdyz to zamykam a volam seriove, tak se to zasekne na vytvoreni 4 vlakna a cela webova aplikace jde do haje. Dotaz tedy - kde lze zmenit nastaveni pocet vlaken pro webovou aplikaci?

NECROMAN: WCF streaming podporuje, ale ma to par omezeni. Kazdopadne musis u endpointu prenastavit TransferMode na Streamed. neco je o tom treba tady: http://blogs.msdn.com/b/drnick/archive/2006/03/31/565558.aspx

NECROMAN: Nevim, jestli na soubory nema WCF nejakej specialni funkcionalitu. Ale pokud nema, tak bych to posilal normalne po chunkach v byte[].

Otazka - kdyz mam web a extra sluzbu, ktera tomu webu poskytuje ulozene soubory z jineho stroje - jak tyto soubory posilat pres WCF nejrozumnejsim zpusobem - tedka se uz den snazim o to rozchodit to rozumne pres Streamy, ale nejak se mi to deadlockuje kdyz se klient pokousi cist vice souboru najednou, nebo jeden soubor vicekrat ve stejny okamzik a nevim, co s tim. Jsou streamy dobre reseni, neob radeji posilat byte[], nebo jeste nejak uplne jinak?

Zdravím,
nemáte někdo funkční sample na použití pooling duplexu pro komunikaci ze silverlight klienta?

jeste dotaz 0 lze nejak nastavit, aby se adresy generovali jenom s malymi pismenky i tehdy, kdyz mam nazvy views a controlleru s velkymi - mam ProductController a slozku Views/Product/
rad bych, aby to generovalo adresy ve tvaru <web>/product/action/

JACHYMKO: nakonec jsem to vyresil extra tabulkou v db, ktera mapuje usernames na unikatni int IDcka, ktera se pouzivaji i jako folder names - po strance vykonu to bude asi nejlepsi reseni, at tam nejsou selecty, kde porovnavam hashe useru.