Print

[kardigen]

Hello all,
  We've started using JPPF JCA connector recently. Before that we could use JPPFClient.awaitConnectionPool(...) and hasAvailableConnection() API to check if JPPF driver is connected. Now we expected that <blocking-timeout-millis> JCA configuration settings should act as those, but it seems to block forever if no JPPF driver was connected. I cannot find anything like that in demo application.
  How to cope with disconnected JPPF driver properly?

Regards,
  Kardigen

[lolo]

Hi Kardigen,

Ok, this is embarrassing There is currently no exposed API in the JCA connector to deal with this.
However, one thing you could do is to set an expiration timeout on the job's client-side SLA. For instance:

Code: [Select]

JPPFJob job = newJPPFJob();
// set the job to expire in the client if it is not finished after 60 seconds
job.getClientSLA().setJobExpirationSchedule(new JPPFSchedule(60_000L));
If this is not sufficient for your needs, and you need to know the state of the client prior to sending jobs, then the only convenient way I see is to expose the JPPFClient handled by the JCA connector. This means it should be exposed in the JPPFConnection interface. I have two main concerns with that:

- if the JPPFClient is exposed, then all other methods in JPPFConnection become irrelevant. That's not a problem to me, it would dramatically simplify the JCA connector code and make JCA and standard client code that much closer, and it would also provide full access to the JPPF client APIs.

- I'm hesitant to change the JPPFConnection interface in a maintenance release, because I'm afraid it will break compatibility with prior maintenance releases. However, I believe it should be no issue if the getJPPFClient() method is instead only added to the implementation class JPPFConnectionImpl. You can then access it with an explicit cast like this:

Code: [Select]

JPPFConnection connection = ...;
JPPFClient client = ((JPPFConnectionImpl) connection).getJPPFClient();The getJPPFClient() method would of course be added to the interface in the upcoming 5.2 version.

If this approach is OK with you, here's the plan proposal:
- create an enhancement request for the change
- pre-5.2 versions: add getJPPFClient() to JPPFConnectionImpl only
- version 5.2: add getJPPFClient() to both JPPFConnection and JPPFConnectionImpl and deprecate all other methods
- version 6.0: keep getJPPFClient() and remove other (deprecated) methods

Also, given that my bandwidth is limited, I'd rather not have to deliver a new maintenance release for the 5.0 branch. Would you consider upgrading to 5.1? If not, then I can deliver an official patch for JPPF 5.0.5 that would include the enhancement, that's still much less work than a maintenance release. For the 5.1 branch, it will be part of the upcoming 5.1.4 maintenance release.

What do you think?

Thanks,
-Laurent

[kardigen]

Helo Laurent,
  Thanks for your quick answer and sorry for my delay, busy time.
 
  From my point of view, I need to know if the job is really executed. Now, if there is no JPPFDriver lunched, the JPPFConnectionFactory.getConnection() blocks forever.
  For me the best solution would be sth like this (in pseudo code):

Code: [Select]

    JPPFConnectionFactory factory = ...;

    if( !factory.isJppfDriverAvailable() ){
      warn("No JPPF driver available - executing locally")
    }
    try{
       connection = factory.getConnection();
    }catch(Exception ex){
       //handle timeout and other errors - also if driver disconnects in the meantime
    }

    // execute job on connection - no mater if local or external execution
 
Not sure if giving access to JPPFClient is good idea. You will need to synchronize access to it. I think the main concept behind JCA connector is that we have only one connection pool and the JPPF client is configured on Application Server level, not application level. Giving access to JPPFClient I think, you will break this contract.

We could possibly move to 5.1 branch as if it will still depends on JDK 1.7. So no problem of releasing it with 5.1 branch.

Cheers,
  Kardigen
 

[lolo]

Hi Kardigen,

if there is no JPPFDriver lunched, the JPPFConnectionFactory.getConnection() blocks forever

I'm confused, because this is not what I am observing on my side. I ran the demo app without any driver launched, and added traces before and after the getConnection() call, and I could see that a connection was effectively obtained from the connection factory. So there seems to be another issue we need to resolve.

For clarification, there is no relationship between the JCA connection pool size and the number of available driver connections in the JPPF client, nor is there any blocking code in the part of the JPPF resource adapter that allocates connection. Definitely the problem must be elsewhere and needs to be investigated. Is there any relevant information or message in the JBoss boot.log and server.log?

Giving access to JPPFClient I think, you will break this contract.

You're making a compelling argument, I agree 100%. So what I propose, is to add the following methods to JPPFConnectionFactory:

Code: [Select]

public boolean isJPPFDriverAvailable();
public void enableLocalExecution(boolean enabled);
I believe the enableLocalExecution() method is required, because if the JPPFClient connects to a driver later on, you might want to ensure the jobs are submitted remotely and prevent local execution, to avoid overloading the app server. I would also recommend that you configure the local executor with a very low priority in case both local and remote execution are enabled at any point in time, for instance:

Code: [Select]

jppf.local.execution.priority = -2147483648
# or with a scripted value
#jppf.local.execution.priority = $script{ java.lang.Integer.MIN_VALUE; }

You will need to synchronize access to it

The JPPFClient is fully thread-safe and can be accessed from many threads without a need for external synchronization. This is actually documented.

We could possibly move to 5.1 branch as if it will still depends on JDK 1.7

Not a problem, there is no plan to move to Java 8 before the 6.0 version, so that shouldn't be a blocker.

Finally, to track this discussion, I created an enhancement request: JPPF-455 Enhancements to the J2EE connector

Sincerely,
-Laurent

[kardigen]

Thank you Laurent!
  I'll check the demo application with driver turned off to see if this it's my environment issue or implementation issue and I'll let you know.

Looking forward to new release.

Best,
  Marcin

[lolo]

Hello,

I have delivered the new functionality as patch 02 for JPPF 5.0.5.
It is also included in the new JPPF 5.1.4 maintenance release, which you can get from the download page.
It is documented here. The demo application was also updated to reflect and use the new APIs.

Sincerely,
-Laurent