Archived

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

A bug in Ice manual 2.0.0

section 32.4.2 Java Mapping

some codes below BlobjectAsync are VB codes, not java

Comments

  • Thanks for reporting this -- I made a mistake when I updated the live links to the text insets for the code examples when I added the C# and VB sections. I'll fix this for the next release, thanks!

    Cheers,

    Michi.
  • Another bug...

    Page 35, writing and compiling a server in Writing an Ice Application with C++, need to specify the Demo namespace, so class PrinterI : public Demo::Printer. Same goes for all the other code in there :) I.e. page 40, the client part: Demo::PrinterPrx printer = Demo::PrinterPrx::checkedCast(base)... Or add the using namespace Demo; after the std one, just like in the Filesystem example in chapters 7 and 9...
  • mes
    mes California
    These issues will be fixed in the next release.

    Thanks,
    - Mark
  • another tiny bug

    pg 202 - create(...) should probably take a named parameter 'type'
  • mes
    mes California
    Re: another tiny bug
    andhow wrote:
    pg 202 - create(...) should probably take a named parameter 'type'
    You're right, thanks.

    - Mark
  • In the bulleted list that spans pg. 767 and pg. 768, sec 30.3.4:
    Bullet one clearly says a callback object may not be used for multiple simultaneous invocations. Bullet three says "If the size of the thread pool is increased, the application may require synchronization if the same callback object is used for multiple invocations".

    Can callback objects be used for simultaneous invocations if properly handled?
  • mes
    mes California
    andhow wrote:
    Can callback objects be used for simultaneous invocations if properly handled?
    The generated AMI_xxx class is derived from an internal Ice class that maintains state about the pending invocation, therefore it is not possible to use the same object for multiple simultaneous invocations. The last bullet is worded improperly; we'll change it to convey the intended meaning that applications may have concurrency issues to deal with if they increase the client-side thread pool (e.g., when multiple callback objects delegate to a single shared object).

    Thanks,
    - Mark