RE: RE: OB-Users Digest, Vol 38, Issue 2

Thanks so much for your time, but as u know I'm using the java implementa=
tion, I'll give it a try anyway, but where exactly should I look to modif=
ie my buffers size in the java implementation ?

Thanks again.=20

______________________________
SIGNORET Micka=EBl - C.T.O.
Vanilla Technology SA - OTCex
15-17 rue Marsollier 75002 PARIS
=C9 : +33 1 56 68 10 54
=CA : +33 1 56 68 10 59
> : [email protected]

-----Message d'origine-----
De=A0: [email protected] [mailto:[email protected]]=20
Envoy=E9=A0: lundi 19 juin 2006 17:33
=C0=A0: Mickael Signoret
Objet=A0: RE: [OB-Users] RE: OB-Users Digest, Vol 38, Issue 2

=20
Hi Mickael,
This is a bit of a long shot but it might be worth looking at. I don't ac=
tually think that it is your problem because it looks like your messages =
are very small.

In the C++ Orbacus 4.3.1 there is a performance problem with the windows =
socket parameters. The performance of the winsock is poor unless the buff=
er size is set to 64K ( (2**16)-1 )and send and recv send data in chunks =
of this size. A fix has been put into the constructor and send and receiv=
e methods for the server side, but this hasn't been applied on the client=
 side.

The module affected is oci_iiop_impl.cpp. There's probably not much point=
 in giving you the C++ methods affected since they may be different in th=
e java implementation. The principle is that every socket needs to have s=
end and receive buffers set to 64K and all send and recv calls should be =
use chunks of 64K.

The calls to set the socket parameters (as I'm sure you know) will look s=
omething like:


    int bufsz =3D 64 * 1024; // 64K

    if(setsockopt(fd_, SOL_SOCKET, SO_SNDBUF, (char*)&bufsz,
       sizeof(int)) =3D=3D -1)
    {
        int err =3D GetError();
        CloseSocket(fd_);
        _OB_setRef(0);
        SetError(err);
        throw COMM_FAILURE(LastError(), MinorSetsockopt, COMPLETED_NO);
    }

	// reset receive buffer size as well - added by simon
    if(setsockopt(fd_, SOL_SOCKET, SO_RCVBUF, (char*)&bufsz,
       sizeof(int)) =3D=3D -1)
    {
        int err =3D GetError();
        CloseSocket(fd_);
        _OB_setRef(0);
        SetError(err);
        throw COMM_FAILURE(LastError(), MinorSetsockopt, COMPLETED_NO);
    }



Make sure that these appear in the both constructors (acceptor and connec=
tor) for the class Transport_impl.
Also that sizeOfPacket can't be more that 64K in calls like

int result =3D ::send(fd_, (const char*)buf -> rest(), sizeOfPacket, 0);

And=20

int result =3D ::recv(fd_, (char*)buf -> rest(), sizeOfPacket, 0);

Older versions of Orbacus had an additional bug where sizeOfPacket didn't=
 get reset after each send / recv. This could cause a problem with large =
buffers.

This may be little use to you. However my experience with Orbacus C++ has=
 been that this module is responsible for most performance problems, so i=
t might be the place to start looking.

Regards,
Simon







-----Original Message-----
From: [email protected] [mailto:[email protected]] =
On Behalf Of Mickael Signoret
Sent: 19 June 2006 15:34
To: Mickael Signoret; David Weir
Cc: [email protected]
Subject: RE: [OB-Users] RE: OB-Users Digest, Vol 38, Issue 2

Hi Everybody,

I'm still looking forward to my problem and i can't find a solution so fa=
r. It's still hanging on one of my oneway function and blocking the whole=
 software, still no exception.

I do need some help.

______________________________
SIGNORET Micka=EBl - C.T.O.
Vanilla Technology SA - OTCex
15-17 rue Marsollier 75002 PARIS
=C9 : +33 1 56 68 10 54
=CA : +33 1 56 68 10 59
> : [email protected]
-----Message d'origine-----
De=A0: Mickael Signoret
Envoy=E9=A0: jeudi 15 juin 2006 15:33
=C0=A0: 'David Weir'
Cc=A0: [email protected]
Objet=A0: RE: [OB-Users] RE: OB-Users Digest, Vol 38, Issue 2

Hi again,

I succesffuly (thanks to you) installed the last version (4.3.1).

>The above configuration (upgraded to JOB-4.3.1) is for your client=20
>machine, correct?

Both client and server, actually it's on the same computer so far.

> Is the NameService also based on JOB-4.3.1?

Absolutely

> Are the 500 messages/second all calls to this oneway function?

Not only I have differecnt function very similar (below you'll find the i=
dl):

#pragma prefix "monitorplug.com"

module MonitorDynamic
{
    interface DynamicData
    {
        oneway void ask_update(in string id, in double price, in double s=
ize, in long long time, in double ref);
        oneway void bid_update(in string id, in double price, in double s=
ize, in long long time, in double ref);
        oneway void last_update(in string id, in double price, in double =
size, in long long time);
        oneway void ask_vol_update(in string id, in double ref, in double=
 price, in long long time, in double imp_vol, in double delta, in double =
gamma, in double vega, in double theta, in double rho);
        oneway void bid_vol_update(in string id, in double ref, in double=
 price, in long long time, in double imp_vol, in double delta, in double =
gamma, in double vega, in double theta, in double rho);
        oneway void mid_vol_update(in string id, in double ref, in double=
 price, in long long time, in double imp_vol, in double delta, in double =
gamma, in double vega, in double theta, in double rho);   =20
        oneway void last_vol_update(in string id, in double ref, in doubl=
e price, in long long time, in double imp_vol, in double delta, in double=
 gamma, in double vega, in double theta, in double rho);
        oneway void general_update(in string id, in double net_change, in=
 double percent_net_change, in long cumul_size, in long bl_trade_volume, =
in double vwap);
        oneway void general_OHLC(in string id, in double open, in double =
high, in double low, in double close);
        oneway void general_derivative_update(in string id, in double set=
tlement, in double open_interest);
    };
};

>So, just to be clear, your application is hanging as opposed to=20
>crashing, correct?

It's not crashing, it's just locked/hanging/very slowing


I'll try to send you a mini version of my program to reproduce the proble=
m.

Thanks again for your concern.

______________________________
SIGNORET Micka=EBl - C.T.O.
Vanilla Technology SA - OTCex
15-17 rue Marsollier 75002 PARIS
=C9 : +33 1 56 68 10 54
=CA : +33 1 56 68 10 59
> : [email protected]

-----Message d'origine-----
De=A0: David Weir [mailto:[email protected]] Envoy=E9=A0: jeudi 15 juin=
 2006 15:23 =C0=A0: Mickael Signoret Cc=A0: David Weir; ob-users@orbacus.=
com Objet=A0: Re: [OB-Users] RE: OB-Users Digest, Vol 38, Issue 2

Hello Mickael,

On Thu, Jun 15, 2006 at 03:06:58PM +0200, Mickael Signoret wrote:
> Hi David,
>=20
> I just tried with the new version JOB 4.3.1, and I have the very same=20
> problem. Do you have any clues and how can I go further to understand=20
> what is going on.
>=20
> Thanks for your concern.
> Regards.

Please make sure that the OB-Users mailing list is copied on all correspo=
ndence that originates there. This ensures that the community can benefit=
 from the discussion.

Since you were able to test this scenario with JOB-4.3.1, I can assume th=
at the issues you were having trying to build this version of Orbacus wer=
e resolved, correct?=20

As for the problem that you are seeing, would it be possible for you to b=
uild a small test program that could reproduce this problem and send it a=
long? Obviously we are dealing with an issue that canot be reproduced at =
will, but a test program that mimics the interactions of your client and =
server (the oneway call for example) would go a long way toward a resolut=
ion.

> > Hi,
> >=20
> > I'm using ORBACUS 4.2.2 with java and windows 2000 Server.

The above configuration (upgraded to JOB-4.3.1) is for your client machin=
e, correct?

> > I'm using the NameService on a win XP server and I send my request=20
> > the simplest way (no event service or that kind of stuff). My=20
> > application is sending like 500 messages /second.

Is the NameService also based on JOB-4.3.1?

> > This is an example of one method in my idl :=20
> >=20
> > oneway void last_update(in string id, in double price, in double=20
> > size, in long long time);

Are the 500 messages/second all calls to this oneway function?

> > Only simple datas, but I'm using the oneway parameters to have an=20
> > unblock policy.
> >=20
> > My application is working fine, but it crash about once a day.
> >=20
> > What happen is very simple : no java/corba exception, no memory=20
> > problem, no processor problem, but the ORB isn't able to absorb my=20
> > amount of request / second and block itself or is absorbing a very=20
> > low quantity of request. And finally I have to restart my software.

So, just to be clear, your application is hanging as opposed to crashing,=
 correct?

> > Again, I double checked, there is no memory problem, no java=20
> > exception, no TRANSIENT or that kind of Corba Exception. It just=20
> > doesn't absorb anymore.
> >=20
> > Anyone had that kind of problem ?
> > Thanks for your time.

Cheers,
Dave

--=20
David Weir                         =20
Team Orbacus - Your CORBA Source
E-Mail: [email protected]
WWW: http://www.orbacus.com
_______________________________________________
OB-Users Mailing List - [email protected] http://mail.ooc.nf.ca/mailma=
n/listinfo/ob-users
Visit our support FAQ before you send a message.
http://www.orbacus.com/faq/support.html



PLEASE READ: The information contained in this email is confidential and
intended for the named recipient(s) only. If you are not an intended
recipient of this email please notify the sender immediately and delete y=
our
copy from your system. You must not copy, distribute or take any further
action in reliance on it. Email is not a secure method of communication a=
nd
Nomura International plc ('NIplc') will not, to the extent permitted by l=
aw,
accept responsibility or liability for (a) the accuracy or completeness o=
f,
or (b) the presence of any virus, worm or similar malicious or disabling
code in, this message or any attachment(s) to it. If verification of this
email is sought then please request a hard copy. Unless otherwise stated
this email: (1) is not, and should not be treated or relied upon as,
investment research; (2) contains views or opinions that are solely those=
 of
the author and do not necessarily represent those of NIplc; (3) is intend=
ed
for informational purposes only and is not a recommendation, solicitation=
 or
offer to buy or sell securities or related financial instruments.  NIplc
does not provide investment services to private customers.  Authorised an=
d
regulated by the Financial Services Authority.  Registered in England
no. 1550505 VAT No. 447 2492 35.  Registered Office: 1 St Martin's-le-Gra=
nd,
London, EC1A 4NP.  A member of the Nomura group of companies.

_______________________________________________
OB-Users Mailing List - [email protected]
http://mail.ooc.nf.ca/mailman/listinfo/ob-users
Visit our support FAQ before you send a message.
http://www.orbacus.com/faq/support.html