爲什麼駱駝在inflightrepository中保留交換？

我的團隊有一個運行（非常簡單）的服務通過Apache駱駝運行，功能上一切都測試正常，但負載測試表明，該服務隨着時間的推移會消耗內存。深入研究堆轉儲的結果是，內存消耗來自機庫。看起來，通過路線發送的每一個交易所都被保留，但我們無法確定爲什麼在路線完成並且交易成功交付後應該保留交易所的任何理由。爲什麼駱駝在inflightrepository中保留交換？

我的團隊對問題的最初反應是膝關節內存泄漏，但我不相信這是事實 - 我們只是有一個意想不到的行爲 - 引用垃圾收集不會嘗試處理它們。

難題在於它不僅僅是交換的一個副本，它似乎被保留，它是交換生命週期中保留的每一步，而路由並不特別複雜，它實現了分離 - 聚合路線，然後誇大了問題。

我們已經考慮添加一個組件來沖洗inflightrepository中的陳舊交換，但是這沒有想到這一點。

任何人都可以解釋爲什麼駱駝表現得像這樣？

來源

2017-08-16 Julian

沒有代碼？我沒有看到我的路線上的這種行爲。 – Namphibian

如果不提供服務的完整代碼 - 本身就有大量的代碼，那麼提供一些代碼段就相當沒有意義。這不是問題 - 駱駝保留機上交流的原因是什麼？也許「駱駝什麼時候從inflightrepository中刪除交換？」將是一個更好的問題... – Julian

我還沒有看到這種行爲。 – Namphibian

經過相當多的挖掘後，解決方案變得非常簡單。該路由生成自定義的exchangeId，以簡化客戶對請求進行交換的跟蹤。結果是，在路由結束時，當交換被銷燬（從機艙庫中刪除）時，存儲庫中的exchangeId：exchange的key：value映射不包含自定義exchangeId，並且由於顯而易見的原因，不刪除完成的交易所。

這似乎是使用聚合策略的副作用。沒有這個交易所按預期被移除。

總之是用戶錯誤...

來源

2017-11-15 15:22:44 Julian

根本沒有用戶錯誤。你的回答幫助我意識到了這個問題，但是駱駝有一個由exchangeId索引的機上倉庫，而且我們可以簡單地執行'exchange.setId（「mashedPotatoes」）'這並不會自動更新上述倉庫是框架的錯誤，不是我們的。這種行爲應該被封裝。由於此問題導致內存泄漏，所以我們只是應用程序崩潰。 – henry700

爲什麼駱駝在inflightrepository中保留交換？

回答

相關問題