Bug 3619

Summary:	Limitations in the service context handling
Product:	TAO	Reporter:	Johnny Willemsen <jwillemsen>
Component:	ORB	Assignee:	DOC Center Support List (internal) <tao-support>
Status:	NEW ---
Severity:	normal	CC:	sm
Priority:	P3
Version:	1.6.8
Hardware:	All
OS:	Windows NT
Bug Depends on:	3357
Bug Blocks:

Description Johnny Willemsen 2009-03-10 08:53:42 CDT

with ziop we are using the service context. we do see some limitations, when we send the reply back to the client, we can't check the policies the client has set, there is no way to access them.

one idea was to store them in a transport, but for one stub we could have set ziop, for a different one not, storing that data in a transport that is muxed is not an option. with each request the client should send the ziop service context which then must be available in the server as part of the TAO_ServerRequest. An optimization could be that the client doesn't send a service context when the data is compressed, then the server could add an implicit service context to the tao_serverrequest with the compressorid of the received data. 

Proposal is to pass service context of the TAO_ServerRequest through the sending of the message, so not just the stream, but also the service request.

Comment 1 Simon McQueen 2009-03-11 06:29:49 CDT

Isn't the standard way to put the required service context into a slot in request scope context PICurrent ?

Comment 2 Johnny Willemsen 2009-03-11 06:41:18 CDT

not sure if we still have PI at that place in the invocation path. this are orb internal service contexts

Comment 3 Johnny Willemsen 2009-03-11 09:58:24 CDT

I don't think PI will work here. The ZIOP policies are more like the codeset context, the ORB has to transfer them. The ORB core now has a hardcoded hook for codeset, but this should be a Service_Context_Generator, which can be registered into a new registry, the registered objects are then each time called from TAO_Transport::generate_request_header (and probably also from generate_reply_header). The generators can then add service contexts to the request for any policies they are handling.

Comment 4 Johnny Willemsen 2009-03-11 10:00:31 CDT

Also in TAO_RT_Protocols_Hooks::rt_service_context we have code to add service contexts, but then just for rtcorba

Comment 5 Johnny Willemsen 2009-03-13 06:54:47 CDT

mine

Comment 6 Simon McQueen 2009-03-13 08:23:34 CDT

RT CORBA service context handling is a hack. In fact, as the comments say, it's a "Mega Hack". It has particular requirements that apparently make it unsuitable for PI - as do CodeSets. That context must be sent on the first use of a transport only - that's not really possible with PI.

It sounds like ZIOP is simply a per request service context based on effective policies like the FT service contexts. Why is that not possible to do the proper portable way with PI rather than adding more hacks ?

Comment 7 Johnny Willemsen 2009-03-13 10:09:43 CDT

part can be done in a generic way, but when sending the reply from server to client, after marshaling all data we have to know the effective policy, you FT hint gave me some ideas,

Comment 8 Johnny Willemsen 2009-03-18 10:33:01 CDT

addd 3357

Comment 9 Johnny Willemsen 2011-11-02 13:38:33 CDT

pool