Re: jacorb-developer Digest, Vol 172, Issue 4

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.ClientCon=
nection in the method setCodeSet in line 163. This line, connection.markTCS=
Negotiated(), does set the connection's flag for codeset negotiation to tru=
e, meaning done. Depending on this flag the method write_to in org.jacorb.o=
rb.giop.RequestOutputStream does include the codeset context in the request=
. In my multi-threading test this flag gets set to true, but the codeset co=
ntext will never be written on the connection's first use.

I created a patch for JacORB, that does not execute connection.markTCSNegot=
iated() 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 wor=
king 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 al=
so provide a testcase.

Regards,
Gotthard




-----Urspr=FCngliche Nachricht-----
Von: jacorb-developer-bounces~gotthard.witsch=3Dith-icoserve.com@lists.spli=
ne.inf.fu-berlin.de [mailto:jacorb-developer-bounces~gotthard.witsch=3Dith-=
[email protected]] Im Auftrag von jacorb-developer=
[email protected]
Gesendet: Donnerstag, 18. J=E4nner 2018 12:01
An: [email protected]
Betreff: jacorb-developer Digest, Vol 172, Issue 4

Send jacorb-developer mailing list submissions to
	[email protected]

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
	[email protected]

You can reach the person managing the list at
	[email protected]

When replying, please edit your Subject line so it is more specific than "R=
e: 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 <[email protected]>
To: Discussions concerning CORBA development with JacORB
	<[email protected]>
Subject: Re: [jacorb-developer] Charset negotiation error in multiple
	threads with JacORB 3.9
Message-ID:
	<CAAFMKe1H6EFQhC0L4Ja6hqEKovbVwkg_rqFVy1LnH0w_KkWczQ@mail.gmail.com>
Content-Type: text/plain; charset=3D"UTF-8"

Hi,

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

Few days ago I studied the codeset negotiation and I provided an implementa=
tion 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 te=
sted 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.CodeSetCom=
ponent struct payload that contains the supported server-side codepages.
    But at this point you should be using IOR references (corbaloc referenc=
es doesn't contain any IOR profile itself).

B) When it's not possible to identify the server-side codepages or even tha=
t codepages aren't supported at client-side as specified at (A) then the cl=
ient-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 environmen=
t we didn't use NamingService or IOR references neither, we relay on corbal=
oc 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 abl=
e to identify the CONV_FRAME.CodeSetContext at very first request on a conn=
ection.


On Wed, Jan 17, 2018 at 8:27 AM, Gotthard Witsch < Gotthard.Witsch@ith-icos=
erve.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:       [email protected]<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  -  [email protected].
> 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  -  [email protected]
https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer


End of jacorb-developer Digest, Vol 172, Issue 4
************************************************
_______________________________________________
jacorb-developer maillist  -  [email protected]
https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer