Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Q quickfix
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 48
    • Issues 48
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 25
    • Merge requests 25
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • quickfixgo
  • quickfix
  • Issues
  • #436
Closed
Open
Issue created May 13, 2021 by Sam Mulube@smulube

Concurrent map access panic in acceptor

Hello we are currently using QuickFIXGo in a UAT environment as an acceptor and we have been seeing intermittent panics related to concurrent map accesses within acceptor.go. Unfortunately I don't have a copy of the stack trace to hand but what I suspect is happening is related to concurrent modifications of the maps within the Acceptor struct (sessions which is a map[SessionID]*session and sessionAddr which is a map[SessionID]net.Addr).

Examples of the maps being read or modified inside a spawned goroutine I believe can be seen here: https://github.com/quickfixgo/quickfix/blob/master/acceptor.go#L291 or https://github.com/quickfixgo/quickfix/blob/master/acceptor.go#L307

We have created a fork of the library in which we've added a sync.RWMutex to Acceptor and we are now protecting any reads or modifications to either the sessions or sessionAddr maps, and since making this change we have not seen any repeat of the problem.

Would this change be useful to submit as a pull request, or is there some reason why those map modifications weren't already being guarded by a mutex that we are missing? It's possible that the fact that we haven't seen repeat occurrences is not related to our changes, but would be happy to send it over as a pull request if you think it would be useful.

thanks

Assignee
Assign to
Time tracking