<div dir="ltr"><div>I appreciate your help, probably the library is smart and elegant, but I will not use it and I will recommend not using it to anybody in my situation.</div><div>Why?</div><div>My situation is a dead simple case from the first page websocket book. </div><div>1. Serial write to session</div><div>2. Clean resources on-session-close</div><div>The first is implemented by blocking queue and VT, the second is implemented by interrupting VT to let them die. It would be elegant to let GC  kill VT. but now it does not work.<br>In this situation I prefer to bloat code a little and manually interrupt the thread rather than taking a library, which is hard to understand (not because of bad code style but due complex domain).</div><div>Commenting in code that this library automatically cleanups thread would be longer and more elaborative than its own implementation.</div><div><br></div><div>My additional concern is QueueClosedException. Must the producer of messages care about it or not? I think yes, maybe  I do not understand the code. With blocking queue there is no doubt - if producer has reference to abandoned queue, he may put anything into, it will GCed</div><div><br></div><div>I think this library is very useful for real usage as well as for learning. But as project manager, which must take care of codebase maintainability, I will not agree to import complex-domain library  to solve trivial case.<br><br>I was already engaged in ephemeral VT discussion, I remember this library, now I have a second use-case (websocket) for why I would like to use ephemeral thread. </div><div>But one thing has not changed - the library does not fill my requirement - I think it is impossible without true ephemeral threads.<br>My requirement is:<br>1. One thread may decide to release the blocking queue and its resources(VT) by removing the queue from global concurrent map</div><div>2. But the second thread may trust the queue is working as long as the second thread has a reference to the blocking queue. Especially, it means no QueueClosedException. Because the queue is not closed. Because the reference is live.Additionally, for my previous, not-websocket use case, even if one thread decided to release a resource, it does not mean blocking consumer may disappear. I expect the consumer to be like a captain on the sinking ship - continue work to the end, of course with some deviation from ordinary flow. </div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">sob., 10 sty 2026 o 16:34 Robert Engels <<a href="mailto:robaho@me.com">robaho@me.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">If you’re working with queues, a “closable queue” works well and it’s non intrusive. See the docs. </div><div dir="ltr"><br></div><div dir="ltr"><div style="display:block"><div style="display:inline-block" role="link"><a style="border-radius:10px;font-family:-apple-system,Helvetica,Arial,sans-serif;display:block;width:300px;overflow:hidden;text-decoration:none" rel="nofollow" href="https://github.com/robaho/closablequeue" dir="ltr" role="button" width="300" target="_blank"><table style="table-layout:fixed;border-collapse:collapse;width:300px;background-color:rgb(230,230,230);font-family:-apple-system,Helvetica,Arial,sans-serif" cellpadding="0" cellspacing="0" border="0" width="300"><tbody><tr><td align="center"><img style="width: 300px; height: 150px;" width="300" height="150" alt="closablequeue.png" src="cid:ii_19baa537878e35bacc51"></td></tr><tr><td><table bgcolor="#E6E6E6" cellpadding="0" cellspacing="0" width="300" style="table-layout:fixed;font-family:-apple-system,Helvetica,Arial,sans-serif;background-color:rgb(230,230,230)"><tbody><tr><td style="padding:8px 0px"><div style="max-width:100%;margin:0px 16px;overflow:hidden"><div style="font-weight:500;font-size:12px;overflow:hidden;text-overflow:ellipsis;text-align:left"><a rel="nofollow" href="https://github.com/robaho/closablequeue" style="text-decoration:none" target="_blank"><font color="#000000" style="color:rgb(0,0,0)">robaho/closablequeue: a Java FIFO blocking queue with "close" semantics. designed for virtual threads.</font></a></div><div style="font-weight:400;font-size:11px;overflow:hidden;text-overflow:ellipsis;text-align:left"><a rel="nofollow" href="https://github.com/robaho/closablequeue" style="text-decoration:none" target="_blank"><font color="#A2A2A9" style="color:rgba(60,60,67,0.6)">github.com</font></a></div></div></td></tr></tbody></table></td></tr></tbody></table></a></div></div><br></div><div dir="ltr"><br><blockquote type="cite">On Jan 10, 2026, at 6:52 AM, Michal Domagala <<a href="mailto:outsider404@gmail.com" target="_blank">outsider404@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Hi,<br><br>I would like to present my case for ephemeral VT.<br>I have a websocket, the websocket has a correlated blocking queue, there is a virtual thread which reads from the queue and writes to the websocket session.<br>When session is closed, I remove blocking queue from global concurrent hash map<br>But I have to<br>- keep reference to VT<br>- interrupt VT on-session-closed<br>It is similar to  C++ destructor.<br>If I can rely on GC, I will just remove blocking queue reference and everything will happen automatically.<br><br>Regards,<div>Michal Domagala<br><br></div></div>
</div></blockquote></div></blockquote></div></div>