Ice.EndpointParseException when calling ic.stringToProxy on client side

kenpark

Hi.

I have a written a server using Ice For Android which is running on an Android emulator instance.

When I try to attache to that service on the client side (the client runs on my development PC) I receive an "Ice.EndpointParseException" with the following stacktrace:

<StackTrace>
Ice.EndpointParseException
str = "127.0.0.1 -p 6100"
at IceInternal.ReferenceFactory.create(ReferenceFactory.java:415)
at IceInternal.ProxyFactory.stringToProxy(ProxyFactory.java:17)
at Ice.CommunicatorI.stringToProxy(CommunicatorI.java:41)
at de.fbihome.seiffert.KontextUI.main(KontextUI.java:19)
</StackTrace>

The server on the emulator is connected to the endpoint 10.0.2.15:6100. I also did some redirect on the emulator to forward hostport 6100 to emulator's port 6100.
The client on the PC wants to connect using the following string to proxy: "2131034112Hi:127.0.0.1 -p 6100".

From the Ice-3.3.1 sources I can see that it raises the exception on that point:

<soucecode>
...
if(endpoints.size() == 0)
{
Ice.EndpointParseException e = new Ice.EndpointParseException();
e.str = unknownEndpoints.get(0);

...
</sourcecode>

Thus it seems the endpoint's size is zero.

I'm not really sure if this problem occurs on the client-side or on the server-side (on the emulator). The documentation only speaks about "malformed endpoints".

Any guesses how to proceede?

Kind regards,
Patrick


UPDATE

I debugged the error and it seems that the EndpointFactoryManager can not creat an endpoint using "127.0.0.1 -p 6100".
I saw that in IceInternal.ReferenceFactory Lines 402 - 411 which is that code snippet below:

<code>
...
String es = s.substring(beg, end);
EndpointI endp = _instance.endpointFactoryManager().create(es, false);
if(endp != null)
{
endpoints.add(endp);
}
else
{
unknownEndpoints.add(es);
}
...
</code>
Thus it adds the variable "es" to the "unknownEndpoints" and "endpoints" remains empty.

What can I do next?
Regards,
Patrick

mes

Hi,

The format for a stringified endpoint is as follows:

protocol options

where protocol is tcp, ssl, or udp, and options include:

-h host
-p port

and so on. For example, you should probably be using this:

"2131034112Hi:tcp -h 127.0.0.1 -p 6100"

You can find complete details in the manual.

Let us know if anything is unclear.

Regards,
Mark

kenpark

Hej Mark.

Of course! My fault!
I should have checked that on the manual first. I only copy/pasted something like "default" and changed that. Therefore I missed the tcp-declaration and thus of couse the strinToProxy was absolutely malformed.

I'm sorry but thank you for you support anyhow.
Regards,
Patrick

mwpowellhtx

Please forgive my ignorance, I am basically following the example with a couple of cooked up examples of my own, copied the line to createObjectAdapterWithEndpoints almost verbatim, but am finding the same Endpoints exception.

Writing an Ice Application with C#

What am I missing about endpoints?

Another question too, if we have different servants we can set them up on different ports to keep network traffic as non-blocking as possible?

Thank you...

mwpowellhtx

mwpowellhtx wrote: »

Please forgive my ignorance, I am basically following the example with a couple of cooked up examples of my own, copied the line to createObjectAdapterWithEndpoints almost verbatim, but am finding the same Endpoints exception.

Writing an Ice Application with C#

What am I missing about endpoints?

Another question too, if we have different servants we can set them up on different ports to keep network traffic as non-blocking as possible?

Thank you...

Here's the exception that was thrown:

Ice.EndpointParseException
str = "expected an endpoint option but found `-h' in endpoint `tcp -h localhost -p 12000'"
at IceInternal.TcpEndpointI..ctor(Instance instance, String str, Boolean oaEndpoint) in c:\IceBuilds\VC9\Release\cs\src\Ice\TcpEndpointI.cs:line 56
at IceInternal.TcpEndpointFactory.create(String str, Boolean oaEndpoint) in c:\IceBuilds\VC9\Release\cs\src\Ice\TcpEndpointI.cs:line 573
at IceInternal.EndpointFactoryManager.create(String str, Boolean oaEndpoint) in c:\IceBuilds\VC9\Release\cs\src\Ice\EndpointFactoryManager.cs:line 85
at Ice.ObjectAdapterI.parseEndpoints(String endpts, Boolean oaEndpoints) in c:\IceBuilds\VC9\Release\cs\src\Ice\ObjectAdapterI.cs:line 1402
at Ice.ObjectAdapterI..ctor(Instance instance, Communicator communicator, ObjectAdapterFactory objectAdapterFactory, String name, RouterPrx router, Boolean noConfig) in c:\IceBuilds\VC9\Release\cs\src\Ice\ObjectAdapterI.cs:line 1219 at IceInternal.ObjectAdapterFactory.createObjectAdapter(String name, RouterPrx router) in c:\IceBuilds\VC9\Release\cs\src\Ice\ObjectAdapterFactory.cs:line 158 at Ice.CommunicatorI.createObjectAdapterWithEndpoints(String name, String endpoints) in c:\IceBuilds\VC9\Release\cs\src\Ice\CommunicatorI.cs:line 80 at DChem.Demos.Basics.Server.Program.Main(String[] args) in c:\Source\Detectachem\SEEKERe\dchem-seekere\seekere-suite\DChem.Demos.Basics.Server\Program.cs:line 30

xdm

Hi Michael,

Seems to me that is an issue with copy/paste the endpoint from the web page that include some non printable characters. Try to type the endpoint manually.

xdm

By the way the documentation you linked is quite old, if you are using Ice 3.4 you should refer to Writing an Ice Application with C-Sharp - Ice 3.4 - ZeroC instead

Cheers,
Jose

mwpowellhtx

I'm comparing notes with the Hello demo, and I navigated my way through the server part. It now comes up. Apparently some tricks in how adapters are being named and identified to endpoints and such. Anyway the config files make life a little easier. Now having issues with the twoway proxy channel coming back null. Not exactly sure why that is. Some of the operations are idempotent, but maybe that's inappropriate. Will have a look at the example however, thank you.

mwpowellhtx

Actually, the style of coding the example is quite far from production quality. We'd probably go with the Ice.Application-based approach (worst case) or at least a decorator pattern that hid the try/catch/destroy nastiness from view quite as much. I broke it out and the proxy does say null, but the property to proxy is not, that parses okay. Not sure what the disconnect is.

mwpowellhtx

It seems that in my public static TestServantPrx checkedCast(Ice.ObjectPrx b) code, b is not a TestServantPrx, and it probably should be. The weak cast to TestServantPrx r = b as TestServantPrx yields r == null, and calls behind b time out in debug mode. b.ice_isA is returning false for the servant type. This is in C#, and I did notice that the path to the class is C++-style namespaces, ::Path::To::My::Servant, instead of what I might expect, Path.To.My.Servant, or even global::Path.To.My.Servant, or I wonder if that's what liberties Ice took with the path?

xdm

The format for the Type id is the expected see: Type IDs - Ice 3.4 - ZeroC

The checkeCast operation returns null reference when the passed proxy is not of the expected type. C-Sharp Mapping for Interfaces - Ice 3.4 - ZeroC

I'm not sure what you are trying to do , will be easy if you show us the code.

Regards,
Jose

mwpowellhtx

I'm not sure this is attaching. I've got a 7-Zip file prepared with a minimal test scenario. I'm not sure what's missing per se. The client/server App code is loosely based on the Demos. I enabled tracing and I am getting client/server messages through ice_isA, it's returning message type 2 if that means anything. I have wireshark, but with more time I could filter to the actual traffic.

mwpowellhtx

Attachment not found.

Okay attached. Wouldn't take 7-Zip but would take Zip.

The only difference I can see of anything is that I am not using the SSL services at all. Possibly something about running through VS2012 as well.

benoit

The TestServantPrxHelper.checkedCast() call returns null for the reason mentioned by José: the Ice object pointed by the proxy test:tcp -p 10000:udp -p 10001 does not implement the TestServant type.

The servant that incarnates this object implements the ITestServant Slice interface which isn't the same thing.

Two solutions depending on what are you goals with the ITestServant and TestServant types:

• Change the checked cast to cast a proxy on the interface type, use ITestServantPrxHelper.checkedCast
• Change the servant implementation to extend DChem.Test.TestServant (i.e.: public class TestServantI : DChem.Test.TestServant {}).

Cheers,
Benoit.

mwpowellhtx

Yessir, that was it. Instead of TestServerPrxHelper, I run that through ITestServerPrxHelper and voila, I have a proxy! Thank you!