Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

memqueue_test.go makes use of Redis #162

Closed
shaunco opened this issue Nov 21, 2021 · 7 comments
Closed

memqueue_test.go makes use of Redis #162

shaunco opened this issue Nov 21, 2021 · 7 comments

Comments

@shaunco
Copy link
Contributor

shaunco commented Nov 21, 2021

Perhaps I'm missing something obvious, but I don't see why memqueue/memqueue_test.go uses a Redis Ring. Given that memqueue/queue.go is supposed to be an entirely in-memory queue, it seems odd that the unit tests are some weird hybrid of in-memory and Redis.

@vmihailenco
Copy link
Owner

Perhaps it should not.

But it is this way, because back in the days redisq backend did not exist and I needed some way to use taskq locally without S3/SQS. So I've replaced S3 with memqueue and left Redis as is because it is easy to run Redis locally.

@shaunco
Copy link
Contributor Author

shaunco commented Nov 21, 2021

Happy to put together a PR to remove Redis from the memqueue_test.go file if you'd be willing to consider it.

@vmihailenco
Copy link
Owner

Looks related to #106? I guess we could use local storage with memqueue by default.

@shaunco
Copy link
Contributor Author

shaunco commented Nov 21, 2021

Agreed, local storage would be the ideal fix.

vmihailenco added a commit that referenced this issue Nov 22, 2021
fix: Use localStorage for memqueue tests instead of Redis for #162
@mrz1836
Copy link

mrz1836 commented Jan 9, 2022

Any idea when a new release will be made? Looks like there's some fixes still in the v3 branch but not in an tagged version (yet).

Thanks!

@lilien1010
Copy link
Collaborator

I think we can close #163 as this is merge now :

@lzap
Copy link

lzap commented Jan 3, 2023

Hey, I am trying to use the in-memory queue but it still appears to require redis (taskq 3.2.9):

		factory := memqueue.NewFactory()
		queue.JobQueue = factory.RegisterQueue(&taskq.QueueOptions{
			Name:        config.QueueName(),
			Storage:     taskq.NewLocalStorage(),
			WorkerLimit: 1,
		})

I am running into:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x38 pc=0x1037afb70]

goroutine 79 [running]:
github.com/bsm/redislock.(*Client).obtain(0x140002b5260, {0x10475ca20, 0x140000ac960}, {0x140001a35f0, 0x24}, {0x14000b31c68?, 0x1056c8300?}, 0x64?)
        /Volumes/SSD/Go/pkg/mod/github.com/bsm/[email protected]/redislock.go:101 +0x50
github.com/bsm/redislock.(*Client).Obtain(0x140002b5260, {0x10475c9e8, 0x140001a4000}, {0x140001a35f0, 0x24}, 0x1037cb70c?, 0x0)
        /Volumes/SSD/Go/pkg/mod/github.com/bsm/[email protected]/redislock.go:73 +0x1b8
github.com/bsm/redislock.Obtain({0x10475c9e8, 0x140001a4000}, {0x0?, 0x0}, {0x140001a35f0, 0x24}, 0x14000084688?, 0x102388310?)
        /Volumes/SSD/Go/pkg/mod/github.com/bsm/[email protected]/redislock.go:129 +0x98
github.com/vmihailenco/taskq/v3.(*Consumer).lockWorker(0x1400013dc70, {0x10475c9e8, 0x140001a4000}, 0x0, 0x2101?)
        /Volumes/SSD/Go/pkg/mod/github.com/vmihailenco/taskq/[email protected]/consumer.go:720 +0x170
github.com/vmihailenco/taskq/v3.(*Consumer).worker(0x1400013dc70, {0x10475c9e8?, 0x140001a4000}, 0x0)
        /Volumes/SSD/Go/pkg/mod/github.com/vmihailenco/taskq/[email protected]/consumer.go:468 +0xd8
github.com/vmihailenco/taskq/v3.(*Consumer).addWorker.func1()
        /Volumes/SSD/Go/pkg/mod/github.com/vmihailenco/taskq/[email protected]/consumer.go:276 +0x64
created by github.com/vmihailenco/taskq/v3.(*Consumer).addWorker
        /Volumes/SSD/Go/pkg/mod/github.com/vmihailenco/taskq/[email protected]/consumer.go:274 +0x1c0

So I guess that is not all that needs changing :-(

Edit: It is a bug: #176

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants