Highlighted
Absent Member.
Absent Member.
3807 views

Cobolbean.dispose() crashes application server

[Migrated content. Thread originally posted on 26 March 2012]

Hello

When using the cobolbean.dispose() function the application server crashes. I have the following code:

@Stateful
@LocalBean
public class DataTypeTestBeanImpl extends CobolBean {
...
@PreDestroy
public void destroy() throws CobolException, Exception {
    super.dispose();    // CobolBean
}

@Remove
public void remove() {
}

were remove() is called from the client to signal the application server that the stateful bean is not needed anymore. The AS will call destroy() afterwards and should dispose() the CobolBean.

I didn't check yet when it happens, after the dispose itself or for the next or a parallel session. I also did't check when catching the exceptions in destroy() itself saves the AS.

I thought dispose should only cleanup the used working storage. What other things does dispose() do ? Any ideas why the AS is crashing ?

I can invest further checks earliest wednesday, hoping to get some answers beforehand.

Simon

0 Likes
7 Replies
Highlighted
Absent Member.
Absent Member.

RE: Cobolbean.dispose() crashes application server

Hello
I build some stress tests, running randomly simultaneous Cobolbeans and disposing them.
Within a JVM everything is fine. I used 100 parallel up to 100'000 sessions.
When calling the CobolBeans as stateful sessionbeans in Glassfish 3.1.1 or 3.1.2, see previous code, it runs fine, when only one parallel session is used. With multiple (even 2) sessions, after 10-30 dispose calls the JVM crashes. No Exceptions are caught. When dropping the dispose calls, the stress test runs fine, also with 100 parallel sessions. The test client runs in another JVM.

What is done in dispose() ?
Any ideas of what could be wrong ?

Cheers
Simon
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Cobolbean.dispose() crashes application server

We really have no idea what is causing this particular problem but I did want to warn you that the approach of running the Java/COBOL interface like this directly under an Application Server like Glassfish is an unsupported one.

The support that you are trying to use (calling native COBOL from Java) was developed for use with the Java JRE and was never intended to be used in a Java Application Server.

The solution that we recommend for this type of setup is to use the Interface Mapping Toolkit (IMTK) to map a Java Interface to our J2EE Resource Adapters in order to call COBOL running under Enterprise Server from Java programs which are running in an Application Server environment.

Please see documentation at:Mapping a Java Interface.

This solution is for Net Express/Server Express applications.

A better solution may be to look at the Visual COBOL JVM product and its direct support for generating Java byte code from COBOL applications. See documentation at: Creating JVM Projects

Thanks.


0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Cobolbean.dispose() crashes application server

Thanks for the infos, especially of generating Bytecode.

I came across the following link to use native Cobol within Tomcat, which is a similar setup as mine Running_JVM_COBOL_within_Apache_Tomcat

There should be a mfcobolrts.jar, which I can not find in Server Express Unix. Does it exist on UNIX or is it only available in Windows? Which classes does it contain ?

Simon
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Cobolbean.dispose() crashes application server

The article that you reference explains how to deploy a Visual COBOL JVM solution under Tomcat in Windows or Linux.
Visual COBOL JVM is the product that generates Java byte code to which I was referring earlier.

The article is specific to Visual COBOL JVM and does not cover the deployment of Server Express native applications.

The Micro Focus solution for Net Express/Server Express is to use the Java Connector Architecture to call COBOL programs running under Enterprise Server.

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Cobolbean.dispose() crashes application server

Hello Chris

I understood that it was in the context of JVM Cobol. But there are some references in the recent article (feb. 2012) which explain that at the moment JVM Cobol still uses native Cobol, here some excerpts:

- The JVM COBOL runtime currently accesses native COBOL by default.
- This process does not work for the main JVM COBOL runtime. JVM COBOL currently utilises the native COBOL runtime for access to facilities such as file handling (work is in progress to provide a pure JVM solution).
- The document goes into the steps needed to perform such a deployment and the environment configuration needed to ensure the runtime can find the native libraries required.

Would be great to know if mfcobolrts.jar exists for UNIX or what it contains.
Also of interest would be to know a timeframe for the pure JVM solution.

Simon

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Cobolbean.dispose() crashes application server

The pure JVM COBOL approach is now supported in the Visual COBOL 2.0 product which is now GA.

Thanks.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Cobolbean.dispose() crashes application server

I would like to clarify my last post.

Although the Visual COBOL 2.0 release does provide for the capability of generating pure JVM applications (native file handler replaced with managed), there will still be issues when trying to run under an Application Server environment.

We have done a lot of development work in this area for our next release which will be Visual COBOL 2.1, due out September/October timeframe.

Visual COBOL 2.1 will enable Tomcat deployment with COBOL JVM within a web container scenario (more specifically JSP or Servlets).

JCA support for native code is also available in Visual COBOL 2.1.

Current plans are to improve this support in future product versions to also include J2EE Servers, etc.

Is this something that you might be interested in?

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.