Enduro/X Core

Hello,

1. Enduro/X build process will use default data model of the operating system. For example if running on 64bit Linux, the gcc compiler by default would use LP64 data model, and thus Enduro will use this. If you would build on 32bit Linux (even working on 64bit cpu), it would be ILP32 - thus 32bit. What operating system you plan to use? We can prepare custom builds if needed.

2. Regarding, Enduro/X Java bindings, these allows to use the Java to write XATMI servers and clients to be managed by Enduro/X as an Application server in contrast of Weblogic. Though, there is possibility to use those bindings within the Weblogic, but in that case you need to boot the Weblogic in the Enduro/X environment. Thus for example

- If you configure Enduro/X instance
- Boot the instance (having all the environments set)
- you start the Weblogic app server in the same environment.
- Then from Weblogic code you would be able to use Enduro/X Java binding package. Previous steps are needed, due to fact that those bindings would instantiate JNI shared libs which would access the Enduro/X IPC resources as a "native client" from Enduro perspective.

If you need to deploy Weblogic and Tuxedo/Enduro core separately, then you can establish the tpbridge link between Weblogic machine and Enduro core, which would make core services to be accessible from Weblogic instance via asynchronous tcp link (basically transparent for programmers from XATMI services perspective).

====
The other way for Weblogic to access to Enduro services would be to use endurox-connect "restincl" process which would expose XATMI services as rest services. restincl supports different buffer encodings. And the simplest one is where FML is projected to very similar JSON. In restincl ini file it is possible to define web routes which maps to Enduro XATMI services. More details here: https://www.endurox.org/dokuwiki/doku.php?id=endurox-connect:v2.4.x:manuals:restincl.8

Of course with this approach you need to rewrite the Jolt code. Or you can write some emulation code of Jolt classes which would access exposed rest services.

PS,
Very soon we will have distributed transaction support over the rest services, so that several XATMI services can be orchestrated by WS calls, where the in the end WS caller decides to commit or abort.. Thus for described above restincl mechanism, some additional http header would manage transaction context for the call.

Thank you for the very full and prompt reply.

I built the distribution as 32 bit binaries and libraries after adding the correct -m32 flags to the CMakeLists.txt file. All our C/C++ binaries are 32 bit.

I need to think about the second part, we have a large number of JOLT based JEE server applications that make use of Oracle TUXEDO servers and services. I am thinking that exposing the services as REST calls would be to large a project to justify the effort. Also the performance would take a severe hit as we make millions of very fast XATMI calls today.

I built the distribution as 32 bit binaries and libraries after adding the correct -m32 flags to the CMakeLists.txt file. All our C/C++ binaries are 32 bit.

Sounds good. If you want to be sure that everything is all right, you may start the unit tests/integration tests. We will consider adding a cmake switch to configure this :)

Maybe the Enduro/X for Java is good solution? As from performance point of view it would be very good. We have benchmarked Java solution on average laptop, to have about 30K tpcalls/sec, and that is for single thread test.
The tpbridge in single thread test locally gives about 10K tpcalls/sec. In multi-threaded mode, the speed for both should multiply, and your java solution is multi-threaded.

The restincl, should also act fast (I do not have direct numbers at the moment), but probably about 1K tpcalls/sec it should work.

For the Java binding, maybe in cpmsrv you can configure that Weblogic is started by Enduro. Thus if Enduro is started, it would boot the weblogic, if it is stopped, it would perform sigterm to WL, and I see that that Wl would terminate this way normally. Maybe for cpmsrv some timeouts needs to be configured, as the WL takes long to start and stop.

If you need distributed transactions for XATMI services, then for Weblogic process in Enduro config you would need to configure dummy null switch/tmsrv. Then this would allow Java to participate in global transaction orchestration.

And if you put all this on separate server or unix user and would use this particular Enduro/X instance for Java only connectivity, then I guess it would be good solution.

Regarding the bridge, for example, if core Enduro/X is switched off, the bridge link would be lost, the Java instance would continue to work, only the service calls would generate TPENOENT exception, as services are gone. If core is started back, then Java instance would connect automatically to core, and service calls would start to work normally.

Also you can have several processing instances and several bridges which would provide HA.

So I'm slowly working through the options here.

I have setup two XATMI servers (different docker containers) with tpbridge communicating between them. I don't see any errors in the logs but can't make a tpcall from one server to the other where I have a custom service working. I get the TPNOENT error, service not available. The service does work on the other XATMI server.

What else do I need to do to make this work?

Also, we have many weblogic servers connecting to a less number of Oracle TUXEDO servers. If tpbridge only allows two servers to cluster this is not going to work.

Is tpgatesv an option here, I am not sure.

Thanks, Francis.

Hi,

Currently to one Enduro/X instance it is possible to connect 31 other Enduro/X instances (thought this number can be increased to 255 by matter of constant change).
Each of the connected instance must have different NDRX_NODEID in range 1..32.
Between any of the two nodes, on each side tpbridge process needs to be configured. You can start several tpbridges in instance, but each tpbridge must be responsible for connecting to different instance (i.e. between two instances only one connection / tpbridge pair is used). To establish connection one node shall be configured as socket listener (-tP - socket server) and other node given tpbridge shall be configured as client (-tA).
Each socket listener must have unique port number on given OS/Docker instance. So you need to decide which Enduro/X instance will be socket server and which will be clients. If for decided socket server Enduro/X instance several other instances will be connected, you will need to open number of ports to listen on (thus on docker you need to map these accessible). For socket tpbridge clients you will need to configure tpbridge server process copy to connect to particular socket server instance (IP address (-i) or hostname (-h)). Also in command line for tpbridge you need to specify other cluster node ID to which you are connecting. For example if client side has NDRX_NODEID=5 and server has NDRX_NODEID=11, then on client side tpbridge you need to specify in cli opts -n11. And on server side tpbridge process you need to specify -n5.

Note above client/server is regarding the socket modes. When connection is established, nodes are fully linked and all XATMI traffic works in full mode (in any side XATMI servers can live and clients can call any service).

If something does not work out, you need to check tpbridge logs. So if you get that processes start OK, but error is TPNOENT, then most likely connection was not established or there were some issue with these -n parameters.
When connection is established, nodes exchanges with the service tables and after that all XATMI operations shall work fine.

Here are some infos about the topology: https://www.endurox.org/dokuwiki/doku.php?id=endurox:v7.5.x:guides:ex_overview#_enduro_x_in_cluster

Thus overall you can connect several nodes, but each link must be defined as tpbridge process on both connected nodes. If you want to inter-connect 4x nodes each with each, then on each Enduro/X instance you need to define 3x tpbridge processes where the connection details and other node id -n is defined.

tcpgatesv normally is used for other types of connections, it just provides efficient/abstract way to program sockets with custom protocols. For example if POS or ATM devices needs to be connect, then tpcgatesv greatly helps with connection handling, but once connected via tpcalls it is possible to send and receive raw data from the devices.

So if you have several 10x Weblogics and you have say 3x processing nodes. And for simplicity I assume the Weblogic would not call each other via XATMI.

Then:
- You assign unique id for each node - 13 IDs.
- You inter connect each processing nodes, thus on each proc node there will 2x tpbridges for connecting other proc nodes.
- On each Weblogic instance you define 3x tpbridges for connecting to each proc nodes.
- On each processing node additionally you define 10x tpbridges for incoming weblogics.

And then it shall work - Each Weblogic will be able to use any resource from any of the 3x processing nodes.

---
If you need that weblogics can communicate via XATMI (as from endurox-java you can advertise service), then additionally 9x tpbridges must be defined in each of the weblogic instances. But I assume you do not need this, as from Jolt interfaces it was not possible to advertise any service.