#metabrainz

nelgin: heh. if they're forwarded to docker, `docker logs --tail 100 docker-mq` might have them

I'm assuming docker-mq is the name of that container here

iliekcomputers: added tests

might need `docker-compose logs ...` instead

OK there we go

mq_1 | =ERROR REPORT==== 1-Sep-2020::17:44:02 ===

mq_1 | Channel error on connection <0.157.11> (172.18.0.5:38782 -> 172.18.0.3:5672, vhost: '/search-index-rebuilder', user: 'sir'), channel 2:

mq_1 | operation basic.publish caused a channel exception not_found: no exchange 'search' in vhost '/search-index-rebuilder'

interesting

It seems to be constantly throwing out those messages

is the indexer container running? I'm pretty sure sir should create those

[listenbrainz-server] paramsingh merged pull request #1054 (master…fix-spotify-imports): Improve spotify imports https://github.com/metabrainz/listenbrainz-serv...

every 2 minutes

Ah. no it isn't

might need to check sir/indexer logs (not sure what the name of it is)

musicbrainz-docker_indexer_1 python -m sir amqp_watch Exit 1

shivam-kapila: thank yoU!

can you start it, or does it always crash on that command?

Let me see. I'm lagging it bit on my pc due to the vm.

np

Ok, it's now saying that it's up

$ sudo docker-compose up -d indexer

musicbrainz-docker_search_1 is up-to-date

musicbrainz-docker_mq_1 is up-to-date

musicbrainz-docker_db_1 is up-to-date

Starting musicbrainz-docker_indexer_1 ... done

musicbrainz-docker_indexer_1 python -m sir amqp_watch Up

cool. unclear why it was down, but :)

hopefully that resolves the amqp errors?

Nope.

operation basic.consume caused a channel exception not_found: no queue 'search.index' in vhost '/search-index-rebuilder'

Still getting that error

hmph

Let me pastebin something from the indexer

try running `sudo docker-compose exec indexer python -m sir amqp_setup` again since that *should* declare those

Ok done. Let me try again.

yeah...those should be created by amqp_setup in theory

Ok, now it looks like I'm getting some success.

Now it's processin 2020-08-16 and earlier it was 2020-08-14. Would I have lost anything in the database replication or should it be good?

great

*processing

if it's running smoothly it should be good since it wouldn't allow applying packets out of order

Hmm, still getting a spurious error

WARNING: SET CONSTRAINTS can only be used in transaction blocks

XIDs Stmts est% XIDs/sec Stmt/sec

832 3625 54% 13 60WARNING: amqp could not commit tx mode on broker 1, reply_type=2, library_errno=4

1507 6631 100% 18 81 81.58 sec

that SET CONSTRAINTS warning can be ignored (I should look into fixing that), but the amqp one is troubling since I thought we fixed that :)

are you still getting errors in the mq logs?

Yeah, I knew about the SET CONSTRAINTS

I think I need to get another 32gb of memory for my pc if I'm going to be running docker on a vm lol

how much do you have now? :)

mq_1 | client unexpectedly closed TCP connection

I wonder if that's caused by the load on the server.

runq is a t5.8

is at 5.8

32gb now

I think. Let me check, it might be 16 lol.

might be an important detail to check

I'd hope 16gb should me more than enough in either case, but

be*

16gb

the indexer likes to suck up ram I guess

the vm has 127mb free, so yeah. I think it likes it.

Oh hell. I only gave it 1 core lol.

yikes

iliekcomputers: I now have a docker setup with goaccess that could be a simple starting point.

That explains everything lol

also, unsure about those TCP connection errors, but you can probably ignore them too...

They seemed to happen why my pc was hanging so probably caused by timeouts rather than anything else.

ah, could be

Ok, lets try this again with 4 cores :)

Alright, I need to get back to work. Thanks for your help, it seems to be going smoothly now.

np, glad it's working!

Are you going to let yvanzo know about the issues?

I'll be sure to link him the chatlogs once he's back

Cool thanks.