This message was deleted.
# general
s
This message was deleted.
a
Could you please check
druid_tasklocks
table in your metadata store and perhaps share the results of a select * for this datasource?
1
If the entries are present in the logs (implying that they are in memory) but not the tasklocks table, it could mean that there was an issue with the Overlord and a master node restart could help
s
It was not preset in the metadata database. I did a restart to overload process and it worked.
👍 1
Does that mean , those were in memory ?
a
Yes, there may have been an issue with task lock clean up
Would you mind raising a github issue with your Overlord logs?
s
Sure. I can .
a
Thank you!
s
@Amatya Avadhanula , let me know if any more details required on this. Will be more than happy to provide ,
a
Thanks again for creating it. It would be great if you could include overlord logs for a longer duration. (Starting when the old tasks were created which did not clean up their locks in memory until the restart)
s
Sure, I'm trying to get the old logs from my log repo. Will upload by tomorrow
It seems for the failed MSQ jobs, the slots are not clearing properly and its restricting to spinup new tasks. Is there some sort of configuration we can do for a cleanup .
a
Do you see the failures without MiddleManager-less ingestion as well?
s
Its middle manager less configuration
While loading we had some issues in the file, thats why its failed. But the problem was it's not releasing the slots properly I guess, bcz of that we are not able to spinup new tasks
a
Hmm, it seems more likely that it's due to MM-less ingestion rather than it being specific to MSQ engine. It would be really helpful to get the overlord logs during this period to debug this better
s
okay.
I'm trying to get that