Raghu Jayan | 19 May 22:11 2014
Picon

Windows 64 bit build

Hello,

Based on a post in this mailing list I tried to obtain the Win64 port
using darcs:

darcs get --set-scripts-executable http://mico.org/mico-darcs-repository mico

However, I get an error when I run it. I get the following message,

darcs failed:  Not a repository: http://mico.org/mico-darcs-repository
(CouldNotConnectToServer)

HINT: Do you have the right URI for the repository?

      If so, check with the repository owner to see if the following files
      are readable:

        1. _darcs/format    - might not exist; that's OK
        2. _darcs/inventory - should exist if #1 is missing
        3. _darcs/hashed_inventory - should exist if #2 is missing

Has anyone been able to successfully compile x64 windows version? I
would appreciate any pointers in this regard.

Thanks in advance,

Raghu

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
(Continue reading)

Schneider, Wolfgang | 9 Dec 17:40 2013
Picon

Calling MICO::IIOPProxy::kill_conn can trigger memory race conditions

Hello MICO developers,

in my scenario a MICO service is called from a client process and delegating
those calls as several parallel invocations to further CORBA services. If
one of those delegation services is shut down, the service in the middle
could crash because of multiple deletes on the same IIOPProxyInvokeRec
object.
One of the delete candidates is the method IIOPProxy::del_invoke called in
IIOPProxy::abort_invoke itself. Another one is triggered as callback
function in CORBA::ORB::get_invoke_reply.

The following changes in MICO snapshot 2012 are my first try to fix the
problem (see the lines marked with // Wolfgang Schneider comments).  Up to
now I didn't test that very heavily. So I'm very interested if you see any
side effects of my fix which I didn't had in mind.

Thanks a lot for any help.

Iop.cc:

void
MICO::IIOPProxy::abort_invoke (CORBA::ORBMsgId id)
{
    // make invocation fail; notify orb ...
    if (MICO::Logger::IsLogged (MICO::Logger::IIOP)) {
	MICOMT::AutoDebugLock __lock;
	MICO::Logger::Stream (MICO::Logger::IIOP)
	    << "GIOP: invocation(" << id << ") aborted" << endl;
    }

(Continue reading)

Felipe Magno de Almeida | 4 Nov 12:33 2013
Picon

fwd_ior threading race and patch

Hello Karel,

We noticed a race with the fwd_ior member of Object when multiple
threads made calls concurrently. We've fixed it by moving the forward
object outside the reference and to the algorithms. The attached patch
has been working for over 1 year.

Any comments are appreciated,

Regards,
--

-- 
Felipe Magno de Almeida
Attachment (forward_ior.patch): application/octet-stream, 20 KiB
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mico-devel
Karel Gardas | 12 Oct 17:12 2013

Re: MICO cryptic problem


On 10/12/13 04:48 PM, andreis <at> eed.usv.ro wrote:
> Hi Karel
> Thank you kindly for the fast reply.
>
> CORBA::Object_var nsobj = orb->resolve_initial_references("NameService");
> // after this line, variable nsobj is not NULL.
>
> CosNaming::NamingContext_var nc=CosNaming::NamingContext::_narrow(nsobj);
> // after this line, nc is also not NULL but a CORBA::INV_POLICY exception
> //apears in the Visual Studio Output window. I must also mention that the
> //execution continues even after the exception is thrown, leading me to
> //think it is being caught somewhere in MICO code.

Do not be that confused about INV_POLICY being displayed in VS. IIRC it 
displays also caught policies. If you are curious what's happening in 
this case is that _narrow attempts to open IIOP connection to target 
object and as part of this code there is also a logic which tries to 
obtain ContextEstablishmentPolicy from the target object reference. By 
spec, if such policy is not associated with the target object 
Object::_get_policy should throw CORBA::INV_POLICY exception which is 
caught and code continues... See iop.cc, and seek for 
MICO::IIOPProxy::make_conn (CORBA::Object_ptr obj, CORBA::Boolean& 
timedout) if you are interested in seeing the code in question.

> As for the demo/services/naming example, i've tested it and it seems to
> work. What i don't understand is that i'm trying to replicate the example
> with the same exact code except the if(CORBA::is_nil(<variable>)) part
> because both nsobj and nc variables are NOT NULL  i.e. 0x13f6d388.

(Continue reading)

andreis | 12 Oct 12:14 2013
Picon

MICO cryptic problem

Hi, my name is Smolenic Andrei and I am a Phd student at the Stefan cel
Mare University of Suceava, Romania. I've reached a point in my research
where I need to compare some CORBA implementations. I've chosen TAO and
MICO. First I've created a TAO based client-server distributed application
and all went well. At the moment I've come to a halt with the MICO
approach. Let me try to explain the problem.

Setup: Windows 7 64 bit / Visual Studio 2010 Ultimate.
I downloaded the MICO sources and built them using the VS compiler (nmake
/f Makefile.win32). All went well so far. Next i've created a console app
to test the connectivity with the naming service.
I've applied the following config to my project:
- added D:\mico\win32-bin and D:\mico\include to C/C++ ->Additional
Include Directories
- added D:\mico\win32-bin\lib to Linker->Additional Library Directories
- added mico2313.lib and micocoss2313.lib to Linker->Input
- i've compiled the classic account idl file and added the resulting
account.h /.cc to the project
- i've implemented the required servant

And the relevant piece of code:

#include "account.h"
#include "coss\CosNaming.h"
...
int main()
{
  int argc = 4;
  char*        argv[4];
  argv[0] = "server";
(Continue reading)

Michael Powell | 15 Feb 13:11 2013
Picon

Cross platform MICO builds

Hello,

I am entering a project where we decided C++ was the way to go. C++/boost core engine, devices to be I2C exposed over a distributed object architecture (enter CORBA potentially), and so on, to enable distributed development potentially off-device, as well as on-device in production.

I am no stranger to distributed object technology stacks, like COM-family, web services including WCF, and even a little CORBA, but it has been several years for CORBA, so need a little practical guidance, specially for targeting cross-platforms.

Development would occur on a Windows-based system and target ArchLinux/ARM. What are our options? We can build the ORB to run on either platform? Can it be statically linked with the client/server? Better to dynamically link and let it run as a service?

However if performance suffers and the advantages of getting out of the middle tier protocol management business aren't there, like can we talk client/server over different asynchronous TCP/IP ports, then we may end up rolling our own infrastructure. Not my first choice, I'd rather focus on speed to market, but this is what we need to know.

Other than that, I'm unafraid of the age of CORBA, it's been around for A WHILE (can you believe the first specifications were out in 1991?), so I expect implementations to be nearly as solid as their age would allow.

Thank you...

Regards,

Michael

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mico-devel
Thomas Schmidt | 22 Jan 02:14 2013
Picon
Picon

Thousands of MICO::GIOPSimpleProf objects?

Hi,

I've just implemented some collections realizing some CosCollection interfaces. A collection is typed at run-time through a CosCollection::Operations object. It offers a collection some methods for element type checking and for ordering. So there's really a lot of communication between a Collection and its Operations object.

After a few seconds of intensive entering, removing or looking up elements in a collection things become slower and slower and slower, …

Some debugging shows that after a few seconds about 40.000 MICO::GIOPSimpleProf objects where created in the context of the Operations process. This process only runs exactly 2 Operation objects as default servants of a POA with NON-RETAIN policy.

After a code review of MICO 2.3.13 (the version in use) I found that profiles where entered - using IOR::add_profile() - into a container of type IOR::IORProfileVec but will only be erased - using IOR::del_profile() - on POA creation. I think computing will become slower due to the lookup loop in IOR::add_profile(). It seems that those MICO::GIOPSimpleProf objects were added in MICO::GIOPCodec::get_target().

Does anyone have a bug fix? Do we really need to add so much profile objects? When do they have to be destroyed? Wouldn't be a container with faster lookup methods a better type for IOR::IORProfileVec?

I'm developing in C++ on MacOSX 10.8.2 in Intel-32bit mode. Applications are running using GIOPVersion 1.2 and IIOPVersion 1.2. I've Threads enabled and switched on -ORBThreadPool and -ORBThreadPerConnection.

Please help, I don't really understand how to fix this bug.


Thanks
Thomas

--
Thomas Schmidt
Velgen 1
D-29582 Hanstedt
Tel: +49-4134-236339
Mobil: +49-151-23095598
Skype: ThCSchmidt
PGP: Key-ID: 0x810B6206

------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mico-devel
Thomas Schmidt | 7 Jan 03:14 2013
Picon
Picon

Bug in POA::activate_object() ?

Hi,

I'm currently implementing some CosCollection based classes. When testing the implementation I'll receive about 20% or more BAD_OPERATION exceptions on methods sending to my collections created for tests. When debugging I found that my collection factory will receive messages (like add_element()) directed to its formerly created collection objects.

After days of debugging and code review I didn't find the reason of this failure but found a workaround:
Instead of activating my collections and other objects like collection iterators or Operations objects using POA::activate_object() which implicitly generates an ObjectId, I better use POA::activate_object_with_id(). When generating my own process-wide unique ID I'll never get BAD_OPERATIONS any more.

I'm developing and testing on MacOSX 10.8 in 32-bit memory mode using Xcode with LLVM gcc 4.2 compiler-suite.

Ciao
Thomas

--
Thomas Schmidt
Velgen 1
D-29582 Hanstedt
Tel: +49-4134-236339
Mobil: +49-151-23095598
Skype: ThCSchmidt
PGP: Key-ID: 0x810B6206

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mico-devel
Alireza Azarnia | 9 Nov 00:46 2012
Picon

Reminder about your invitation from Alireza Azarnia

Hi, Alireza Azarnia sent you an invite on Zoosk.


View Invite

This message was sent by a Zoosk user who entered your email address. If you'd prefer not to receive emails when other people send you emails through Zoosk, click here

You have received this message at the email address: mico-devel <at> lists.sourceforge.net

Copyright © 2007-2012 Zoosk, 989 Market St, San Francisco, CA 94103 USA.

Privacy Policy

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mico-devel
Gregory, Peter | 30 Oct 11:56 2012

Marshall exception

Hi

Recently my company have upgraded the version of mico that we are using from 2.3.11 to 2.3.13.

 

We have done this because 2.3.11 failed to build on a new version of red hat that we have moved to. (Red Hat Enterprise Linux Server release 6.3 (Santiago))

 

Other than making some changes to get our software to build against the new compiler we haven’t changed our code.

 

However when we run we are getting a marshall exception in the client (thrown by the server). The client is a java client built against jacorb.  

 

The server is reporting the following error

 

Error: cannot decode args in StaticServerRequest.

 

In the idl the function call is defined as  unsigned long getLikeSize(in long keyNum, in any key);

 

Switching on the full debugging reports the following

 

MICO::GIOPConn::input_ready ()

  conn: 0x8079450

    ev: GIOPConnCallback::InputReady

 t_mod: 0

  pool:

  conn:

_activerefs: 1

   In Data  47 49 4f 50 01 00 00 00 00 00 02 90 00 00 00 00  GIOP...........

            00 00 00 02 01 00 00 00 00 00 00 16 2f 31 38 33  ............/183

            35 34 2f 31 33 35 31 30 39 32 34 30 30 2f 30 2f  54/1351092400/0/

            5f 30 00 00 00 00 00 0a 67 65 74 42 79 53 69 7a  _0......getBySiz

            65 00 00 00 00 00 00 00 00 00 00 01 00 00 00 0f  e...............

            00 00 02 0c 00 00 00 00 00 00 00 20 49 44 4c 3a  ........... IDL:

            77 63 73 2f 4d 68 65 4c 6f 63 6e 55 73 61 67 65  wcs/MheLocnUsage

            2f 52 65 63 6f 72 64 3a 31 2e 30 00 00 00 00 07  /Record:1.0.....

            52 65 63 6f 72 64 00 00 00 00 00 06 00 00 00 04  Record..........

            6b 65 79 00 00 00 00 12 00 00 00 00 00 00 00 04  key.............

            73 65 71 00 00 00 00 03 00 00 00 05 6c 6f 63 6e  seq.........locn

            00 00 00 00 00 00 00 0f 00 00 00 60 00 00 00 00  ...........`....

            00 00 00 15 49 44 4c 3a 77 63 73 2f 4c 6f 63 61  ....IDL:wcs/Loca

            74 69 6f 6e 3a 31 2e 30 00 00 00 00 00 00 00 09  tion:1.0........

            4c 6f 63 61 74 69 6f 6e 00 00 00 00 00 00 00 02  Location........

            00 00 00 05 7a 6f 6e 65 00 00 00 00 00 00 00 12  ....zone........

 

            00 00 00 00 00 00 00 09 69 64 65 6e 74 69 74 79  ........identity

            00 00 00 00 00 00 00 12 00 00 00 00 00 00 00 0e  ................

            6c 6f 63 61 74 69 6f 6e 5f 74 79 70 65 00 00 00  location_type...

            00 00 00 11 00 00 00 ae 00 00 00 00 00 00 00 27  .......®.......'

            49 44 4c 3a 77 63 73 2f 4d 68 65 4c 6f 63 6e 55  IDL:wcs/MheLocnU

            73 61 67 65 2f 4c 6f 63 6e 55 73 61 67 65 54 79  sage/LocnUsageTy

            70 65 3a 31 2e 30 00 00 00 00 00 0e 4c 6f 63 6e  pe:1.0......Locn

            55 73 61 67 65 54 79 70 65 00 00 00 00 00 00 04  UsageType.......

            00 00 00 16 4d 48 45 5f 4c 4f 43 4e 5f 55 53 41  ....MHE_LOCN_USA

            47 45 5f 4e 4f 52 4d 41 4c 00 00 00 00 00 00 13  GE_NORMAL.......

            4d 48 45 5f 4c 4f 43 4e 5f 55 53 41 47 45 5f 41  MHE_LOCN_USAGE_A

            4c 4c 00 00 00 00 00 14 4d 48 45 5f 4c 4f 43 4e  LL......MHE_LOCN

            5f 55 53 41 47 45 5f 4e 4f 4e 45 00 00 00 00 16  _USAGE_NONE.....

            4d 48 45 5f 4c 4f 43 4e 5f 55 53 41 47 45 5f 4c  MHE_LOCN_USAGE_L

            49 53 54 45 44 00 00 00 00 00 00 04 6d 68 65 00  ISTED.......mhe.

            00 00 00 0f 00 00 00 50 00 00 00 00 00 00 00 10  .......P........

 

            49 44 4c 3a 77 63 73 2f 4d 68 65 3a 31 2e 30 00  IDL:wcs/Mhe:1.0.

            00 00 00 04 4d 68 65 00 00 00 00 02 00 00 00 05  ....Mhe.........

            74 79 70 65 00 00 00 00 00 00 00 12 00 00 00 00  type............

            00 00 00 09 69 64 65 6e 74 69 74 79 00 00 00 00  ....identity....

            00 00 00 12 00 00 00 00 00 00 00 09 6d 68 65 5f  ............mhe_

            74 79 70 65 00 00 00 00 ff ff ff ff ff ff fe d4  type....ÿÿÿÿÿÿþÔ

            00 00 00 0c 41 69 73 6c 65 53 63 72 65 65 6e 00  ....AisleScreen.

            00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01  ................

            00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00  ................

            00 00 00 01 00 00 00 00 00 00 00 00              ............

: ActiveMsgQueue::put_msg: (0x8070e68) msg: 0x806d908

T *operator[](0): returns 0x807b558

void_array::remove (0)

PassiveOperation::put_msg():0x806d908

PassiveOperation::_run():0x806d908

void  InputHandler::process( msg_type& msg )

  conn: 0x8079450

    ev: 0

     b: 0x807a220

MICO::Server::input_callback (GIOPConn *conn, CORBA::Buffer *inp)

   conn: 0x8079450

    inp: 0x807a220

IIOP: incoming data from inet:128.0.0.145:39238

GIOP: incoming Request from inet:128.0.0.145:39238 with msgid 2

IIOPServer::add_invoke (id=6)

ORB::add_invoke (MsgId=6)

void MICOPOA::POACurrent_impl::set( poa=0x806cb00, POAObjectReference=0xb6602780, Servant=0x807936c )

Error: cannot decode args in StaticServerRequest

void MICOPOA::POACurrent_impl::unset()

ORB::del_invoke (MsgId=6)

GIOP: sending Reply to inet:128.0.0.145:39238 for msgid 2 status is 2

MICO::GIOPConn::output (CORBA::Buffer *b)

     b: 0xb66007f0

  Out Data  47 49 4f 50 01 00 00 01 00 00 00 38 00 00 00 00  GIOP.......8....

            00 00 00 02 00 00 00 02 00 00 00 1e 49 44 4c 3a  ............IDL:

            6f 6d 67 2e 6f 72 67 2f 43 4f 52 42 41 2f 4d 41  omg.org/CORBA/MA

            52 53 48 41 4c 3a 31 2e 30 00 00 00 00 00 00 00  RSHAL:1.0.......

            00 00 00 01                                      ....

IIOPServer::del_invoke (id=6)

GIOPConn::deref: 0x8079450, refcnt: 1, activerefs: 0

: ActiveMsgQueue::check_msg: (0x8070e68) msg:

void_array::__fast_insert (0x807b558):    return 0

: ActiveMsgQueue::check_msg: (0x8070e68) msg:

 

 

 

Any help would be most appreciated.

 

Peter

 

 

 

Peter Gregory
Senior Software Engineer

 

DD: +44 (0) 1536 480 652 | Mobile: +44 (0) 7932 518 921 | Fax: +44 (0) 1536 480 700 peter.gregory <at> logistex.com  | www.logistex.com

 

Logistex - a sure thing

Logistex Limited, 2700 Kettering Parkway, Kettering, Northamptonshire, NN15 6XR, United Kingdom  Main Phone. +44 (0) 1536 480 600

 

Registered Company Name: Logistex Limited | Registered Company Address: 2700 Kettering Parkway, Kettering, Northamptonshire, NN15 6XR, United Kingdom
Place of Registration: England
| Registration Number: 334189

This e-mail and any attachments are confidential and may contain legally privileged information.  If you are not the intended recipient please reply to the sender or telephone +44 (0) 1536 480 600 without using or disclosing the information contained herein.

Please be aware, all mail received by any <at> logistex.com address may be scanned for spam, virus, indecent images and spyware.

 

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mico-devel
Alireza Azarnia | 29 Oct 12:28 2012
Picon

Alireza Azarnia wants to share new pictures with you

Hi Mico-Devel, Alireza Azarnia sent you an invite on Zoosk.


View Invite

This message was sent by a Zoosk user who entered your email address. If you'd prefer not to receive emails when other people send you emails through Zoosk, click here

You have received this message at the email address: mico-devel <at> lists.sourceforge.net

Copyright © 2007-2012 Zoosk, 989 Market St, San Francisco, CA 94103 USA.

Privacy Policy

------------------------------------------------------------------------------
The Windows 8 Center - In partnership with Sourceforge
Your idea - your app - 30 days.
Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
_______________________________________________
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mico-devel

Gmane