Fwd: Erlang: orber problem

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Erlang: orber problem

Kjetil Rossavik-2
Thanks a lot for your response.

You were right about not having registered my types - didn't realise you
should, the tutorial example is not clear on that. My stupidity was worse
than that, I'm afraid, I had forgotten to compile my ic:gen() generates. I
am trying that out now, but compiling the generated code has been running
for 1 hour 25 now...

 > > I can communicate with the server, but in some instances I am getting
 > > the following exception:
 > > {'EXCEPTION',{'MARSHAL',[],107,'COMPLETED_MAYBE'}}
 > >
 > > 1. Is this a client (Erlang/Win2K) or server (Orbix/Solaris) marshalling
 > > failure?
 >
 > If you don't run Orber as lightweight the exception above is thrown when
 > Orber attempts to decode a message (e.g. Reply, Request).

Should I be running as lightweight?

D:\temp\erl>erl -orber lightweight [\"marketing-u10:1570\"] -orber domain
"ORBER_LIGHT"
Eshell V5.0.2  (abort with ^G)
1> orber:start_lightweight().
{error,{bad_environment_value,"\"[\"marketing-u10:1570\"]\""}}

=ERROR REPORT==== 20-Jul-2001::17:04:11 ===
application_controller: syntax error before: marketing:
"["marketing-u10:1570"]"

Thanks,
KJ.



Reply | Threaded
Open this post in threaded view
|

Fwd: Erlang: orber problem

Niclas Eklund-2
On Fri, 20 Jul 2001, Kjetil Rossavik wrote:
> You were right about not having registered my types - didn't realise you
> should, the tutorial example is not clear on that. My stupidity was worse
> than that, I'm afraid, I had forgotten to compile my ic:gen() generates. I
> am trying that out now, but compiling the generated code has been running
> for 1 hour 25 now...
The compile-time depends on your IDL-files. Make sure you use separate
files for separate IDL module-definitions.
I do recommend that you upgrade to the latest Orber-version since the
IIOP-overhead have been reduced significantly and a new version is on its
way which improve the performance even more!

> Should I be running as lightweight?
If you start Orber as lightweight it can only act as client-side. To be
able to reduce possible error-reasons I had to ask that question. Usually
the best option is to start Orber as non-lightweight (even a must in
most cases).

/Nick





Reply | Threaded
Open this post in threaded view
|

Fwd: Erlang: orber problem

Kjetil Rossavik-2
Thanks again for your replies. I am now doing some "viral marketing" of
Erlang here in Cisco. After your successful infiltration of Nortel (through
the acquisition of Bluetail), it is time to attack the real enemy (of
Ericsson). It certainly has had the desired effect on Nortel... :-)

>The compile-time depends on your IDL-files. Make sure you use separate
>files for separate IDL module-definitions.

As I am interfacing with an existing system, I cannot influence the IDL,
I'm afraid.

>I do recommend that you upgrade to the latest Orber-version since the
>IIOP-overhead have been reduced significantly and a new version is on its
>way which improve the performance even more!

As I am only prototyping at this stage, I can afford to wait for the
Win-build of OTP R8A, unless I run into any problems.


One issue I have come across is that the IDL I am using has hex numbers
(0x10, etc), and also hex numbers bitwise shifted (0x10 << 10). ic:gen()
does not seem to support this. Is this non-standard IDL, or is it an
unsupported feature in ic:gen? (So far I have circumvented the issue by
substituting in the base10 numbers).

KJ.



Reply | Threaded
Open this post in threaded view
|

Fwd: Erlang: orber problem

Hakan Millroth
> It certainly has had the desired effect on Nortel... :-)

Good luck in getting CSCO to join us down here in single-digit land :-)

-- Hakan


Reply | Threaded
Open this post in threaded view
|

Fwd: Erlang: orber problem

Niclas Eklund-2
In reply to this post by Kjetil Rossavik-2
On Wed, 25 Jul 2001, Kjetil Rossavik wrote:

> Thanks again for your replies. I am now doing some "viral marketing" of
> Erlang here in Cisco. After your successful infiltration of Nortel (through
> the acquisition of Bluetail), it is time to attack the real enemy (of
> Ericsson). It certainly has had the desired effect on Nortel... :-)
>
> >The compile-time depends on your IDL-files. Make sure you use separate
> >files for separate IDL module-definitions.
>
> As I am interfacing with an existing system, I cannot influence the IDL,
> I'm afraid.

Perhaps I should rephrase my first comment.
If you have

module foo {
...
};

module bar {
...
};

You can put both in one IDL-file (e.g. AllModules.idl). That is what you
should avoid. My suggestion is that you instead divide the module
definitions into two files (e.g. foo.idl and bar.idl). The result will be
the same and will not affect interoperability.
The drawback is that if you, for example, edit the 'foo'-module you have
to edit the AllModules.idl (used on the Orbix-side) and foo.idl. However,
this will only reduce stubs/skeleton compilation time which do rather
seldom. Hence, this change isn't very important. :-)

> >I do recommend that you upgrade to the latest Orber-version since the
> >IIOP-overhead have been reduced significantly and a new version is on its
> >way which improve the performance even more!
>
> As I am only prototyping at this stage, I can afford to wait for the
> Win-build of OTP R8A, unless I run into any problems.

Orber-3.2.7 will be a part of the next open-source release (R7B).
The result of the latest benchmarking tests (one open-source user's and my
own tests) shows very good results!
 

> One issue I have come across is that the IDL I am using has hex numbers
> (0x10, etc), and also hex numbers bitwise shifted (0x10 << 10). ic:gen()
> does not seem to support this. Is this non-standard IDL, or is it an
> unsupported feature in ic:gen? (So far I have circumvented the issue by
> substituting in the base10 numbers).

It is a part of the OMG standard. I've tested it and got an error-message.
For now I'm afraid you have to stick with your "workaround".

Best Regards

Nick