ice_ping MarshalException from refreshSession in python

Hello,
while playing around with python demos from the book I came across a strange behaviour. Every time I try to get a session going between client and server an exception is raised:

[ 2011-01-14 16:29:49.656448 Server.py: Protocol: received request 
  message type = 0 (request)
  compression status = 0 (not compressed; do not compress response, if any)
  message size = 74
  request id = 3
  identity = 2F0A6DC7-6942-4E49-99B8-7FAD33A673CC
  facet = 
  operation = ice_ping
  mode = 0 (normal)
  context =  ]
2011-01-14 16:29:49.656677 Server.py: warning: dispatch exception: Object.cpp:352: Ice::MarshalException:
protocol error: error during marshaling or unmarshaling:
unexpected operation mode. expected = ::Ice::Idempotent received = ::Ice::Normal
identity: 2F0A6DC7-6942-4E49-99B8-7FAD33A673CC
facet: 
operation: ice_ping

and this is what the client sent:

[ 2011-01-14 16:29:49.656030 Client.py: Protocol: sending asynchronous request
  message type = 0 (request)
  compression status = 0 (not compressed; do not compress response, if any)
  message size = 62
  request id = 3
  identity = DemoGlacier2/router
  facet = 
  operation = refreshSession
  mode = 0 (normal)
  context =  ]

However, this does not occur unless I provide my own SessionManager implementation, which looks like this:

class SessionManager(Glacier2.SessionManager):

	def create(self, userId, controlPrx, current):
		s = Session()
		return Glacier2.SessionPrx.uncheckedCast(current.adapter.addWithUUID(s))

class Session(Glacier2.Session):
	pass

(I've removed everything in session class just to be sure it wasn't causing this error)

Basically, it's Glacier2/callback example from the demos, with added things like session manager registering in Server.run():

class Server(Ice.Application)
	def run(self, args):
		[...]
		sessManager = SessionManager()
		adapter.add(sessManager, self.communicator().stringToIdentity('Callback.SessionManager'))

and session ,manager configuration in glacier's config:

Glacier2.SessionManager=Callback.SessionManager:tcp -h 127.0.0.1 -p 10000

Client.py remained unchanged, since it already has session creating code in it.

I've tried variuos ways to circumvent this error including cutting out the callback management code altogether, providing a slice for me own session class extending Glacier2:Session and variuos configuration options of endpoint on the client etc. Nothing seemsy to work.

What really interests me about this error is what would glacier's router send ice_ping as normal instead of idempotent operation?

I've read Chat example's c++ source a dozen times and I can't find anything wrong with my code... even (un)checkedCast() on the session in client doesn't helped.
But maybe I am doing something wrong?

versions etc:

Ice 3.4.1
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)
MacOS 10.6.5 
Python 2.6.6 (r266:84292, Jan  6 2011, 12:59:15) [GCC 4.2.1 (Apple Inc. build 5664)]

also tested on winxp 32 bit with 3.4.1 binaries downloaded from the site and python 2.6.4

I hope I've provided all the information needed and despite me being a "Personal" user, someone with helpful advice will ariive

Best Regards
Filip

I've tested ChatDemoGUI-Java to see how it uses refreshSession:

-- 1/14/11 18:55:32:533 Protocol: sending asynchronous request
   message type = 0 (request)
   compression status = 0 (not compressed; do not compress response, if any)
   message size = 58
   request id = 9
   identity = Glacier2/router
   facet = 
   operation = refreshSession
   mode = 0 (normal)
   context = 

so, "normal" mode seems to be ok here, but the router's name is different.
I've changed mine just to be 100% sure, but it doesn't help:

[ 2011-01-14 19:00:43.246609 Client.py: Protocol: sending asynchronous request
  message type = 0 (request)
  compression status = 0 (not compressed; do not compress response, if any)
  message size = 58
  request id = 4
  identity = Glacier2/router
  facet = 
  operation = refreshSession
  mode = 0 (normal)
  context =  ]

---- SERVER:
[ 2011-01-14 19:00:43.246958 Server.py: Protocol: received request 
  message type = 0 (request)
  compression status = 0 (not compressed; do not compress response, if any)
  message size = 74
  request id = 3
  identity = B0F0E606-A748-4D86-85B3-1B5AE4E091A9
  facet = 
  operation = ice_ping
  mode = 0 (normal)
  context =  ]
2011-01-14 19:00:43.257774 Server.py: warning: dispatch exception: Object.cpp:352: Ice::MarshalException:
protocol error: error during marshaling or unmarshaling:
unexpected operation mode. expected = ::Ice::Idempotent received = ::Ice::Normal
identity: B0F0E606-A748-4D86-85B3-1B5AE4E091A9
facet: 
operation: ice_ping

Since I can't get c++ examples to build I'll modify python callback example to to see how it uses ice_ping and how server reacts to it.

Hi Filip,

Welcome to the forum.

It looks like you've uncovered a bug. Actually, it's caused by a combination of issues.

If you're willing to rebuild the Ice for Python extension, I can describe how to temporarily work around the issue. We'll include a permanent fix in the next Ice release.

Regards,
Mark

Well, that's just great
I always seem to come across issues never heard of before...

I have already started to edit out all calls to refreshSession in Glacier2.py, putting ice_ping() (which works fine on it's own) in it's place. I would rather use the patch though, since I have no idea what other functions may be affected by those issues you've mentioned...

Thanks for warm welcome and speedy response

This exception only occurs when a C++ or C# client makes an asynchronous invocation of one of the built-in operations (ice_ping, etc.) on a Python servant. Strange enough for you?

In your scenario, the bug is triggered by calling refreshSession on the router because the implementation of refreshSession invokes ice_ping asynchronously on the Python session manager.

To work around it, open py/modules/IcePy/Operation.cpp and comment out line 3671:

// __checkMode(op->mode, current.mode);

Disabling this call to __checkMode is harmless.

Regards,
Mark

Strange enough
Thanks for the patch, I'll get to it tomorrow and test it.

How come no one every got this kind of error? Are python bindings so rarely used?

Regards,
Filip

Everything seems to be working now. However, Server.py still reports ice_ping as being sent as "normal" operation. I guess this can be ignored.

This problem existed before version 3.7.2？ it will be resolved before 3.7.2 ?

when push data to client from the server ， it will case this question 。 the server is c++ and the client is python， ice 3.6 and ice3.7 all will occur。

、

It's never a good idea to highjack an old discussion. The old problem - in 2011 - was related to operation modes and was fixed a long time ago.

I suggest you start a new discussion and describe your problem. From the screenshot above, it looks like a bug in the Python implementation of one of your Ice operations. Can you show the corresponding Slice definition and Python code?

Cheers,
Bernard