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

Can't use Redis through UNIX socket for the task scheduler #9004

Closed
2 of 7 tasks
HorlogeSkynet opened this issue Nov 14, 2019 · 1 comment · Fixed by #9363
Closed
2 of 7 tasks

Can't use Redis through UNIX socket for the task scheduler #9004

HorlogeSkynet opened this issue Nov 14, 2019 · 1 comment · Fixed by #9363
Labels
type/enhancement An improvement of existing functionality

Comments

@HorlogeSkynet
Copy link
Contributor

  • Gitea version (or commit ref): v1.10.0
  • Git version: v2.20.1
  • Operating system: Debian Buster
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant

Description

Hey back the team, second issue of the evening.
It looks like we cannot make the task scheduler use Redis over an UNIX socket, as for the cache storage or the session provider.

[task]
QUEUE_TYPE     = redis
QUEUE_CONN_STR = network=unix addrs=/var/run/redis/redis-server.sock password=$PASSWORD db=$N pool_size=$X idle_timeout=$T

The service hard-fails at startup with :

routers/init.go:107:GlobalInit() [F] Failed to initialize task scheduler: dial tcp [::1]:6379: connect: connection refused

So this issue got multiple purposes :

  1. Should we be able to achieve this ?
  2. Why connection strings are not parsed consistently across different configuration entries ?
    • addr becomes addrs
    • Token separator is sometimes , and some other times
    • Some options as network, pool_size or idle_timeout are de facto not interpreted (still according to the parser sources of the task scheduler)
  3. kind/proposal : cache, session, task and issue indexer connection strings should be configured the same way.

Bye again 👋

@lunny lunny added the type/enhancement An improvement of existing functionality label Nov 15, 2019
@zeripath
Copy link
Contributor

Agreed - consistency is key.

I am in the process of trying to unify our queue creation - and to try to make it so that all queues can be persisted on shutdown.

@sapk sapk closed this as completed in #9363 Jan 7, 2020
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/enhancement An improvement of existing functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants