[MXS-260] Multiple MaxScale processes Created: 2015-07-10  Updated: 2015-08-25  Resolved: 2015-08-25

Status: Closed
Project: MariaDB MaxScale
Component/s: Core
Affects Version/s: 1.2.0
Fix Version/s: 1.3.0

Type: Bug Priority: Major
Reporter: Dipti Joshi (Inactive) Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None
Environment:

RHEL 6.6, CentOS 6.6



 Description   

if you run 3 time maxscale you get 3 process



 Comments   
Comment by markus makela [ 2015-07-10 ]

This needs more information.

Comment by markus makela [ 2015-07-13 ]

The process was called directly three times with the save configuration file. This should have resulted in only a single running maxscale process instead of three since the other two should have failed to bind to the same ports the first was already bound to. The configuration file listed a socket which is the probable cause for this.

Comment by Dipti Joshi (Inactive) [ 2015-07-15 ]

stephane@skysql.com, stephanevaroqui Please attach the config file used when this happened.

Comment by markus makela [ 2015-07-20 ]

Added functionality which checks if a MaxScale process is already running.

Comment by martin brampton (Inactive) [ 2015-08-24 ]

I'm wondering if this problem has been correctly diagnosed. It is intended that MaxScale should be capable of running more than once on a single machine, provided that each instance has its own configuration file and the use of ports does not conflict. Does the proposed solution retain the capability to run multiple instances of MaxScale?

Comment by markus makela [ 2015-08-24 ]

With the changes in the development branch, you should be able to control the location of the PID directory and the configuration file you use. This way you should be able to run MaxScale on the same machine provided that nothing conflicts.

Comment by martin brampton (Inactive) [ 2015-08-24 ]

OK, great, thanks for the clarification.

Comment by Dipti Joshi (Inactive) [ 2015-08-24 ]

markus makela Is this closed now ?

Generated at Thu Feb 08 03:57:59 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.