[alg] socket met timeout andere sockets verzieken?

[Alarmnummer]

In het systeem waar ik op dit moment aan mee ontwikkel, wordt gebruik gemaakt van socket verbindingen naar smtpserver. Dit verloopt geheel multithreaded aangezien niet alle smtp servers even snel zijn en we niet het hele proces willen vertragen door langzame servers.

Alleen gebeurt het wel eens dat een socket naar een smtp server een timeout geeft. Onze indruk is dat er zo lang het systeem bezig is om een verbinding te maken en totdat het moment dat er een timeout optreed, alle andere goed werkende sockets ook niets kunnen doen.

Deze conclusie trekken we omdat er in die tijd ook geen (log)berichten van andere threads verschijnen.

Ik ga straks aan de slag om even een paar foute sockets te maken waar we het even grondig op kunnen testen, maar zijn er mensen die dit soort ervaringen hebben gehad?

De taal is trouwens Java en het platform windows xp/windows 2003 server.

[ Voor 8% gewijzigd door Alarmnummer op 19-01-2005 09:41 ]

[-FoX-]

Zou het misschien kunnen zijn dat bepaalde poorten geblockt worden door de firewall?
En er hierdoor bepaalde sockets een timeout veroorzaken?

[Alarmnummer]

-FoX- schreef op woensdag 19 januari 2005 @ 09:43:
Zou het misschien kunnen zijn dat bepaalde poorten geblockt worden door de firewall?
En er hierdoor bepaalde sockets een timeout veroorzaken?

Een socket mag best een timeout veroorzaken... daar kunnen wij niets aan doen. Maar wat zo vervelend is, is dat zo lang die 'rotte' socket bezig is om een timeout te veroorzaken dat we niets horen van onze andere SmptConnections (die gebruik maken van hun eigen socket naar een hele andere smtp server) die door andere threads worden gebruikt.

Gewoonlijk werken alle sockets dus goed multithreaded en helemaal door elkaar heen. Maar de indruk bestaat dat zolang 1 socket een timeout aan het veroorzaken is dat de rest niets doet.... soortement van collectieve staking als 1 wordt ontslagen..

[ Voor 9% gewijzigd door Alarmnummer op 19-01-2005 09:50 ]

[mulder]

Ik heb de ballen verstand van sockets maar misschien is dit wat:
http://support.microsoft....aspx?scid=kb;en-us;310155

[Alarmnummer]

Don Facundo schreef op woensdag 19 januari 2005 @ 11:39:
Ik heb de ballen verstand van sockets maar misschien is dit wat:
http://support.microsoft....aspx?scid=kb;en-us;310155

In dit geval doen we niets met IIS. Het is een door ons zelf geschreven SmptConnectie die direct met een Smtp server verbinding kan zoeken. Zelfs JavaMail API zit er niet tussen (te weinig controle).

[The End]

Dit klinkt gewoon als een bug ergens. Ik heb dit gedrag nog nooit gezien iig.

Spreken jullie die sockets aan binnen critical sections o.i.d. ?

[Alarmnummer]

The End schreef op woensdag 19 januari 2005 @ 11:53:
Dit klinkt gewoon als een bug ergens. Ik heb dit gedrag nog nooit gezien iig.

Spreken jullie die sockets aan binnen critical sections o.i.d. ?

Nope.. als er geen socket timeout optreed (dus lieve sockets), dan gaat het perfect. Dan draaien de smpt connections volledig door elkaar (dus meerdere sockets op hetzelfde moment en voor 'lange' tijd open en werken volledig onafhankelijk van elkaar).

Ik heb trouwens net een kleine timeout server geschreven die zo nu en dan door een smtp connection wordt gebruikt en nu gaat alles wel goed. Ik zit dus ook even met mijn handen in mijn haar als ik de fout niet kan herproduceren.

[The End]

Alarmnummer schreef op woensdag 19 januari 2005 @ 12:05:
[...]


Nope.. als er geen socket timeout optreed (dus lieve sockets), dan gaat het perfect. Dan draaien de smpt connections volledig door elkaar (dus meerdere sockets op hetzelfde moment open en werken volledig onafhankelijk van elkaar).

Ik heb trouwens net een kleine timeout server geschreven die zo nu en dan door een smtp connection wordt gebruikt en nu gaat alles wel goed. Ik zit dus ook even met mijn handen in mijn haar als ik de fout niet kan herproduceren.

Ik bedoel meer of er dit soort functies zijn:

code:

EnterCriticalSection

Socket.Send(DataSharedByManyThreads);

LeaveCriticalSection

Als je steeds stukjes data verstuurd of gewoon heel weinig in totaal dan zal er nooit wat mis gaan, totdat 1 socket gaat wachten op een timeout. Deze houdt dan de critical section gelocked, waardoor de andere sockets ook niks meer kunnen versturen.

[Alarmnummer]

The End schreef op woensdag 19 januari 2005 @ 12:08:
[...]

code:

EnterCriticalSection

Socket.Send(DataSharedByManyThreads);

LeaveCriticalSection

Iedere thread heeft zijn eigen socket. Dus er is geen gesharde resource waar op gewacht moet worden.

[ Voor 3% gewijzigd door Alarmnummer op 19-01-2005 12:19 ]

[The End]

Alarmnummer schreef op woensdag 19 januari 2005 @ 12:17:
[...]

Iedere thread heeft zijn eigen socket. Dus er is geen gesharde resource waar op gewacht moet worden.

Het gaat er niet om of de socket tussen threads geshared wordt, maar of de data, die verstuurd wordt, geshared wordt door meerdere threads.

[elevator]

Alarmnummer schreef op woensdag 19 januari 2005 @ 09:40:
De taal is trouwens Java en het platform windows xp/windows 2003 server.

Je krijgt niet toevallig (op je XP machine) een melding in de log dat je aantal sockets gethrottled worden?

Verder - zoals hier al eerder aangegeven wordt, weet je zeker dat er geen (te simpele) DDoS protectie in je firewall zit die gewoon een minuut lang zegt 'even geen connecties' of iets dergelijks?

[Alarmnummer]

The End schreef op woensdag 19 januari 2005 @ 12:19:
[...]


Het gaat er niet om of de socket tussen threads geshared wordt, maar of de data, die verstuurd wordt, geshared wordt door meerdere threads.

Ook niet Het is echt geen locking probleem op mijn nivo. Daarom is/was mijn vermoeden dat het een locking probleem was op lager nivo. Bv de VM of het OS.

Ik heb het probleem intussen geprobeerd te simuleren met een server die altijd een timeout geeft, en hier gaat het wel goed.. (Er worden nog steeds multithreaded berichten verstuurd naar meerdere servers terwijl 1 socket dwars ligt). Dus daar gaat het exact zoals wij het willen.

[ Voor 38% gewijzigd door Alarmnummer op 19-01-2005 12:29 ]

[chielsen]

Ik ken dit probleem.

Ik was iets aan het testen op mijn pc (windows xp) met sockets.
Als ik verkeerde parameters meegaf raakte hij van slag en liep heel php vast (apache bleef nog wel lopen). Als ik op tijd stop met het script laden, dan kwam php er na een paar minuten weer overheen, anders moest ik apache weer opnieuw opstarten.
Het vreemde is dat ik een hele lage timeout en script execution tijd opgaf, toch blijf hij nog doorlopen zo leek het...

[Verwijderd]

misschien blokkeren je sockets niet , maar je logfunctionaliteit
als dat zo is zo na het verdwijnen van de lockup ineens een aantal logmessages tegelijk moeten verschijnen.
/me ReSc krijgt altijd hoofdpijn van MT synchronisatie bugs

edit:

hier heeft er ook iemand problemen met z'n sockets, misschien kan je daar wat hints vinden

[ Voor 28% gewijzigd door Verwijderd op 19-01-2005 18:15 ]

[Alarmnummer]

Verwijderd schreef op woensdag 19 januari 2005 @ 18:00:
misschien blokkeren je sockets niet , maar je logfunctionaliteit

Ik neem aan dat een logcall niet blokkeert. En ook al zou hij wel blokkeren, ik zie de relatie tussen een blokkerende socket en een logger niet.

code:

logger.acquire();

logger.info("blabla")

rotteSocket.getInfo();

logger.release()

Als het logger en zo uit zou zien dan ja... maar zo ziet het er niet uit, dus ik zie niet hoe het systeem op de logger zou kunnen blokken.

als dat zo is zo na het verdwijnen van de lockup ineens een aantal logmessages tegelijk moeten verschijnen.

Yep.. maar ik kan niet zien of die berichten zijn ontstaan tijdens de 'lock' of omdat de threads wakker worden.

Ik ben ook nog niet in staat geweest om de fout te herproduceren.

[Infinitive]

Het zou wel heel erg toevallig zijn, maar het zou kunnen dat de sockets die een timeout gaven, toevallig allemaal naar dezelfde server connecten? Een mailserver kan meerdere ip-adressen hebben en naar die ip-addressen kunnen weer meerdere domainnamen aan gehangen zijn.

Of een rotte router dichtbij in je netwerk die poort 25 connecties dropt... hoewel zoiets mij sterk lijkt.

Ik verwacht eerlijk gezegt niet dat er een of andere bug in de socket functionaliteit van je operating system zit. Zoiets zou allang gedetecteerd en opgelost moeten zijn.

Helaas kan ik je geen reden geven. Als je het probleem niet kan herproduceren en er ook geen aanleiding bestaat waar het probleem te zoeken valt, dan zijn er nog maar weinig mogelijkheden over...

[ Voor 16% gewijzigd door Infinitive op 19-01-2005 18:20 ]

[Alarmnummer]

Infinitive schreef op woensdag 19 januari 2005 @ 18:19:
Het zou wel heel erg toevallig zijn, maar het zou kunnen dat de sockets die een timeout gaven, toevallig allemaal naar dezelfde server connecten? Een mailserver kan meerdere ip-adressen hebben en naar die ip-addressen kunnen weer meerdere domainnamen aan gehangen zijn.

Nee.. het zijn allemaal verschillende smtp servers die echt op verschillende computers draaien.

Helaas kan ik je geen reden geven. Als je het probleem niet kan herproduceren en er ook geen aanleiding bestaat waar het probleem te zoeken valt, dan zijn er nog maar weinig mogelijkheden over...

Yep.. maar dat is het leven van een developer he

[Verwijderd]

Yep.. maar ik kan niet zien of die berichten zijn ontstaan tijdens de 'lock' of omdat de threads wakker worden.

logmessages timestampen met System.currentTimeMillis() en dan kijken naar het patroon in de tijden, als er echt iets goed blokkeert dan zit er een "gat" in de tijden


Ik weet natuurlijk niet hoe jij je log gebeuren hebt geimplementeerd, maar je geeft zelf het voorbeeld van hoe het niet moet , dus dan zal het daaraan niet liggen, maar het had zomaar gekunt.

misschien loop je tegen een aantal windows XP limieten aan kwa sockets,
bijvoorbeeld als je heel snel heel veel sockets connect/disconnect, heb je al snel dat al je beschikbare sockets in TIME_WAIT status staan, en die zijn niet meer te gebruiken, totdat ze uit de TIME_WAIT status komen. misschien heb je last van zo'n soort "bug" (dwz je OS doet dingen die je niet verwacht ipv dat er een bug in je code zit)

zie ook de link in de edit van m'n vorige post, das dan wel op .net, maar die heeft ook vage dingen met z'n sockets.

kan je het stukje code laten zien waarin de connectie wordt opgebouwd?
misschien kan ik er dan meer van zeggen.

edit:

en er viel mij ineens iets te binnen, als je connect call op een dusdanige manier blockt dat de thread waarin je connect de cpu niet vrijgeeft tijdens het wachten op de timeout, kan je nog zoveel threads opstarten, maar als ze niet op de cpu kunnen , doen ze ook niks
de documentatie van je socket lib moet daar wat zinnigs over te zeggen hebben

[ Voor 19% gewijzigd door Verwijderd op 19-01-2005 18:50 ]