Archived

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

IceStorm.NoSuchTopic cannot be cast to Ice.UserException

Hello,

My understanding, as per this FAQ is that Ice runtime exceptions in java derive from Ice.LocalException. Thus I am perplexed by an exception I have received in my IceStorm based event listener:

Ice 3.4.1 x86_64
gcc 4.4.4-10 x86_64 also 4.1.2-48 x86_64
JDK 1.6.0.21 x86_64 also 1.6.0.18 x86_64
FC13 also RHEL 5.5
Ice.SyscallException
error = 0
    at IceInternal.BasicStream$DynamicUserExceptionFactory.createAndThrow(BasicStream.java:2171)
    at IceInternal.BasicStream.throwException(BasicStream.java:1568)
    at IceInternal.Outgoing.throwUserException(Outgoing.java:443)
    at IceStorm._TopicManagerDelM.retrieve(_TopicManagerDelM.java:141)
    at IceStorm.TopicManagerPrxHelper.retrieve(TopicManagerPrxHelper.java:452)
    at IceStorm.TopicManagerPrxHelper.retrieve(TopicManagerPrxHelper.java:414)
    at [...]Listener.setupListener
    at [...]Listener.<init>
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0
    at sun.reflect.NativeConstructorAccessorImpl.newInstance
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
    at java.lang.reflect.Constructor.newInstance
    at java.lang.Class.newInstance0
    at java.lang.Class.newInstance
[B]Caused by: java.lang.ClassCastException: IceStorm.NoSuchTopic cannot be cast to Ice.UserException[/B]
    at IceInternal.BasicStream$DynamicUserExceptionFactory.createAndThrow(BasicStream.java:2163)
    ... 22 more

This from my Java class, by the book:
[...]
private void setupListener() {
[...]
   // Obtain TopicManager proxy succeeds, using property
   // TopicManager.Proxy=IceStorm/TopicManager
    manager =
        IceStorm.TopicManagerPrxHelper
            .checkedCast(communicator
                .propertyToProxy("TopicManager.Proxy"));
[...]
    try {
        topic = manager.retrieve(<topicName>);
    } catch (IceStorm.NoSuchTopic ne) {
        try {
            topic = manager.create(<topicName>);
        } catch (IceStorm.TopicExists ex) {
            localLogger("Temporary failure retrieving Topic Proxy.");
            return;
        }
    } catch (Ice.NotRegisteredException re) {
        localLogger("Could not locate Topic Proxy in the registry.", re);
        close();
        return;
    } catch (Ice.LocalException ie) {
        localLogger("Unknown error in Listener setup.", ie);
        close();
        return;
    }
[...]
}

I have used Trace.Slicing and several other logging properties:
Network: trying to establish tcp connection to x.x.x.2:55424
Network: tcp connection established
    local address = x.x.x.2:55554 remote address = x.x.x.2:55424
Protocol: received validate connection
    message type = 3 (validate connection)
    compression status = 0 (not compressed; do not compress response, if any)
    message size = 14
Protocol: sending request
    message type = 0 (request)
    compression status = 0 (not compressed; do not compress response, if any)
    message size = 82 request id = 1 identity = IceStorm/TopicManager facet =
    operation = ice_isA mode = 1 (nonmutating) context =
Protocol: received reply  message type = 2 (reply)
    compression status = 0 (not compressed; do not compress response, if any)
    message size = 26 request id = 1 reply status = 0 (ok)
Protocol: sending request  message type = 0 (request)
    compression status = 0 (not compressed; do not compress response, if any)
    message size = 64 request id = 2 identity = IceStorm/TopicManager facet =
    operation = retrieve mode = 1 (nonmutating) context =
Protocol: received reply  message type = 2 (reply)
    compression status = 0 (not compressed; do not compress response, if any)
    message size = 60 request id = 2 reply status = 1 (user exception)
Protocol: sending request  message type = 0 (request)
    compression status = 0 (not compressed; do not compress response, if any)
    message size = 64 request id = 3 identity = IceStorm/TopicManager facet =
    operation = retrieve mode = 1 (nonmutating) context =
[B]Protocol: received reply  message type = 2 (reply)
    compression status = 0 (not compressed; do not compress response, if any)
    message size = 60 request id = 3 reply status = 1 (user exception)[/B]
Protocol: sending close connection  message type = 4 (close connection)
    compression status = 0 (not compressed; do not compress response, if any)
    message size = 14
Network: closing tcp connection

Of particular interest is the log message highlighted above.

Any guidance from this forum, especially suggestions for introspection, are greatly appreciated.
BTW, anyone else having trouble with the search function in the online Ice manual (latest)?

Best Regards,
Charles

Comments

  • bernard
    bernard Jupiter, FL
    Hi Charles,

    Welcome to our forums!

    The search for the online manual should be fixed now.

    From your stack trace, here is what apparently happened:
    - your subscriber sent a retrieve request to IceStorm
    - IceStorm returned an IceStorm.NoSuchTopic user exception
    - the Ice runtime (in your subscriber) created an instance of IceStorm.NoSuchTopic, and for some reason could not cast it to a UserException
    -the Ice runtime converted this java.lang.ClassCastException into an Ice.SyscallException

    Ice.SyscallException is an Ice.LocalException, so it should be caught by your catch (Ice.LocalException ie).

    The first question is naturally why did the Ice runtime get this ClassCastException in the first place. IceStorm.NoSuchTopic is definitely an Ice.UserException.

    Does your subscriber use a special configuration - e.g. sets Ice.Default.Package or Ice.Package.IceStorm?

    You may also find this FAQ entry useful: http://www.zeroc.com/faq/unmarshalOutOfBoundsException.html

    Best regards,
    Bernard
  • More Context, Other Thoughts?

    Hi Bernard,

    Thank you for the prompt reply. My response is inline.
    bernard wrote: »
    The first question is naturally why did the Ice runtime get this ClassCastException in the first place. IceStorm.NoSuchTopic is definitely an Ice.UserException.

    Does your subscriber use a special configuration - e.g. sets Ice.Default.Package or Ice.Package.IceStorm?

    I do not use Ice.Default.Package or Ice.Package.IceStorm either. Here is an abstract of my slice definition, I am not using any slice metadata directive:
    #include <IceStorm/IceStorm.ice>
    #include <MyOwnModule.ice>
    module MyOwnModule
    {
    [...]
        module MyOwnService
        {
            [...]
    
            interface SomeService
            {
                [...]
            };
    
            exception SomeException extends MyOwnException {};
       };
    };
    

    Here is an excerpt from my build target (ant) :
        <target name="generate" depends="init">
            <mkdir dir="${generated.dir}"/>
            <slice2java outputdir="${generated.dir}">
            <meta value="java"/>
                <fileset dir="${slice.dir}" includes="${slice.files}"/>
                    <includepath>
                        <pathelement path="${slice.dir}"/>
                        <pathelement path="${ice.slice.dir}"/>
                    </includepath>
            </slice2java>
        </target>
    

    Again, using Ice.Trace.Slicing=1 has produced no additional log output. I have turned on Ice.UseSyslog and this is as yet the case. For your reference, here is my client configuration file:
    Ice.Default.Locator=IceGrid/Locator:tcp -t 5000 -p <port>
    TopicManager.Proxy=IceStorm/TopicManager
    ClientAdapter.Endpoints=default
    IceStorm.Trace.TopicManager=2
    IceStorm.Trace.Topic=2
    IceStorm.Trace.Subscriber=2
    Ice.PrintAdapterReady=1
    Ice.Warn.Connections=1
    Ice.Trace.Network=2
    Ice.Trace.Protocol=2
    Ice.Trace.Slicing=1
    Ice.UseSyslog=1
    

    Your support is well received,
    Charles
  • mes
    mes California
    Hi Charles,

    Is it possible that you're using multiple class loaders?

    If you can provide a small test case that reproduces the problem we'd be happy to take a look at it.

    Regards,
    Mark
  • The plot thickens

    Hello Mark,
    mes wrote: »
    Is it possible that you're using multiple class loaders?

    That is distinctly possible. Would you elaborate? If you are referring to the InitializationData class loader, I do not use this feature.

    In the mean time, I will look into manufacturing a test case. Thank you for your continued advice.

    Best,
    Charles
  • mes
    mes California
    I suspect that UserException and NoSuchTopic are being loaded by different class loaders, in which case the is-a relationship between the two classes is no longer true. Keep in mind that Ice is dynamically loading the NoSuchTopic class. As explained in the manual, Ice uses the following semantics:
    If an application does not supply a class loader (or if the application-supplied class loader fails to locate a class), the Ice run time attempts to load the class as follows:
    • using the system class loader
    • using the current thread’s class loader
    • using the default class loader (that is, by calling Class.forName)
    Consequently, if Ice happens to find the class using a class loader that is different than the one that loaded UserException, I believe you would get a ClassCastException.

    I think this situation is more likely to occur in application servers like WebLogic, where multiple class loaders are often used to enhance security. In situations like this, you'll probably need to specify the proper class loader in InitializationData.

    Regards,
    Mark
  • One liners: now not only for politicians
    mes wrote: »
    I suspect that UserException and NoSuchTopic are being loaded by different class loaders,

    Preliminary testing suggests that you are correct. Explicitly defining the classloader does appear to resolve this issue for me. I will be sure to post here should I discover complications in testing.

    Cheers!
    Charles