2015-10-31 24 views
9

Utilizziamo connessioni persistenti e abbiamo tentato di forzare le connessioni per essere rilasciati dopo x quantità di tempo. Mentre vedo che in teoria possiamo usare ConnectionKeepAliveStrategy, forma quello che posso dire che questo si applica solo dopo una risposta..i.e. mentre la connessione è inattiva.Apache HttpClient loadbalancing connessioni pool

Il problema che stiamo avendo ..

Assumere 1 client, colpendo 2 server (A, B), tramite una loadbalancer. Quando uno dei server passa offline (B), tutte le nuove connessioni vengono stabilite sul server contro (A). Ora quando l'altro server (B) torna online, rimarrà inattivo poiché tutte le connessioni si trovano sull'altro server (A). Finché il client continua ad accedere a una connessione al di sotto del timeout di inattività/keepalive, questo continuerà, lasciando il server B inattivo (ovvero con zero connessioni).

Ciò che vogliamo fare è forzare tutte le connessioni persistenti a chiudersi periodicamente (all'interno di una "finestra temporale casuale". Idealmente non vogliamo che tutte le connessioni si resettano contemporaneamente). Qualche suggerimento su come farlo?

Abbiamo provato ad estendere HttpClientConnectionManager ea tracciare per quanto tempo è stata aperta una connessione, quindi chiuderla dopo x tempo di ammontare ... tuttavia non sembra funzionare. Suppongo che questo sia dovuto al fatto che HttpClientConnection non è in realtà la connessione effettiva, ma è piuttosto un proxy e sembra che al di sotto di questo proxy, sia in realtà "in uso" una delle connessioni stabilite, in quanto tale rende impossibile monitorare effettivamente il tempo quelle connessioni sottostanti sono state stabilite per.

Pensieri?

In questo momento mi sto giocando con l'idea di semplicemente chiamando: HttpRequestBase.abort() il 1 collegamento per minuto una volta che abbiamo eseguito una richiesta su di esso, che credo ci avrebbe ottenere qualche cosa più vicino al comportamento desiderato.

+0

Hai il controllo del bilanciamento del carico? Forse una soluzione è disattivare le sessioni appiccicose. – kuporific

+0

Non ci sono sessioni adesive, il suo round-robbin..ma una volta che viene creata la connessione persistente. Rimane ... quindi la necessità di chiudere periodicamente le connessioni persistenti, così il lb può ancora una volta bilanciare il carico tra i server. – danomano

+0

Hai avuto qualche sfondamento in questo scenario? Ho esattamente lo stesso scenario alla ricerca di solide idee su come affrontarlo. – jagamot

risposta

2

Uno può limitare la durata totale di una connessione utilizzando il parametro TTL (time to live).

HttpClientBuilder.create() 
     .setConnectionTimeToLive(1, TimeUnit.MINUTES) 
     .build(); 

Ciò costringerà tutte le connessioni a rinnovarsi dopo un minuto.

+0

Ciò funzionerebbe ... ma ha il rovescio della medaglia che quando il client stabilisce connessioni X allo stesso tempo. Probabilmente causerà l'interruzione di tutte quelle connessioni contemporaneamente e il ripristino, non ideale. Avere il TTL randomizzato in una finestra temporale sarebbe l'ideale ... che è quello che sto cercando di fare. – danomano

+0

No, non lo farà. HttpClient non sfrutta proattivamente le connessioni scadute. Elimina le connessioni scadute passivamente quando prende in affitto una connessione dal pool. – oleg

+0

hmm, beh a questo punto mi sto appoggiando al mio hack di interrompere 1 connessione al minuto, o alcuni di questi. – danomano

3

Non penso che tu stia utilizzando correttamente il bilanciamento del carico. Se stai cablata come questo:

   +--> SA 
C <---> LB <--+ 
       +--> SB 

Il cliente può avere connessioni persistenti per il bilanciamento del carico. Le connessioni LB<-->SA e LB<-->SB possono essere con connessioni permanenti o meno, non importa. Il bilanciamento del carico dovrebbe comprendere HTTP e instradare su quel livello e non solo le connessioni TCP. Pertanto, due richieste HTTP in entrata (su LB) sulla stessa connessione persistente possono essere indirizzate a due server separati.

+0

Suppongo che l'LB possa far scorrere il LB -> (SA, SB) ad un intervallo di tempo, assicurando che se SB dovesse sparire, potrebbe sotto, ristampare le connessioni SB Connections una volta ritornato .. (chiudendo le connessioni SA) .. nel frattempo il cliente sarebbe ignaro di ciò. – danomano