2010-06-28 2 views
6

Una connessione PipedInputStream/PipedOutputStream funziona alla grande quando i dati devono essere inviati a un solo output, ma se più flussi di output sono connessi a un flusso di input, i dati diventano frammentato tra le diverse uscite. La mia soluzione attuale consiste nel disporre di un "lettore" filettato che legge i dati da un InputStream e quindi scrive i dati negli oggetti OutputStream che sono stati associati al lettore. Questo sembra funzionare bene, ma sembra disordinato e inefficiente rispetto alle classi native di PipedIO.Il modo migliore per inviare dati da un flusso di input a più flussi di uscita

C'è un modo migliore per gestire questo o è l'implementazione che sto lavorando con circa buono come sto andando a ottenere?

risposta

1

Se un flusso di input deve essere letto da più utenti e il flusso di input è effimero (ovvero non è una risorsa che può essere "riavvolto" o supporta più puntatori di input) in genere è necessario fornire uno schema di buffer che si comporta come se conservasse ogni elemento di dati finché tutti i consumatori non lo hanno letto.

Avete diverse scelte sull'implementazione. Il più semplice è quello che suggerisci, poiché l'overhead è principalmente lo spazio di archiviazione per più copie dei dati nei buffer di output. Se la memoria è un problema, è possibile fornire un singolo buffer che mantiene separati i puntatori di lettura, uno per ciascun utente, e tiene in memoria solo i dati tra i puntatori di lettura più bassi e più alti. Se i consumatori leggono i dati a velocità notevolmente diverse, si potrebbe ancora finire con la maggior parte o tutti i dati di input in memoria, a quel punto diventerebbe necessario un qualche tipo di limitazione degli input o uno schema di buffering del disco intermedio.

Presumo che il singolo flusso di input non sia persistente (cioè un file su disco) ... in tal caso la soluzione è banale.

+0

Grazie per la risposta. Hai ragione nell'assumere che i dati non siano persistenti. Fondamentalmente sto leggendo i dati da una connessione SSH per scopi di verifica. Memorizzo le risposte dei comandi in modo che possano essere verificate rispetto al comportamento previsto, scrivere i dati in un registro di debug come richiesto e scrivere tutti i dati in una GUI a scopo di monitoraggio. Dal momento che mi preoccupo solo del buffering di piccole quantità di dati per la risposta al comando, penso che seguirò il mio metodo attuale o il metodo multiplex sopra a meno che non ci siano altri suggerimenti. – WeeTodd

0
+0

Grazie per la risposta. Avete qualche input in più su quanto bene funzionerebbe quando si deve parlare tra thread rispetto alla mia attuale soluzione? Ho provato a giocare con piping i dati di input a un flusso di output multiplex ma le prestazioni sembrano essere laggy e non altrettanto affidabili. – WeeTodd

+0

@WeeTodd Probabilmente avrai bisogno di confrontare le diverse soluzioni. Vorrei raccomandare di andare avanti e poi guardare a diverse opzioni se ti imbatti in problemi perf. Fai in modo che tu possa facilmente sostituire le implementazioni –