topic Re: Odd ESB Route deployment through the TAC in Talend Studio

Odd ESB Route deployment through the TAC

n999 — Sat, 16 Nov 2024 05:57:18 GMT

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.

Re: Odd ESB Route deployment through the TAC

Anonymous — Wed, 01 May 2019 11:08:17 GMT

When deploying and undeploying routes it is VERY important to do it in a strict order. If a route is being updated, you must stop the route and completely remove it, before adding your new version.

However, we can fix this for you. It is quite complicated, but with a bit of perseverance it will work 🙂

First, log in to your CLI client and type...

feature:stop

...followed by the name of your feature. I believe tab complete should work here (to help find the feature name), however that is not guaranteed.

Then you need to type.....

feature:uninstall

...followed by the feature name. Again, try tab complete here. I believe you need to explicitly specify the version, but that may not be the case (I can't test it here as I don't currently have a Karaf running). If your feature is called "MyRoute" and the version is 1.0.0-SNAPSHOT you might try this...

feature:uninstall MyRoute-feature/1.0.0-SNAPSHOT

Then you can completely remove any reference to it from your Karaf with this command...

feature:repo-remove MyRoute-feature

If you have trouble working out the names for any of the above you should be able to get the actual names for your features using ...

feature:list

If you have too many features to easily search through, you can use....

feature:list |grep

....followed by part of the feature name.

Good luck 🙂

Re: Odd ESB Route deployment through the TAC

n999 — Wed, 01 May 2019 16:51:04 GMT

Thanks for the

feature:...

prefix - didn't know that.

So does this mean we can't trust the TAC?

Cheers

Re: Odd ESB Route deployment through the TAC

Anonymous — Wed, 01 May 2019 17:20:48 GMT

You can trust TAC, but you must make sure that you follow a strict order when updating your routes. The steps I have given you are to correct alignment issues caused by not following a strict order. It is entirely reasonable to have your "MyRoute" route running several different versions concurrently in Karaf. Unfortunately, that is not what you want to be doing here. I have raised a request with R&D to find a way of preventing the issue you are suffering from, while allowing multiple versions of the same route to run. Hopefully this will materialise. Until then, just make sure that you either stop and delete your routes before upgrading or create a new route if you want to run an upgrade side by side 🙂

Re: Odd ESB Route deployment through the TAC

n999 — Wed, 01 May 2019 17:33:07 GMT

Hi Thanks for that.

However, I don't think you can trust people to do things in the right order.

So, I'm not sure you can trust the TAC as if you do things in the wrong order it incorrectly says all is well!

"It is entirely reasonable to have your "MyRoute" route running several different versions concurrently in Karaf."

That would be fine if that was reflected in the TAC and you could manage these versions there.

Anyway, sounds like an issue to add to the list :

cheers

Re: Odd ESB Route deployment through the TAC

Anonymous — Wed, 01 May 2019 22:49:30 GMT

As I said, I have raised this issue. The problem is caused by changing the version of an existing and running route in the TAC. This is a gap in the functionality, but it doesn't mean you cannot trust the TAC. The TAC will do what you ask it to do, unfortunately here it is also doing things that you should not ask it to do.

Re: Odd ESB Route deployment through the TAC

n999 — Wed, 22 May 2019 10:38:00 GMT

Sorry - a quick question.

What is the difference between the commands/process:

1) >list

2) >stop [ids]

3) >bundle:unistall [ids]

vs the feature commands you have listed below?

They seem to be different as I just ran the 3 commands above to get rid of a old version, but when I run feature:list

I still see the old version as "Started"

Maybe I need to ask the question what is the difference between bundles and features here?

Thanks..

Re: Odd ESB Route deployment through the TAC

Anonymous — Sun, 26 May 2019 10:07:35 GMT

Sorry about the delay in responding. I am currently on vacation, but thought I would check in to see how things are going 🙂

Features contain bundles. You can start/stop bundles installed as a feature without necessarily having to start/stop the feature. When TAC installs services and routes, it installs them as features. If you are acting on the feature in the Karaf client, it acts across all bundles of that feature. If you are acting on the bundle, then only the bundle you are referencing will be affected (unless a feature is rendered useless by removing or stopping the bundle).

If you have a dev runtime, play around with the tab completion that comes with the client. It will help you discover commands that may be useful. Also pay attention to the prefixes. "bundle:" and "feature:" are very important at ensuring you are applying the command correctly.

Re: Odd ESB Route deployment through the TAC

n999 — Mon, 03 Jun 2019 09:37:06 GMT

Thanks for that.

Is it fair to say that in this case the feature is the route deployed to the TAC and the bundles manifest themselves as the different versions of the deployed route?

Cheers

Nomit

Re: Odd ESB Route deployment through the TAC

Anonymous — Mon, 03 Jun 2019 09:39:57 GMT

If only it were that simple 🙂

If you have published different versions of a route, it will be published as different versions of a feature. I believe you see these by using ....

feature:list | grep myroutename

I say "I believe" as I don't have karaf on my machine at the moment, so the above is from memory 🙂

Re: Odd ESB Route deployment through the TAC

n999 — Mon, 03 Jun 2019 11:01:26 GMT

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....?

Re: Odd ESB Route deployment through the TAC

Anonymous — Mon, 03 Jun 2019 11:21:15 GMT

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.

Re: Odd ESB Route deployment through the TAC

sheftalenduser — Mon, 30 Sep 2019 09:35:43 GMT

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.

Re: Odd ESB Route deployment through the TAC

Anonymous — Mon, 30 Sep 2019 10:17:40 GMT

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!