Support for multiple hosts

[padcom]

From supp...@pivotal-solutions.co.uk on March 19, 2010 14:40:19

One of the long awaited (never fulfilled unfortunately) features of lambda probe was support for multiple hosts. This would make Probe a much more attractive tool for production sites

Original issue: http://code.google.com/p/psi-probe/issues/detail?id=98

[padcom]

From MALfunct...@gmail.com on March 19, 2010 07:36:50

Do you mean one instance of Probe managing multiple vhosts? Can you not deploy an instance of Probe to each vhost?

[padcom]

From supp...@pivotal-solutions.co.uk on March 19, 2010 08:06:51

That's correct - one probe, multiple vhosts.

Yes, I can deploy probe multiple time but that means you can't get an overview of what your Tomcat instance is doing - there is no way of determining how many vhosts are deployed without viewing the server.xml file.

Wouldn't it be great if the application page showed all applications from all hosts, perhaps indented under a host name?

I'd like to try and contribute to the codebase so I downloaded the code.
Unfortunately, there isn't any build information that I can make use of in my IntelliJ environment. I'm not familiar with maven so it's a bit of a trudge to get a project up and running.

[padcom]

From MALfunct...@gmail.com on March 19, 2010 11:15:48

In the past, someone brought up the idea of using a single instance of Probe to manage multiple servers. The difficulty lies in Tomcat's security mechanism; the Probe context must be "privileged" in its container to work properly.

I don't know for sure, but I believe this limitation applies to vhosts as well. Each vhost is a separate container, and unless there is a privileged context deployed to each container which contains Probe's features, we won't have the level of access we need. I could be wrong, though.

If I'm right, the only way I can think of to get around this is by splitting Probe apart. You'd deploy a special privileged "Probe service" context to each container which would expose Probe's data and features through secure web services or JMX.
Then you'd have a single "Probe portal" context that you deploy elsewhere which connects to each "service" context across multiple containers (whether on the same Tomcat instance or not) and aggregates the data and features.

Thoughts? This is on the scope of Probe 3.0, so you may be stuck for now. If you can think of another way though, please share!

Part of the motivation behind using Maven was so the project would not be tied to any specific IDE. I'm sorry for the learning curve this created for you. IntelliJ does support Maven, but I don't know enough about IntelliJ to help you set it up. Perhaps someone in the Discussion group can help. If you do get it working and would be willing to write up instructions for doing so, I'll gladly add them to the wiki.

Thanks!

[padcom]

From bealesna...@googlemail.com on March 26, 2010 03:40:18

Thanks for the feedback - yes I see the problem, it doesn't look easy to implement.

I've managed to create an intelliJ project but I get an NPE in the Tomcat55ContainerAdapter.findContexts when I start it. Pretty fundamental I know, so it's going to be a while until I can be of much help to this project.

Thanks, Steve

[padcom]

From MALfunct...@gmail.com on March 26, 2010 15:34:47

One day, I would like for it to work this way. This structure would be equally useful for managing nodes of a cluster.

Best of luck getting it to work in IntelliJ.

Summary: Support for multiple hosts
Status: Accepted
Blockedon: 40

[padcom]

From MALfunct...@gmail.com on November 05, 2010 09:15:00

Issue 162 has been merged into this issue.

[padcom]

From jh.web...@gmail.com on February 03, 2011 01:55:44

How about an architecture that uses a JMX agent library, deployed to the common class loader (likely circumventing any security issues)? This also has the advantage that Tomcat itself already exposes a wealth on information via its own MBeans, reducing the amount of work needed to implement remote monitoring.

[padcom]

From MALfunct...@gmail.com on February 03, 2011 07:43:00

Yes, that idea has some merit. Some features might not be implemented with JMX and may still require the separate "service" that I talked about in comment 3. Issue 13 deals with fully implementing jconsole within Probe. Implementing that would be the first step toward feature discovery on a remote server.

Blockedon: 13

[padcom]

From and...@corporateinteractive.com on March 12, 2011 16:08:46

Been hanging for this feature for about 2 years now. Would absolutely love it!

It sounds like the deployment manner might need to be something similar to the way we deploy the manager app across virtual hosts. By dropping manager.xml into each vhost we get access to the manager app across that vhost. It's a small job to drop the manager.xml file in each time we create a new vhost and we only end up with one instance of the physical manager app. So maybe probe could be deployed in a similar way will a small footprint within each vhost giving the global probe access to all.

I know a lot of people would be very grateful for this feature which was commonly requested in the original probe forum many years ago (including myself!) even to the extend someone offered financial backing!

Many thanks in advance.

[padcom]

From MALfunct...@gmail.com on March 14, 2011 15:06:22

@andrew, while it's true that there is only one physical copy of the manager app in most vhost configurations, I believe Tomcat is still running multiple instances of the manager in each vhost's ClassLoader. If so, there would be multiple isolated copies in memory, which would not allow them to interact with each other or a "global" manager.

I could be wrong, though; I don't have a lot of experience with Tomcat vhosts. Have you tried this before and gotten a manager on one vhost to manage apps on another vhost? If so, that might be worth looking into for PSI Probe.

[padcom]

From webdirec...@gmail.com on March 16, 2011 20:18:55

Hi - no I've not been able to do what you're quite saying in your post. I have one manager app physically deployed in the $TOMCAT_HOME/server/webapps folder and then the manager.xml within each vhost - when I connect to the manager app within the vhost you can only see the contexts within that vhost. I'm not sure if in memory it has re-deployed the manager app for each vhost or not. Certainly I haven't been able to manage apps in other vhosts. I guess I was thinking about it from the other direction but maybe as you say this is not an option.

[padcom]

From MALfunct...@gmail.com on March 17, 2011 08:55:47

I was afraid of that. It was a good idea, but the solution is going to be a lot more complex. However, it will also include support for hosts on separate machines, not just vhosts on the same machine.

[padcom]

From MALfunct...@gmail.com on March 17, 2011 08:56:07

This dependency is backwards.

Blockedon: -40

[padcom]

From MALfunct...@gmail.com on March 17, 2011 08:56:18

Blocking: 40

[padcom]

From chenw...@chenwang.org on June 29, 2011 04:45:26

This is a very nice feature but I'd make it lowest priority as there are some existing monitoring tools doing just that, Hyperic being one of them. They use an agent-master architecture, which is common in most monitoring solutions, and similar to what's been described above for this ticket. Personally I'd like to see other features implemented than making probe compete with enterprise monitoring tools by implementing features like such.

[padcom]

From MALfunct...@gmail.com on June 29, 2011 07:59:10

Yes, it's of lowest priority right now. This feature involves a complete overhaul of the entire project.

[padcom]

From michael.wyraz on July 02, 2012 04:15:45

Hi. I had a quick view to the code to see, how the code talks to a running tomcat instance. Most important code is (of course) within the tomcat adaptors. IMO it should be not too much work to add virtual host functionality:

• the adaptor should have access to the host's parent like it is done with "(Host) wrapper.getParent().getParent();", so it should be possible to access the other hosts.
• each context could simply prefixed by the hostname (e.g. localhost:/probe), so most lists and most selections of context should work without big changes
• in the deployment- view, either one have to type hostname:/contextname to deploy something. Or a selectbox allowing to select the host me be added.
• an alternative aproach would be to select the host on a central select box and would be passed to all functions of the adaptor. In this case nothing in the existing views needs to be changed.

Do you think this should be sufficient to add basic multi-host support?

Regards, Michael.

[padcom]

From michael.wyraz on July 02, 2012 08:12:14

I played a bit around with the code. I changed the adaptor (tomcat 6 and tomcat 7) so that all contexts of all hosts are returned. The list then contains all them. Since context.getName() is used, all are namend "/" or "/probe". The code for extracting the name of a context needs to be delegated to the adaptor so that there something like "host:/context" can be built. I tested some things manually (show context details, reload a context) by changing the "webapp" param of the requests to "host:/context". All worked as expected, even for contexts of different hosts. The changes i made to the adaptors where trivial:

e.g. in Tomcat70ContainerAdaptor:

• change the local variable from Host to Engine

• change the setWrapper function

  • added one .getParent() and changed the cast
  • for (Container container : engine.findChildren()) container.getPipeline().addValve(valve);
  • (same for remove)
  • added a splitContextName function, changed the formatContextName funciton

  protected String[] splitContextName(String name) { if (name==null) return null; String[] contextAndHost=name.split("\:",2); if (contextAndHost.length!=2 || contextAndHost[0].length()==0) throw new IllegalArgumentException("Invalid name. Expected host:context"); return contextAndHost; }

  public String formatContextName(String name) { if (name == null) { return null; } String[] hostAndContext=splitContextName(name); return hostAndContext[0]+":"+super.formatContextName(hostAndContext[1]); }

  protected Context findContextInternal(String name) { String[] contextAndHost=splitContextName(name); Host host=(Host) engine.findChild(contextAndHost[0]); if (host==null) return null; return (Context) host.findChild(contextAndHost[1]); }

  public List findContexts() { List result=new ArrayList(); for (Container host: engine.findChildren()) { for (Container context: host.findChildren()) { result.add(context); } } return result; }

• some other small changes to make it compile (mostly by using the "default host" if a host is required

In conclusion, the basic changes for multi-host-support are easy to do. There are some bigger changes to do on places where a host is expected. Most changes consists of delegating things to the adaptor or adding a host selection.

I hope this helps for the decision of making virtual host support part of the project :-)

[padcom]

From MALfunct...@gmail.com on July 03, 2012 08:13:48

@michael.wyraz, this is good stuff. Could you attach a patch of all the changes you made? That would make my job a lot easier. :)

Blockedon: -psi-probe:13 psi-probe:13

[padcom]

From michael.wyraz on July 12, 2012 00:40:29

Hi, I simply hacked the things in the code with no respect to re-usability of my changes. I attached the patch to tomcat70adaptor. Some changes should go to the abstract superclass (dealing with host:context).

Attachment: tomcat70adaptor.txt

[padcom]

From MALfunct...@gmail.com on September 06, 2012 11:03:48

Issue 314 has been merged into this issue.

[padcom]

From MALfunct...@gmail.com on June 04, 2013 07:22:49

Labels: Patch

[padcom]

From sirkorro on June 07, 2014 06:17:18

Hello. Any update on this? Is there a way to see application from all hosts? Regards.

[padcom]

From ulf.ditt...@googlemail.com on July 30, 2014 05:42:19

The patch in #21 works well. In addition to the change in the Adaptor class, I added a "host" attribute in the Application class which is set in ApplicationUtils via "app.setHost(context.getParent().getName())". Then you only need to replace "${app.name}" by "${app.host}:${app.name}" in all JSPs that use the "webapp" parameter to construct some URL (there are only 3 of them).