JPPF, java, parallel computing, distributed computing, grid computing, parallel, distributed, cluster, grid, cloud, open source, android, .net
JPPF

The open source
grid computing
solution

 Home   About   Features   Download   Documentation   On Github   Forums 
November 21, 2019, 02:03:19 PM *
Welcome,
Please login or register.

Login with username, password and session length
Advanced search  
News: New users, please read this message. Thank you!
  Home Help Search Login Register  
Pages: [1]   Go Down

Author Topic: disabling jmxremote_optional  (Read 2272 times)

brian

  • JPPF Master
  • ***
  • Posts: 46
disabling jmxremote_optional
« on: May 28, 2016, 04:52:17 AM »

Hi,

The jmxremote_optional jar makes trouble for other libs on my classpath which use those same javax.management.remote APIs but expect different (JDK) impl. If I resolve this by removing the jmxremote_optional jar from my classpath, is there a way to then disable whichever features in JPPF use it?

Thanks.
Logged

lolo

  • Administrator
  • JPPF Council Member
  • *****
  • Posts: 2257
    • JPPF Web site
Re: disabling jmxremote_optional
« Reply #1 on: May 29, 2016, 09:46:03 AM »

Hello,

To remove the jppf_jmxremote_optional jar from your client application's classpath you don't need to do anything special. If you want to remove it from a driver or node, then you need to disable management in their respective configuration:

For a driver:
Code: [Select]
jppf.management.enabled = false
jppf.management.ssl.enabled = false

For a node:
Code: [Select]
jppf.management.enabled = false
However, I would be interested in understanding what kind of problem this is causing with your other libraries, so we can fix it in upcoming versions of JPPF. Would you mind providing details on this?
In particular I'm not clear on what you mean by "but expect different (JDK) impl", could you please elaborate?

Thanks,
-Laurent
Logged

brian

  • JPPF Master
  • ***
  • Posts: 46
Re: disabling jmxremote_optional
« Reply #2 on: May 30, 2016, 06:53:42 PM »

Ok great.

I think the issue is on my side not your problem so there'd be nothing for you to fix. But I'll let you know if I discover otherwise.

Btw in case you never considered it, one thing you could consider doing for this dep is shading (https://maven.apache.org/plugins/maven-shade-plugin/) it so jppf users didn't even realize it was there.
Logged

brian

  • JPPF Master
  • ***
  • Posts: 46
Re: disabling jmxremote_optional
« Reply #3 on: June 05, 2016, 07:53:47 PM »

Which features will stop working when management is disabled in node and driver? That is, I know visualvm would no longer be able to connect but aside from that are you also using JMX connections to implement other features?
Logged

lolo

  • Administrator
  • JPPF Council Member
  • *****
  • Posts: 2257
    • JPPF Web site
Re: disabling jmxremote_optional
« Reply #4 on: June 05, 2016, 08:29:33 PM »

Everything related to driver and node management and monitoring will be unavailable, including:
- management and monitoring APIs
- grid topology and job monitoring APIs
- the Swing-based administration console, which uses the above APIs, will not be able to manage/monitor the drivers and nodes

-Laurent
Logged

brian

  • JPPF Master
  • ***
  • Posts: 46
Re: disabling jmxremote_optional
« Reply #5 on: September 08, 2016, 01:11:27 AM »

Hi Laurent,

I wanted to revisit an old suggestion I made to shade your jmxremote_optional dependency. It would be great if you did this because I could then add jppf dependency to my main project classpath as a normal dependency vs. the "hack" I use now which is to create a special Ivy configuration and source folder just for jppf code&dependency. I do that separation because I don't want jppf's jmxremote_optional code being used in the many prod apps depending on my library. Today they all use the jmx_optional jar which came from Sun and while I'm sure the jppf version would also work for them, I don't want this jppf-specific dependency leaking outside jppf jmx connections. If you were to shade the packages, both jmxremote_optional impls could live together on the same classpath and your specialized jmxremote_optional jar would only get used by jppf connections.

Thanks for considering it,
Brian
Logged

brian

  • JPPF Master
  • ***
  • Posts: 46
Re: disabling jmxremote_optional
« Reply #6 on: September 23, 2016, 12:46:17 AM »

Hi Laurent,

This request actually extends to all of JPPF. As our dependency on jppf grows and multiple grids are deployed in production, upgrading them all at the same time is not feasible. Multiple teams working with projects that consume a similar set of internal libs (which have jppf dependencies) require independent upgrade cycles. It would be ideal to have multiple versions of jppf on the classpath like org.jppf52, org.jppf53, org.jppf61 etc. SPI files could also co-exist because package names would not conflict. Maven shade plugin or JarJar could accomplish this, or even doing it in source tree like commons-math3.

Let me know what you think. Thanks.
« Last Edit: September 23, 2016, 01:09:47 AM by brian »
Logged

brian

  • JPPF Master
  • ***
  • Posts: 46
Re: disabling jmxremote_optional
« Reply #7 on: November 05, 2016, 07:29:57 PM »

Hi,
FYI I am still interested in this feature. I have used JarJar to emulate this packaging for now, but a supported packaging would be ideal.
Thanks.
Logged

brian

  • JPPF Master
  • ***
  • Posts: 46
Re: disabling jmxremote_optional
« Reply #8 on: March 15, 2017, 03:13:44 PM »

Hi,
Any thoughts on this feature?
Thanks.
Logged
Pages: [1]   Go Up
 
JPPF Powered by SMF 2.0 RC5 | SMF © 2006–2011, Simple Machines LLC Get JPPF at SourceForge.net. Fast, secure and Free Open Source software downloads