[jacorb-developer] jacorb-developer Digest, Vol 172, Issue 4

Fri Jan 19 10:14:50 CET 2018

Hello,

thanks for your response. My client is running JacORB 3.9 on openJDK build 1.8.0_151-b12 and the server is running omniORB 4.2.2. The client reads the CodeSetComponent correctly and sets the codeset accordingly.

However there is a bug in JacORB in the class org.jacorb.orb.giop.ClientConnection in the method setCodeSet in line 163. This line, connection.markTCSNegotiated(), does set the connection's flag for codeset negotiation to true, meaning done. Depending on this flag the method write_to in org.jacorb.orb.giop.RequestOutputStream does include the codeset context in the request. In my multi-threading test this flag gets set to true, but the codeset context will never be written on the connection's first use.

I created a patch for JacORB, that does not execute connection.markTCSNegotiated() in ClientConnection.setCodeSet in line 163. With this modification, my multi-threading test ist working fine. I testet it with 10, 20, 100 and 2000 threads sending requests and with a single threaded testcase, all working as expected. I will open an issue on github and provide the patch. If I'll be able to reproduce the issue with a simple jacorb example, I will also provide a testcase.

Regards,
Gotthard

-----Ursprüngliche Nachricht-----
Von: jacorb-developer-bounces~gotthard.witsch=ith-icoserve.com at lists.spline.inf.fu-berlin.de [mailto:jacorb-developer-bounces~gotthard.witsch=ith-icoserve.com at lists.spline.inf.fu-berlin.de] Im Auftrag von jacorb-developer-request at lists.spline.inf.fu-berlin.de
Gesendet: Donnerstag, 18. Jänner 2018 12:01
An: jacorb-developer at lists.spline.inf.fu-berlin.de
Betreff: jacorb-developer Digest, Vol 172, Issue 4

Send jacorb-developer mailing list submissions to
	jacorb-developer at lists.spline.inf.fu-berlin.de

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer

or, via email, send a message with subject or body 'help' to
	jacorb-developer-request at lists.spline.inf.fu-berlin.de

You can reach the person managing the list at
	jacorb-developer-owner at lists.spline.inf.fu-berlin.de

When replying, please edit your Subject line so it is more specific than "Re: Contents of jacorb-developer digest..."

Today's Topics:

   1. Re: Charset negotiation error in multiple threads with JacORB
      3.9 (Amadeu Barbosa)

----------------------------------------------------------------------

Message: 1
Date: Wed, 17 Jan 2018 10:46:11 -0200
From: Amadeu Barbosa <amadeu at tecgraf.puc-rio.br>
To: Discussions concerning CORBA development with JacORB
	<jacorb-developer at lists.spline.inf.fu-berlin.de>
Subject: Re: [jacorb-developer] Charset negotiation error in multiple
	threads with JacORB 3.9
Message-ID:
	<CAAFMKe1H6EFQhC0L4Ja6hqEKovbVwkg_rqFVy1LnH0w_KkWczQ at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Hi,

Please, clarify to me: both server and client are using JacORB? Are you using IOR references in order to connect to your corba server?

Few days ago I studied the codeset negotiation and I provided an implementation of server-side codeset negotiation to our own ORB for the Lua language ( http://webserver2.tecgraf.puc-rio.br/~maia/lua/oil/v06/index.html and my fork at https://git.tecgraf.puc-rio.br/engdist/oil). In my case, I have tested against JacORB and I didn't notice any problem with JacORB client-side codeset capabilities.

The client-side codeset negotiation in CORBA expect two possible behaviours:

A) The client must extract the IOR Profile tag 1 with CONV_FRAME.CodeSetComponent struct payload that contains the supported server-side codepages.
    But at this point you should be using IOR references (corbaloc references doesn't contain any IOR profile itself).

B) When it's not possible to identify the server-side codepages or even that codepages aren't supported at client-side as specified at (A) then the client-side must sends a service_context on the first request of a connection with the codepages supported (see: CONV_FRAME.CodeSetContext struct).
    So the server-side must convert strings itself.

In order words, the CORBA spec didn't expect a full handshake of codepages.
There is only these two oportunities to set up. In my production environment we didn't use NamingService or IOR references neither, we relay on corbaloc references. It became a problem to me on codepages conversion because my server-side will must convert all strings and I am not able to use client-side conversion.

If you're using a server-side other than JacORB you must check if it is able to identify the CONV_FRAME.CodeSetContext at very first request on a connection.

On Wed, Jan 17, 2018 at 8:27 AM, Gotthard Witsch < Gotthard.Witsch at ith-icoserve.com> wrote:

> Hello JacOrb Team,
>
> I am facing a problem with JacORB 3.9 when sending multiple requests 
> in parallel threads. Especially if there are more than 10 threads, 
> sending requests to the same CORBA endpoint.
> After analyzing the problem I figured out that JacORB does not 
> negotiate the correct codeset with the server. There is no request 
> send for codeset negotiation at all! Therefore our CORBA server 
> defaults to the ISO-8859 encoding, however JacORB does work with 
> UTF-8. As the result we get invalid content.
>
> My code does send three requests to the server:
> 1. Establish a connection to the NamingService 2. Receive the CORBA 
> object named TenantManger 3. Call a method on the CORBA object and 
> read the received data.
>
> Each thread does execute these three steps. I downloaded the source 
> code for JacORB 3.9 and added some logging statements.
> These statements definitely show that the encoding is negotiated for 
> the first two requests. However the third request does not negotiate 
> the encoding for the used client connection.
>
> Debugging the JacORB source code led me to the org.jacorb.orb.Delegate 
> and org.jacorb.orb.giop.ClientConnectionManager class, that are 
> responsible for retrieving the connection to the CORBA server.
> Unfortunately I could not find any obvious bugs in those classes. I 
> also had a look at the class org.jacorb.orb.giop.RequestOutputStream 
> and its write_to method, but could not find any bugs neither. I added 
> logging statements to the write_to method, but the block for 
> negotiating the codeset is not executed on the third request.
>
> Has anyone got a clue, what is causing the error? Or do I miss some 
> important configuration?
> If I just use 5 threads, for example, everything is fine. When I 
> increase the number of threads it starts causing the described error. 
> At about 10 threads it's failing all the time.
>
> My JacORB configuration is the following:
>
> props.put("ORBInitRef.NameService", "corbaloc:iiop:" + host + ":" + 
> port
> + "/NameService");
> props.put("org.omg.CORBA.ORBClass", "org.jacorb.orb.ORB"); 
> props.put("org.omg.CORBA.ORBSingletonClass",
> "org.jacorb.orb.ORBSingleton");
>
> // Charset properties
> props.put("jacorb.codeset", "on");
>
> // Turn on SSL support
> props.put("jacorb.security.support_ssl", "on");
>
> // Read certificates from key store (not from trust store) 
> props.put("jacorb.security.jsse.trustees_from_ks", "on");
>
> // Filename key store file
> props.put("jacorb.security.keystore", keyStorePath); // Password for 
> the key store props.put("jacorb.security.keystore_password", 
> keyStorePassword);
>
> props.put("jacorb.security.ssl.client.supported_options", "60"); 
> props.put("jacorb.security.ssl.client.required_options", "01");
>
> // Use JSSE
> props.put("jacorb.ssl.socket_factory", "org.jacorb.security.ssl.sun_ 
> jsse.SSLSocketFactory"); props.put("jacorb.ssl.server_socket_factory",
> "org.jacorb.security.ssl.sun_jsse.SSLServerSocketFactory");
>
> props.put("jacorb.maxManagedBufSize", "23");
>
> // connection timeout
> props.put("jacorb.retries", "30");
> props.put("jacorb.retry_interval", "2000"); // in ms
>
> // dump messages to log
> props.put("jacorb.debug.dump_outgoing_messages", "off"); 
> props.put("jacorb.debug.dump_incoming_messages", "off");
>
> Thanks in advance,
>
> Gotthard Witsch
>
> Research & Development syngo.share
> E-Mail:       gotthard.witsch at ith-icoserve.com<mailto:gotthard.witsch@
> ith-icoserve.com>
> ______________________________________
> ITH icoserve technology for healthcare GmbH a siemens company - HC SV 
> DS ITH Innrain 98, 6020 Innsbruck, ?sterreich - 
> www.ith-icoserve.com<http:// www.ith-icoserve.com/>
> Rechtsform: Gesellschaft mit beschr?nkter Haftung - Firmensitz: 6020 
> Innsbruck, Innrain 98
> Firmenbuchnummer: FN 174117f - Firmenbuchgericht: Innsbruck - DVR: 
> 0983039
>
> _______________________________________________
> jacorb-developer maillist  -  jacorb-developer at lists.spline.
> inf.fu-berlin.de
> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-develope
> r
>

--
Amadeu A. Barbosa Junior
http://www.tecgraf.puc-rio.br/~amadeu

------------------------------

_______________________________________________
jacorb-developer maillist  -  jacorb-developer at lists.spline.inf.fu-berlin.de
https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer

End of jacorb-developer Digest, Vol 172, Issue 4
************************************************