1 2 3 Previous Next 39 Replies Latest reply: Jan 23, 2013 12:48 AM by vasileios Go to original post RSS
      • 30. Re: sync message:timeout when waiting for a lock <table>
        METHOD_OPT => 'for all columns size repeat',
        CASCADE => TRUE,
        DEGREE => 15

        Here is an article on the stats package


        But what I gave you should be enough for a start.

        How many devices are there in the field? If you can get to the performance tab within the mobile manager to see what is going on, it might shed some more light on the issue.
        • 31. Re: sync message:timeout when waiting for a lock <table>
          there are currently only 3 pdas working out, the plan is to reach about 40 but we started with 3 to see if everything goes ok. i will check the performance asap, but i dont think that with 3 pdas that is causing the issue to be honest.
          in the meanwhile is there anything other we can check ?
          • 32. Re: sync message:timeout when waiting for a lock <table>
            Can you retrieve your err.log on the server?
            • 33. Re: sync message:timeout when waiting for a lock <table>
              the err.log doesnt show anything about the errors produced on the client . on the specific hours that the olsynclog of the client shows the errors there is no entry in the err.log of the server.

              this err.log is it olites or oracle db file?

              moreover the attempts to sync that return the failure message with the lock are not shown in the performance history syncs of the mobile manager.

              it is my guess that the client is throwing the error before it contacts the server.

              let me say something more
              when the synch happens there are 4 bars, composing sending receiving and processing. the second bar (sending) is filled up BUT the tick in front of the bar is not activated then there is a long unusual waiting period and then the timeout when waiting... is thrown the tick becomes visible and the sync stops. i dont know if that is of any importance.

              any other ideas?:(
              thank you for all your efforts and time

              Edited by: vasileios on 18-Aug-2010 06:52
              • 34. Re: sync message:timeout when waiting for a lock <table>
                Got to $ORACLE_HOME/mobile/server/ and you should be able to find an err.log file there.

                Even though the timeout is happening on the client, something is failing initially that is causing the uploads not to take. Need to find out what that is.
                • 35. Re: sync message:timeout when waiting for a lock <table>
                  nope there is nothing relevant to the date and time in the err.log. there is something interesting though on the handheld.
                  i have set up the debug on the handheld and each time i try to sync it creates 2 debugx.txt files

                  in the first one i notice that at some point it says:
                  size=2 m_accumLen=1654
                  last m_accumLen=1656
                  last deflate=1
                  last write 470 total_out=7759
                  sendPart(1024) contentslen=8002
                  8:38:23.000 octrDmHttp::sendRaw===>dmHttpWrite... 8:38:24.000 dmHttpWrite(4)=4
                  8:38:24.000 octrDmHttp::sendRaw===>dmHttpWrite... 8:38:24.000 dmHttpWrite(1024)=1024
                  m_sentLenInReq=1024 m_totalSentLen=1024 SendPart ret nlen=1024
                  sendPart(4096) 8:38:24.000 octrDmHttp::sendRaw===>dmHttpWrite... 8:38:24.000 dmHttpWrite(4096)=4096
                  m_sentLenInReq=5120 m_totalSentLen=5120 SendPart ret nlen=4096
                  sendPart(2878) 8:38:24.000 octrDmHttp::sendRaw===>dmHttpWrite... 8:38:24.000 dmHttpWrite(2878)=2878
                  m_sentLenInReq=7998 m_totalSentLen=7998 SendPart ret nlen=2878
                  8:38:24.000 octrDmHttp::sendRaw===>dmHttpSendRequest... 8:41:14.000 octrDmHttp::sendRaw<===dmHttpSendRequest
                  remove TMP_FILE_NAME=0
                  8:41:14.000 pCCC->send()=0
                  8:41:14.000 dmHttpRead... Content-Length=0
                  TIMEOUT_MAX = -1, socket timeout = 60
                  8:41:14.000 dmHttpRead=0
                  dmHttpRead err=10054 WINCE: 10054
                  CCC::nread=0 receviedLen=0
                  8:41:14.000 receive done rec_success=0
                  mess=(10054 )
                  AddLog(0 "ERROR",0,"08/19/2010 08:41:14",":10054 ","TZIAKOURIS_NICOLAS" )
                  8:41:14.000 okConnect1()... 8:41:14.000 okConnect1(\SD Card\conscli.odb)=2633737
                  CONNECT OKAPI conscli=2633737 okEnv=1a0b624
                  Inflate Init
                  CreateFile error 2 \Orace\TZIAKOURIS_NICOLASolres.bin
                  8:41:14.000 CreateFile error 2 TZIAKOURIS_NICOLASolres.bin
                  8:41:14.000 ret2=0 DoProcess()=-2
                  in prepareErrorReport
                  BeginTranz(0 0)
                  EndTranz nDirty=2
                  ocDoSyncronize done 8:41:14.000 ocEnv=19fc3fc
                  ocSessionTerm env=27247612
                  ROLLBACK OKAPI conscli
                  8:52:47.000 okDis(env=1a0b624)
                  DISCONNECT OKAPI conscli okEnv=1a0b624
                  8:52:47.000 okFinal 0

                  then the second file created says
                  Start of debug.txt Jun 16 2010 SP=2b9ef6cc
                  8:41:16.000 *** InitCCC env=27237160
                  8:41:16.000 okConnect0()... 8:41:16.000 okConnect0(\SD Card\conscli.odb)=0
                  Connect nopass okEnv=1a00f74
                  Error at C:\ADE\omeprod_ol103030\olite\db\build\win\ocapi\..\..\..\src\ocapi\username.cpp line:1453 rc:-3264
                  Build date Jun 16 2010
                  okErr=(Timeout when waiting for a lock)
                  AddLog(-3264 "ERROR",POL-3264,"08/19/2010 08:41:17","Timeout when waiting for a lock:C$INFO","myuser")
                  ROLLBACK OKAPI conscli

                  so it appears that first it gets the 10054 error and then the timeout error.
                  from the olsynclog i see that:
                  "ERROR",0,"08/19/2010 08:56:26",":10054 ","TZIAKOURIS_NICOLAS"
                  "ERROR",POL-3264,"08/19/2010 08:56:28","Timeout when waiting for a lock:C$INFO","TZIAKOURIS_NICOLAS"

                  so the 10054 error occurs first and then the timeout when waiting for a lock.
                  ok so the question is what is this 10054? what does this code mean and what can i do about it please?

                  • 36. Re: sync message:timeout when waiting for a lock <table>
                    On the server, in the webogo.ora config file, do you have the following set in the [CONSOLIDATOR] section?


                    The RESUME_CLIENT_TIMEOUT parameter is the number of seconds that the client should use to timeout network operations. The default is 60 seconds.


                    The RESUME_TIMEOUT parameter indicates how long to keep client data while the client is not connected. The default is 0, which means that resume is disabled and after disconnection, the client data is discarded. A short timeout, such as 15 minutes, is suitable to resume any accidentally dropped connections. A longer timeout may be needed if users explicitly pause and resume synchronization to switch networks or use a dialup connection for another purpose.

                    Also, if you could get a hold of that ERR.log file, that would be great.
                    • 37. Re: sync message:timeout when waiting for a lock <table>
                      i appreciate all your help guys on this item.
                      it was very helpfull

                      at the end after a series of stressed and exhausting tests and after using packet sniffer and network analyzing software and together with the handheld manufacturer it appears that
                      this issue is caused because when through gprs the handheld cannot calculate the correct packet (mtu) size. the cellular company with the gprs handheld causes this issue.

                      after creating a new registry value in the handheld's registry that enables mtu automatic discovery the problem appears to be solved. the problem first trew a wince 10054 erro and then the timeout when waiting for a lock. the timeout when... was deceiving and caused the wrong imppresion. the 10054 was the network issue and when solved all went well.

                      in my opinion if anyof you have any kind of gprs synchronization issues with a customer, the very first thing you have to try is to put it on the cradle on a customer's pc and see if it synchronizes no matter what the message is. if it does then go low with a network analyzer through the gprs.

                      • 38. Re: sync message:timeout when waiting for a lock <table>
                        Can you please tell me what vendors device you were using when you resolved this issue.

                        • 39. Re: sync message:timeout when waiting for a lock <table>
                          hi it was
                          intermec cn4 but the solution was for cn3 model so i guess all intermec handhelds have this thingie
                          1 2 3 Previous Next