Archived

This forum has been archived. Please start a new discussion on GitHub.

Application Idle

Hello,

I have a Problem I've experienced with all Ice-Versions I worked with.

At this point, the Application often crashes and is Idle. There is no error but the application doesn't move to the next line of code while debugging.

this->Appfinder = ApplicationLayerFunctionsPrx::checkedCast(base);

But sometimes it works without any change in the code.

Has anyone else experienced this?

Thanks,
Susanne

Comments

  • I've just debugged a little further and it seems like the Application stops at the if(!d && b->ice_isA(T::ice_staticId())) statement and doesn't work on.


    checkedCastImpl(const ::Ice::ObjectPrx& b)
    {
    P d = 0;
    if(b.get())
    {
    typedef typename P::element_type T;

    d = dynamic_cast<T*>(b.get());
    if(!d && b->ice_isA(T::ice_staticId()))
    {
    d = new T;
    d->__copyFrom(b);
    }
    }
    return d;
    }

    I hope anyone can help me!?

    Thanks,
    Susanne
  • dwayne
    dwayne St. John's, Newfoundland
    Perhaps your call to checkedCast is throwing an exception? This would happen if your server is not running or the object is not the type you think it is. Try adding a try/catch block around the call and see if this is the case.
  • Thanks,

    but the try-catch-block is already there:

    try {

    this->ic = Ice::initialize(argc, (char**)args);
    Ice::ObjectPrx base = this->ic->stringToProxy("ApplicationLayer:tcp -h 127.0.0.1 -p 10000");
    this->Appfinder = ApplicationLayerFunctionsPrx::checkedCast(base);
    if (!this->Appfinder) {
    throw "Invalid proxy";
    }
    } catch (const Ice::Exception& ex) {
    cerr << ex << endl;
    status = 1;
    } catch (const char* msg) {
    cerr << msg << endl;
    status = 1;
    }

    There is no Exception. The Application is stuck in a wait-routine. But the Server is running. Sometimes it works and sometimes not, although noting has changed.

    The Problem is the wait-routine inside the ConnectRequestHandler::getConnection routine. This is IceE-code but i've experienced the same problem with the newest Ice-Version.

    ConnectRequestHandler::getConnection(bool waitInit)
    {
    if(waitInit)
    {
    //
    // Wait for the connection establishment to complete or fail.
    //
    Lock sync(*this);
    #if !defined(ICEE_HAS_AMI)
    if(_connect)
    {
    //
    // If there's no AMI support, we establish the connection synchronously
    // from this waiting user thread.
    //
    _connect = false;
    sync.release();
    try
    {
    setConnection(_reference->getConnection());
    }
    catch(const Ice::LocalException& ex)
    {
    setException(ex);
    }
    sync.acquire();
    }
    #endif
    while(!_initialized && !_exception.get())
    {
    wait();
    }
    }

    if(_exception.get())
    {
    _exception->ice_throw();
    return false; // Keep the compiler happy.
    }
    else
    {
    assert(!waitInit || _initialized);
    return _connection;
    }
    }

    thanks for your help,
    Susanne
  • dwayne
    dwayne St. John's, Newfoundland
    This faq may be helpful. You may have endpoints that are not working, thus causing delays. The reason it may work sometimes is that Ice does not always choose the same endpoint to use on each try.
  • But the Endpoints are already choosed explicitely :

    ApplicationLayer:tcp -h 127.0.0.1 -p 10000

    And server and client are running on one machine. There can be no Firewall blocking the traffic, right?
  • dwayne
    dwayne St. John's, Newfoundland
    No, if you are just using loopback on a single host there should be no delays. What OS/compiler are you using? Perhaps you could provide a small complete example, including Slice, so that we can try to reproduce your issue.

    Also it is not entirely clear to me whether your application crashes or just hangs. If it does crash, perhaps you can get a stack trace of where the crash occurs.
  • I'm using Windows XP and Visual Studio 2008 Express Edition. I'll try with Visual Studio 2005 Professional Edition. Maybe that could help?
  • dwayne
    dwayne St. John's, Newfoundland
    The express edition should work fine. One common cause of problems on Windows is a mix-up in release and debug libraries. See here.
  • Ok, thanks. I'll try that and let you know if it works.
  • I'm Using IceE, so there are the Iceed.lib and the iceecd.lib. I've linked them both but I think I need both, right?
  • matthew
    matthew NL, Canada
    I doubt this problem is caused by a mixture of release/debug libraries, and that typically results in a very quick crash :) It sounds more like your application is attempting to establish a connection with a server and that connection establishment is hanging for some reason. To help debug this you should enable network tracing. Add:

    Ice.Trace.Network=2

    to your configuration file of both the client and the server. You could also try setting "Ice.Trace.Network=3" for more information. You'll then get insight into what Ice is doing at the time of the hang. Since you are connecting with localhost the most likely reason for this hang is that all of the threads in the server side thread pool are exhausted.

    In addition, you should consider enabling a connection timeout so that the hang is not indefinite.
  • dwayne
    dwayne St. John's, Newfoundland
    susannesch wrote: »
    I'm Using IceE, so there are the Iceed.lib and the iceecd.lib. I've linked them both but I think I need both, right?

    No, you do not need to link with both of these libraries. You link with IceEC(d) if your application is just a client, whereas you need to link with IceE(d) for server features. However as you say you are able to reproduce this with regular Ice as well, this is not your problem.
  • if I only link with IceEC(d), I get compile errors becaus of external symbols the compiler cannot find. That means there has to be Server-Code somewhere. For code generation of the client part I used slice2cppe from IceE1.3.0.
  • benoit
    benoit Rennes, France
    Hi,

    If your code requires server functionality, you should link with the icee.lib library only then. You should not link with both, it's one or the other.

    As Matthew suggested, I would enable network tracing with --Ice.Trace.Network=2 to get more information.

    Cheers,
    Benoit.
  • Thanks for your help so far! I don't have configuration files for client and server. The client is part of DLL and the Server is an OSGI-Bundle. I didn't specify any configuration information.
  • dwayne
    dwayne St. John's, Newfoundland
    susannesch wrote: »
    if I only link with IceEC(d), I get compile errors becaus of external symbols the compiler cannot find. That means there has to be Server-Code somewhere. For code generation of the client part I used slice2cppe from IceE1.3.0.

    When you use the IceEC library with a client only application you also have to compile your application, including the generated file, with ICEE_PURE_CLIENT preprocessor macro defined.
  • benoit
    benoit Rennes, France
    Hi,

    I assume you have access to the source code of this client DLL so you could change the code where the communicator is initialized to add the tracing property setting and recompile the DLL. For example:
            Ice::InitializationData initData;
            initData.properties = Ice::createProperties();
            initData.properties->setProperty("Ice.Trace.Network", "2");
            communicator = Ice::initialize(initData);
    

    Cheers,
    Benoit.
  • Thanks, now I see what's going on. Although the connection is established correctly, the response sometimes takes very long:

    [ Network: trying to establish tcp connection to 127.0.0.1:1234 ]
    [ Network: tcp connection established
    local address = 127.0.0.1:3979
    remote address = 127.0.0.1:1234 ]

    Is there a possibility to avoid this? When I try to establish the connection in the dll main method, the connection can't even be established. It looks like a thread problem.
  • benoit
    benoit Rennes, France
    Hi,

    The connection on the loopback interface should be very quick. Can you reproduce the issue with the Ice demos? Do you have any firewalls enabled on your Windows machine? Did you try to strip down your Ice application to ensure the problem isn't coming from other code from this DLL/OSGI bundle?

    The best way to investigate this issue would be to provide us a small self-contained test case the we could use to reproduce the problem.

    Cheers,
    Benoit.
  • I've solved this problem. I had to make a slight change inside my OSGI-Bundle.