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
This from my Java class, by the book:
I have used Trace.Slicing and several other logging properties:
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
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
0
Comments
-
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,
Bernard0 -
More Context, Other Thoughts?
Hi Bernard,
Thank you for the prompt reply. My response is inline.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,
Charles0 -
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,
Mark0 -
The plot thickens
Hello Mark,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,
Charles0 -
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)
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,
Mark0 -
One liners: now not only for politiciansI 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!
Charles0