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

The open source
grid computing

 Home   About   Features   Download   Documentation   On Github   Forums 
November 19, 2019, 03:51:32 PM *
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  

Recent Posts

Pages: [1] 2 3 ... 10
Developers help / Re: Please, help-me: Unsupported major.minor version 52.0
« Last post by creigelde on October 30, 2019, 08:01:01 AM »
It is because of Java version mismatch. Unsupported major.minor version error happens when you compile your projects on higher version of java(e.g. jdk 1.8) and then run it on a lower version (e.g. jdk 1.7). Depending on your situation, you have two ways to resolve this error: compile your code for an earlier version of Java, or run your code on a newer Java version. Sometimes you may have more than one version of Java SDK installed in your machine. Make sure the application you are running is pointing to the right or highest version available . It is better you need to install both JRE/JDK with the same version.

Developers help / Integrating with external applications
« Last post by rocardho on September 06, 2019, 10:27:35 PM »
My use case is to use JPPF to perform computation on a large data set (data is to come from an external application (spring-boot)).

Work done so far
I have been able to setup the JPPF dev environment and implemented the necessary methods to perform the computation (using static data).

  • How do i integrate it my external application where data for the computation will be coming from?
  • Are there database (MySql, ..) and cache (redis, ..) adapters for performing crud operations? 


Forums / Re: Please post a message when you register
« Last post by rocardho on September 05, 2019, 12:42:25 PM »
Hi Laurent,

Tests show that the processing threads I have configured are now being respected:

Code: [Select]
INFO  [2019-08-27T16:05:58,273] [main] {} JPPF Version: 6.0, Build number: 2242, Build date: 2019-08-24 10:46 CEST
INFO  [2019-08-27T16:05:58,273] [main] {} starting client with PID=11524, UUID=542564fd-b87f-4f5c-9b5e-c29c82c076e4
INFO  [2019-08-27T16:05:58,273] [main] {} --------------------------------------------------------------------------------
INFO  [2019-08-27T16:05:58,301] [main] {} HikariCP libraries are not in the classpath, no datasource will be defined
INFO  [2019-08-27T16:05:58,316] [main] {} created client-side datasources: []
INFO  [2019-08-27T16:05:58,363] [main] {} load-balancer persistence is not configured
INFO  [2019-08-27T16:05:58,426] [main] {} running 16 processing threads
INFO  [2019-08-27T16:05:58,426] [main] {} Using default thread manager

Thank you very much!


Hi CM,

A fix for JPPF-602 was implemented and is now available in patch 01 for JPPF 6.0.

Please feel free to apply this patch at your convenience and let us know of the outcome.

Hello CM,

Yes, you can definitely post issues on Github. I've been procrastinating on this because the current issue tracker was more convenient to me, and migrating to the Github issue system incurs some initial work. But in the end, what matters is what isconvenient ot the community. So, please go ahead!

This is great, thanks Laurent!

BTW, should community start using git to log issues? Makes total sense to use it vs the forums.

I've downloaded the jppf helm charts and see a few issues. Not sure if I should be posting them here, vs opening issues in git.

Thank you again!

Hi CM,

Thank you very much for the detailed information, this was very helpful.
I finally managed to reproduce the behavior you described and found the cause of the issue. I registered a bug for this: JPPF-602 AbstractExecutionManager uses the wrong configuration to initialize

I will fix it in branches 6.0, 6.1 and 6.2 and prepare a patch for 6.0.0. This may take a couple of days, but it should be ready before next week. I will keep you apprised of the progress.

Hi Laurent,

I've debugged this directly inside JPPFClient, outside of my application entirely. The method you pointed out in ChannelWrapperLocal never gets called.

Here we initialize the JobManager:

Which initializes settings from the JPPFClient.config() in its constructor:

At this time the JobManager knows the jppf client is local execution mode, as it has read it from the config of the JPPFClient

Then from AbstractGenericClient.initPools(),  setLocalExecutionEnabled() is called which then calls jobManager.setLocalExecutionEnabled(localExecutionEnabled):

The following logic in jobManager.setLocalExecutionEnabled(localExecutionEnabled) evaluates to true, so updateLocalExecution() is never called, which creates ChannelWrapperLocal
Code: [Select]
    if (this.localEnabled == localExecutionEnabled) return;

My test for reference:
Code: [Select]
    public static void main(String[] args) throws Exception {

        TypedProperties properties = new TypedProperties();
        try (InputStream is = new BufferedInputStream(new FileInputStream("/path/to/"))) {

        properties.setBoolean("jppf.remote.execution.enabled", false);
        properties.setBoolean("jppf.local.execution.enabled", true);" {}", properties);
        JPPFClient jc = new JPPFClient(UUID.randomUUID().toString(), properties, new ConnectionPoolListenerAdapter());"JPPF Client local execution threads: {}", jc.getConfig().get(JPPFProperties.LOCAL_EXECUTION_THREADS));

Thank you advance for the assistance

Developers help / Re: Questions about local execution mode
« Last post by codemonkey on August 19, 2019, 10:53:15 PM »
Thanks Laurent for taking the time to write these detailed answers, very helpful.


Pages: [1] 2 3 ... 10
JPPF Powered by SMF 2.0 RC5 | SMF © 2006–2011, Simple Machines LLC Get JPPF at Fast, secure and Free Open Source software downloads