alireza.azarnia | 23 Nov 02:34 2014
Picon

alireza.azarnia <at> gmail.com has indicated you're a friend. Accept?

Click here to discover alireza.azarnia <at> gmail.com's favorite websites!
alireza.azarnia <at> gmail.com wants to follow you
I would like to add you as a friend
-alireza.azarnia <at> gmail.com
Accept Decline
Following alireza.azarnia <at> gmail.com helps you discover great websites they recommend :)
Click here to unsubscribe from such emails from alireza.azarnia <at> gmail.com or all friends


P.O. BOX 70928, Sunnyvale, CA 94086
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mico-devel
imcompo | 19 Nov 16:06 2014
Picon

idl compilation fail with VS2012

Hello,

Here is my configuration with which I tried to compiled
the latest snapshot of 2014 name : mico-2014-02-13
(but I have also try with other packages)

- windows 7 with all fix and servicepack
- Visual Studio 2012

The compilation works well until the ide generator use :
I have an error in \mico-2014-02-13\orb\os-thread\pthreads.cc, line 496 
and idl crashed.

I do not think it comes from the pthread dll because I use the same
in other element of my framework.

Have you a solution ?

I need to compile with 2012 because all my framework developpement is 
compiled with
(C++) then if I use 2008 (I could), there will be mangling problem.

Thanks for answer.

Famenco

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
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
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
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;
    }

    IIOPProxyInvokeRec* inv_rec = pull_invoke(id);

	// Wolfgang Schneider, change 9.12.2013
	// Do not delete the id object in invoke callback action
(CORBA::ORB::get_invoke_reply)
	id->deactivate();

    switch (_orb->request_type (id)) {
    case CORBA::RequestInvoke: {
	CORBA::Object_var obj = new CORBA::Object (new CORBA::IOR);
	CORBA::Request_var req =
	    new CORBA::Request (obj, "someop");
	LocalRequest orbreq (req);
	orbreq.set_out_args (
	    new CORBA::TRANSIENT (0, CORBA::COMPLETED_MAYBE));
	_orb->answer_invoke (id, CORBA::InvokeSysEx,
			     CORBA::Object::_nil(), &orbreq, 0);
	break;
    }
    case CORBA::RequestLocate:
	_orb->answer_locate (id, CORBA::LocateUnknown,
			     CORBA::Object::_nil(), 0);
	break;
	
    case CORBA::RequestBind:
	_orb->answer_bind (id, CORBA::LocateUnknown,
			   CORBA::Object::_nil());
	break;

    default:
	assert (0);
    }

    this->del_invoke(inv_rec);
}

Orb.cc:

CORBA::InvokeStatus
CORBA::ORB::get_invoke_reply (ORBMsgId id, Object_out obj, ORBRequest *&r,
			      GIOP::AddressingDisposition &ad)
{
    ORBInvokeRec *rec = get_invoke (id);
    assert (rec);

	//Wolfgang Schneider, change 9.12.2013
	//The id object will be deleted by IIOPProxy::abort_invoke 
	bool invoke_aborting = id->active() == false;

    InvokeStatus state;
    Object_ptr o;
    CORBA::Boolean ret = rec->get_answer_invoke (state, o, r, ad);
    assert (ret);
    obj = Object::_duplicate (o);
	
	//Wolfgang Schneider, change 9.12.2013
	//The id object will be deleted by IIOPProxy::abort_invoke 
	//del_invoke ( rec->id() );
   	 if ( !invoke_aborting ) {
		del_invoke ( rec->id() );
	}

#ifndef HAVE_THREADS
    // XXX has to be changed for MT
    //_currentid = 0;
    if (!_currentid.empty()) {
	_currentid.pop();
    }
#else // HAVE_THREADS
    stack<CORBA::ORBInvokeRec*>* invs =
static_cast<stack<CORBA::ORBInvokeRec*>*>
	(MICOMT::Thread::get_specific(_current_rec_key));
    if (invs != NULL && !invs->empty()) {
	invs->pop();
    }
#endif // HAVE_THREADS
    return state;
}

Attachment (smime.p7s): application/pkcs7-signature, 8 KiB
------------------------------------------------------------------------------
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Mico-devel mailing list
Mico-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mico-devel
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.

Hmm. One thing is that nsobj and nc variables are NOT NULL from the C++ 
point of view. They are both _var smart pointers allocated statically on 
the stack so they should not be NULL anyway. The question here is if 
nsobj.in() and/or nc.in() are NULL or not, that means if the pointers 
saved into the smart pointers are null or not. That's why 
CORBA::is_nil(var) is usable here and I certainly recommend its usage 
here...

> I don't think there is smth wrong with argv[3] because with TAO it works
> just fine.

I still think this may be a culprit, if you don't believe try to use the 
same corbaloc in demo/services/naming example... Of course I may be 
mistaken here! But such is my instinct here... :-)

Karel
--

-- 
Karel Gardas                  kgardas <at> objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
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";
  argv[1] = "-ORBNoResolve";
  argv[2] = "-ORBInitRef";
  argv[3] = "NameService=corbaloc::127.0.0.1:45678/NameService";

  CORBA::ORB_var orb = CORBA::ORB_init (argc, argv);

  CORBA::Object_var poaobj = orb->resolve_initial_references ("RootPOA");
  PortableServer::POA_var poa = PortableServer::POA::_narrow (poaobj);
  PortableServer::POAManager_var mgr = poa->the_POAManager();

  PortableServer::Servant account_servant = new Account_impl;
  CORBA::Object_var the_account = account_servant->_this();

  CORBA::Object_var nsobj = orb->resolve_initial_references("NameService");
  CosNaming::NamingContext_var nc=CosNaming::NamingContext::_narrow (nsobj);

  CosNaming::Name name;
  name.length (1);
  name[0].id = CORBA::string_dup ("testname");
  name[0].kind = CORBA::string_dup ("");

  nc->rebind (name, the_account);

  return 0;
}

The problem is that when the narrowing of nsobj to
CosNaming::NamingContext occurs an CORBA::INV_POLICY is raised (but just
in the VS output) and the execution moves on. Then when the rebinding
takes place i get "Access violation reading location 0xfdfdfdfd". It is my
belief that this access violation occurs because the naming service wasn't
properly resolved/narrowed in the first place, not being able to
bind/rebind to a 'fake' naming context.

I have searched around the web for a solution, i've documented myself
about the policies, about the exception itself but i have yet to find an
answer about what's going on.

I start the naming service daemon with the following command:
nsd -ORBNoResolve -ORBDebug All -ORBIIOPAddr inet:127.0.0.1:45678

Maybe if someone has the time to give me a hint I would greatly appreciate
it. Thanks,

Smolenic Andrei

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
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

Gmane