![]() |
Telelogic SYNERGY (steve huntington) | ![]() |
Topic Title: Experiences with multiple CS 4.2 instances on the same database? Topic Summary: Created On: 3-Nov-2004 13:37 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: Sorry to insist: you can have several CS installations on a machine, each one using a unique TCP port (8600, 8601, 8602, for example). Each CS installation can handle several CM database (at least one). But one CM database must be handled by one and only one CS installation. | |
![]() |
|
As the title suggests, I'd be interested in any comments along these lines. We have implemented 2 CS instances tied to our CM database, each has a slightly different workflow. Since doing this, we've had some issues with one of the ports going into an unresponsive state, which requires a stop/start of the service. They are on unique ports, and it's not a regular occurrance, but is somewhat annoying.
Has anyone implemented this successfully, and what suggestions/observations/tips can you pass along that we should be considering in our implementation? Thanks! Greg O. |
|
![]() |
|
![]() |
|
CS does not support the configuration you are trying to set up there !!! There should not be several CS installations on the same CM database... and as far as I know, there is definitly not need for such configurations !
If you need two (or more) different workflows in one CM database (for exemple for defects and enhancement requests), you just need to have two different lifecycles in your CRProcess. Anyway, only one CS installation is supported on each CM database. Please explain what you are trying to do. HTH Vincent |
|
![]() |
|
![]() |
|
Thanks for the reply, I guess our environment is a little different than yours. Basically we have a few major CM databases at this site, and we presently have two other sites that we DCM with-- so obviously we have several CM databases globally. As it applies to CS, we do leverage the capabilities to link change requests to CM tasks, but the complexity comes in from workflows and user management. We roll up some projects based on how we market and support them, and due to many dependancies, we really work out of one main CM database with current and future projects. Although the users can access if they know the correct port number, we do have a unique set of CS packages for each based on the requirements.
On our "production" system we have 2 instances, in our development environment, we have 3. Generally, they work pretty well, and actually in the past week, we have had not a single case of the service needing a restart. As far as a supported configuration, I do believe that this is ok, the trick is that each installation needs to use a different port. Refer to the CS installation guide for windows, the appendix refers to resolving port conflicts for "one or more ChangeSynergy installations". Our Telelogic AE hasn't mentioned any concerns with our setup either, and he is familiar with what we are doing, and how we work. |
|
![]() |
|
![]() |
|
Sorry to insist: you can have several CS installations on a machine, each one using a unique TCP port (8600, 8601, 8602, for example). Each CS installation can handle several CM database (at least one). But one CM database must be handled by one and only one CS installation.
|
|
![]() |
|
![]() |
|
Hi Guys sorry to but in but Vincent your totally wrong I received instructions straight from Tech support on setting up the very thing Greg is talking about and have the same configuration currently running. But sorry I can't offer any assistance with your problem Greg, My only problem (don't think is related to 2 CS installs) is CM likes to drop the INFORMIX databases for no apparent reason.
Brian |
|
![]() |
|
![]() |
|
Sorry for the long time elapsed, but we recently resolved the issue I think. We brought one of Telelogic's consultants onsite for a few weeks back in March for some assistance with doing our upgrade to 4.3, and took a few moments to look into this while he was here. He focused in on the jetty service itself, and more closely on the java environement that it runs in. While I have heard many different answers from support, the usual, upgrade to 4.3 and it's fixed, but in continuing to probe into what the root cause, I was told that the jetty version changed, then when I looked, it was the same. Long story short, they did double the memory available to java in 4.3, from 128mb to 256mb. The consultant (Ian) suspected that we may have been running out of memory space. After increasing this parameter in our 4.2 instance to match the default 4.3 value, we've had very few failures!
Also, we do nightly database packs, and it was suggested that we first shutdown the jetty service, then do the packs, and restart jetty after the database is back online. I think the combination of these two modifications has greatly improved our stability, and all but eliminated the problem. Maybe this will help someone else, just looking for some other unrelated help today, and saw this still hanging out here. Thanks to all, Greg Oman |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.