vaadin views never die

Hi we use vaadin 24 and our server get memory crash, the server have 80gb off memory
We do the profiler and we Discovery tha views after closed remaining in memory and the garbage collection never catch thei
We use the spring-boot with vaadin.
Anyone know what we do the wrong?
We try change the annotations to prototype and request but not work.

I think you need to add more information, with that little amount of information it’s quite hard to help you. Is it only one view that is never cleaned up? Can you explain which annotation you have currently? Usually memory leak is quite hard to debug. 80Gb of memory is really big

Hi Christophe thanks for your reply.
ALL views never cleaned UP
One time user open a view that instance remains open, even after user close the view.
When user open that view again, looks like a New instance is created.
The server increase memory use and never decrease, until crash.
Every nigth i have a process to stop the server and Restart for initialization the memory use.
The anotation is a spring @scope we try use prototype and a @scope(“request”)
But both react the same way.
I dont now is problem IS in vaadin or spring.
Or i need insert same code on detach listener.
Any way, i complete losted

this is the most use view in the system (61.8 KB)

Remove the component and scope annotation. Both are not needed.

Your setup sounds like the UIs are never cleared… you don’t have idle timeouts for your users or session clean up?

ok, i will remove.
i have the heartbeath configured, then when user dont use for a time, the session is closed. but ultil, the instance off view remain in memory


if i remove the @Component() the spring will know this wiew?

i dont use @Component() only if the view have route like this: @Route(value = ApiConst.PAGE_PAINEL_ATIVIDADE_VIEW, layout = MainLayout.class)
but if is a view that ai use inside another view, i always use the @Component()

this view “call” the AtividadeView (file insert bellow)

private final AtividadeView atividadeView;
public PainelAtividadesView(ProducaoPainelRepository ppr, PedidoOrigemService pos, EstruturaSenhasService estruturaSenhasService,
PedidoService pedidoService, PedidoEtapaService pedidoEtapaService,
EstruturaUsuarioService eus,
PedidoTagsService pedidoTagsService,
UsuarioTagService usuarioTagService,
PedidoAnexoService pedidoAnexoService,
PedidoMovimentacaoService pedidoMovimentacaoService, PedidoVinculoService pedidoVinculoService,
EquipeService equipeService,
PedidoEmailRepository pedidoEmailRepository,
AtividadeView atividadeView,
StorageService cs, PainelAtividadeExportacaoService painelAtividadeExportacao, UsuarioHierarquiaService hierarquiaService, PedidoLogService pedidoLogService,
GridOrderService gridOrderService, UsuarioService usuarioService,
WhatsAppAtendimentoCreate whatsAppAtendimentoCreate, WhatsAppAtendimentoService whatsAppAtendimentoService,
WhatsAppView whatsAppView, PedidoDeleteService pedidoDeleteService, ClienteContatoView clienteContatoView,
DownloadDialog exportDialog, PedidoEtapaGrupoService pegs) {

this.atividadeView = atividadeView;

atividadeView.create(pedido, getEu(), this.filter.getRbTipo().getValue());

The amount of injections make me wonder if there is some kind of circular dependency between components / views which creates your memory leak because they can’t GC :grimacing: but that’s impossible to debug from the outside

when i will compilation de code, if exists any circular dependence, de compilation fails. then i think that this do not exists.

you know if have any comand that i need insert in detachlistener to guarantee the class die and the GC get him?

You can’t really force GC, just hinting the system to do so. But that won’t help much while a reference is still in use.

Only thing to say: if you override detach - ensure to also call super.detach in there so that the default chain is still called

I would say you have to do memory profiling of your running instance to find what’s blocking your ram

ok, i will make a profiling in production and i post here.
for now, thank you so much

Just to be 100% clear: it is the heap that is full?
I’m asking because in my dev environment I recently got a “java.lang.OutOfMemoryError: Metaspace” with the same settings I have used for years for Vaadin8

Hi. Thanks for your reply. Yes i have 100% sure. The error when crash is the heap space