Soci (Soczó Zsolt) szakmai blogja

2013.02.14.

WCF perf

Filed under: .NET,.NET 4.5,Szakmai élet — Soczó Zsolt @ 22:11

Ma sikerült 700 MBits/seccel adatokat átvinni titkosítva, tömörítve WCF-fel egy erős pc és egy szerver között. :)
Ehhez egyszerre 3 szerverre uploadoltunk fájlokat párhuzamosan, netTcpBindinggel, SSL-lel, a csatornán Deflate tömörítéssel (.NET 4.5).

2013.02.10.

HashSet.Add végtelen ciklus oka és megoldása

Filed under: .NET,Szakmai élet — Soczó Zsolt @ 12:32

Alapszabály, hogy HashSet, Dictionary vagy bármi más asszociatív kollekciókban kulcsként csak immutable objektumokat lehet használni. Ennek az az oka, hogy amikor berakunk egy elemet, akkor a kollekció meghívja az objektumon a GetHashCode-ot, és az azonos hashkódú objektumokat listába szervezi. Ha két objektum egyenlőnek tekintendő (az Equals alapján), akkor a hascodejuknak azonosnak kell lenni. Ha ez nem teljesül, vagy idővariáns, azaz később már nem igaz, akkor ezek a kollekciók meghülyülnek.
A példám így nézett ki:

public virtual bool Equals(EntityBase other)
{
if (other == null)
{
return false;
}
if (Id == 0)
{
//Transient object
return ReferenceEquals(this, other);
}
return other.Id == Id;
}

public override bool Equals(object obj)
{
if (!(obj is EntityBase))
{
return false;
}
return Equals((EntityBase)obj);
}

public override int GetHashCode()
{
return Id;
}

Eleve látszik, a GetHashCode és az Equals nem azonos logika szerint működik. A GetHashCode akkor ad vissza azonos hascodeot, ha az idk azonosak. Az Equals viszont az idtől függően vagy az idkat hasonlítja össze, vagy referenciális komparálást csinál. Ez már kapásból bug.

A másik bug, hogy ez az objektum nem immutable, az Id változik, amikor adatbázisba beszúrjuk az entitást, és kap egy idt. Emiatt az egész koncepció beteg.

A HashSet.Add meghívja a HashSet.AddIfNotPresetet, amiben van egy ciklus:

for (int i = this.m_buckets[num % this.m_buckets.Length] – 1; i >= 0; i = this.m_slots[i].next)
{
if (this.m_slots[i].hashCode == num && this.m_comparer.Equals(this.m_slots[i].value, value))
{
return false;
}
num3++;
}

Ez az ciklus akadt be. Az if feltétele sose teljesült, így sose lépett kis a ciklusból, mivel idt kapott az entitás, így megváltozott az Equals logikája.

2013.02.02.

IOC containerből példányosított WCF szerviz ojjektumok

Filed under: .NET,Szakmai élet — Soczó Zsolt @ 21:07

Ilyet még nem csináltam, percall alapú szervizeknél félnék is a DI framework sebességétől, de ezzel a módszerrel be lehet vezetni a DI-t a szerviz infrastruktúra tövénél. Még kevesebb Service Locator antipattern lesz a kódban.

WCF and SSL Processing Load Balancers

Filed under: .NET,Szakmai élet — Soczó Zsolt @ 20:40

Hogyan bízzuk az sslt a load balancerre, és használjunk sima httpt mögötte, a wcf szervizekig?
A bemutatott trükkös megoldás jól jött volna tavaly, amikor az OEP TAJ ellenőrző szervizét nem tudtuk WCF-fel meghívni, mert nem SSL-en kér auth adatokat. Alapban a WCF ezt nem nyeli le, de a cikk megmutatja, hogy lehet átvágni.

WAS alatt hoszolt WCF szerviz

Filed under: .NET,.NET 4,Szakmai élet — Soczó Zsolt @ 15:46

Pár órám elment az életemből, mivel véletlenül abszolút elérési utat írtam be endpoint addressnek egy WAS (IIS) alatt hoszolt WCF szervizbe. Jó szokásától eltérően nem jött semmi világos hibaüzenet, mi a baja a WCF-nek.

2013.02.01.

REST evolúció

Filed under: Architektúra,Szakmai élet — Soczó Zsolt @ 14:37

Érdekes írás Fowlertől, hogyan alakult ki a REST, ami ma már inkább Hypermedia API. Nekem a vége kicsit fura, amikor már kezd beszivárogni valami interfészleírás-szerű valami, így pont az eddig egyszerűség kezd elveszni.

WCF REST támogatás vagy ASP.NET WepAPI?

Filed under: .NET,Szakmai élet — Soczó Zsolt @ 14:21

Jó kis összefoglaló a témáról, miért kellett ASP.NET-be újra megcsinálni a dolgokat.

Powered by WordPress