Odd ESB Route deployment through the TAC

[n999]

Hello

We are on 6.4.1.

We have published a developed Route to Nexus from the Studio at multiple versions to our Snapshots repo. Say we have versions 1.1.0, 1.1.1 and 1.1.2 as we develop the Route.

In the Tac: When we Add a new Task on the ESB Conductor page, we browse to a Feature published to Nexus at version 1.1.0 and then Deploy and Start. All works fine.

In the Tac when I amend the Task and browse to feature version 1.1.1, my code changes are not reflected on the ESB!

I try and undeploy and delete the task and get odd messages from the TAC about the version not being deployed or that undeloyment will not remove this version from the ESB. I do delete the task and try version 1.1.2.

Nothing I do in the TAC to add 1.1.2 will cause my changes to be picked up, even though the TAC says 1.1.2 is deployed and started.

I then, for the first time ever, used the CLI client in /opt/talend/6.4.1/runtime/bin/client.sh to query the ESB.

When I >list the Active instances running I can see that all 3 versions are Active. This explains what is happening.

I bundle:uninstall the 2 older versions and my code changes are now there.

I bundle:uninstall  ALL versions, delete the Task in the TAC, restart the ESB runtime service and create the Task again in the TAC. 

I  I >list the Active instances running I can see that all 3 versions have come back and are Active again!

I check the artefact in the repo and the Feature xml file that you browse to in the TAC to create the task only mentions one version number, not all 3.

What is going on here? Why does the TAC tell me all is fine? How can I trust the TAC when I deploy new code live?

Thanks for any advice.

[n999]

Okay 

I've a route called route1 that hands off to 2 Talend Jobs (through cTalendJob components).

When I deploy the route feature using the TAC at particular versions and query in the CLI I see

> feature:list | grep myRouteName

myRouteName-feature | version 1

myRouteName-feature | version 2

> bundle:list | grep myRouteName

437 │ Active │ 80 │ version 1 │myRouteName
438 │ Active │ 80 │version 1 │myRouteName_SUB_01_myJobName
439 │ Active │ 80 │version 1 │myRouteName_SUB_02_myJobName
440 │ Active │ 80 │version 2 │myRouteName
441 │ Active │ 80 │version 2 │myRouteName_SUB_01_myJobName
442 │ Active │ 80 │version 2 │myRouteName_SUB_02_myJobName

So the bundles are the component parts of a feature....?

[Anonymous]

Yes, that is correct. What you need to do is remove ALL route1 feature versions (using the Karaf client), then add the feature you require with TAC. I suspect that your multiple features are "orphaned" and have no links to TAC anymore. Once you have removed them and added the one you require, so long as you continue to use TAC to add then remove completely, you should be able to rely on the TAC to handle this.

[sheftalenduser]

Hi

Very interesting exchange and describes almost exactly the TAC behaviour we're seeing on our site, also on 6.4.1. You mentioned raising a issue with R&D about how TAC interprets Route status - has this been progressed at all? We do intend to migrate to version 7 this year and wonder if the upgrade is likely to offer any improvements in how TAC deals with Route deployment/redeployment.

[Anonymous]

Exactly! The TAC is terrible for the task of deployment service artifacts. One small mistake and you have no choice other than working with the Karaf client.

One other big problem is the TAC deploys the repository entries with full path to the maven (Nexus) including the user credentials. This is a nightmare if one decide to move the Nexus server to a different server - it cause a lot of work!