about icepack

lisa

I am faced with a headache and I need your help.

The problem appears when I am using icepack.
At first ,a simple introduction of the icepack system：
smserver is the icepack register.

qserver is the server which is registered on smserver.



1. At first,clients asked smserver for service for many times.During this period,maybe some of the clients failed to be served due to some operation reason.Then there comes the problem.

2. finally almost all the clients fail to get the serivice, And qserver seems very busy.

3. Then I killed the icepacknode on the qserver and then restart it. Immidiately, the following information appears on the background of icepacknode command:

" [ icepacknode: Server: changed server `Query' state to `Activating' ]

[ icepacknode: Activator: activating server `Query'

path = /home/oracle/netdb_m_0827/bin/QServer

pwd =

args = --Ice.Config=db/qserver172.16.4.51/servers/Query/config/config --Ice.Default.Locator =IcePack/Locator : default -p 12000 -h 172.16.4.51 --Ice.ServerId=Query ]

[ icepacknode: Activator: activated server `Query' (pid = 32094) ]

[ icepacknode: Server: changed server `Query' state to `Active' ]

[ icepacknode: Adapter: server adapter `Query.queryAdapter' activated ]

[ icepacknode: Activator: detected termination of server `Query' ]

[ icepacknode: Server: changed server `Query' state to `Deactivating' ]

[ icepacknode: Adapter: server adapter `Query.queryAdapter' deactivated ]

[ icepacknode: Server: changed server `Query' state to `Inactive' ]

“

It is strange that I haven’t start any client. More and more such information appear. In 7 minutes, there are almost 300 pieces of such information above.

4. Apparently, qserver is very busy with starting. Everytime after it starts up, it will exit due to absence of client data.

Under this condition, I try to start real clients to get service. All the clients exit without getting proper service.

5. when I use netstat command on the qserver, I get the following information:

“ Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 0 0 qserver:38978 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38979 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:39004 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:39005 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:39006 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:39000 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:39001 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:39002 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:39003 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38996 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38997 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38998 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38999 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38994 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38956 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38957 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38958 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38959 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38952 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38953 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38954 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38955 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38948 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38949 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38950 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38951 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38944 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38946 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38947 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38972 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38973 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38974 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38975 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38968 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38969 smserver:ncube-lm TIME_WAIT

tcp 0 0 qserver:38970 smserver:ncube-lm TIME_WAIT

…………..

tcp 0 0 qserver:37248 smserver:ncube-lm ESTABLISHED

tcp 0 0 qserver:37094 smserver:ncube-lm ESTABLISHED

tcp 0 0 qserver:36994 smserver:ncube-lm ESTABLISHED

tcp 0 0 qserver:37729 smserver:ncube-lm ESTABLISHED

……………

“

After a summary of the information which we get from netstat command, we find there are 80 pieces of information like“tcp 0 0 qserver:##### smserver:ncube-lm TIME_WAIT” and there are 72 pieces of information like “tcp 0 0 qserver:##### smserver:ncube-lm ESTABLISHED”

SUMMARY:

It is very strange that icepack register smserver is sending many virtual client to qserver.

I wonder where these clients comes and what inspires these clients. Is it because of those clients which failed to get the proper service and were remembered by the icepack register?





I am expecting for your answer. Thanks very much.

lisa

is there anyone who can help me?

bernard

Hi Lisa,

Please read this post regarding our support policy.

You should also provide additional details about your environment:
- Ice version
- OS
- IcePack deployment: is your Registry in a separate process?
- Have you tried to increase the IcePack tracing (see IcePackNode.Registry.Trace.* and especially IcePack.Node.Trace.*)?

Best regards,
Bernard

lisa

- Ice version
:Ice version is Ice 2.1.0
- OS
:OS is SUSE 9
- IcePack deployment: is your Registry in a separate process?
:yes ,it is in a sepertate process
- Have you tried to increase the IcePack tracing (see IcePackNode.Registry.Trace.* and especially IcePack.Node.Trace.*)?
:yes, I increase the IcePack tracing and there are lots pieces of "from" and "to" when i restart the icepacknode. Actually,i have not start any client at this time.

benoit

Hello Lisa,

We'll be glad to help if you provide a bit more information about you and your project as outlined in [thread=1697]this post[/thread]. Please also provide the traces of the IcePack registry with Ice.Trace.Protocol set to 1.

Thank you,
Benoit.