axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Love <joel...@lac.uic.edu>
Subject Re: issues establishing a persistent connection
Date Fri, 22 Apr 2005 17:55:32 GMT
The server is an Apache plugin, with AxisCPP still.  (Just going for a 
full c++-based solution.)

-Joe

Carsten Blecken wrote:
> DOC vs. RPC provider : Both are ok - I was cutting-and-pasting
> 
> You could go into Session.hpp to declare init(), but
> moving it into the constructor is fine too.
> 
> In terms of the stack trace it would make sense if the 
> server closes the socket, since the Axis tries to pull
> the soap header. There might be a bug for zero bytes
> returned.
> 
> In any case, you will have to figure out why the server
> did not send the result of the 2nd call. What is your server
> (Apache plugin, SimpleAxisServer, Axis Java)?
> 
> Carsten
> 
> 
> 
> -----Original Message-----
> From: Joe Love [mailto:joelove@lac.uic.edu]
> Sent: Friday, April 22, 2005 10:12 AM
> To: Apache AXIS C User List
> Subject: Re: issues establishing a persistent connection
> 
> 
> Hi Carsten,
> 
> Thanks for the suggestion.  I have a few questions & comments.
> - CPP_DOC_PROVIDER - is this the typical parameter passed to initialize? 
>   When I built the client stubs, my initialize call defaults with 
> CPP_RPC_PROVIDER as the parameter.
> - When I did the little sample there, I must not have been thinking 
> straight as *Service.cpp is one of the server-side files, so the clarity 
> on whether anything would be the client or server code is a bit confusing.
> - The code you suggested appears to me to be client-side code, yet if I 
> try to declare an init() function in the generated stub file fails, with 
>   the error: no `int session::init()' member function declared in
>     class `session' (eg, if the stub is session.cpp, declaring 
> session::init()... there is no init() function in Stub.hpp from the axis 
> includes, so this seems to be obvious why it doesn't work that way.  THe 
> server-side stuff has an init() function however, which is why my 
> confusion as to whether this is supposed to be client or server.
> 
> I was reluctant to give up based on the functions not existing, so I 
> tried moving around the initialize() & uninitialize() functions.  I 
> moved the initialize to the constructor, and the uninitialize to the 
> destructor, and thus the individual calls (store() & get()) will not to 
> the initialization & uninitialization during their processing.
> 
> This yeilded me an "Abort (core dumped) on the second function call. 
> The first call succeeds, but the second fails.  The backtrace from gdb 
> is included below.  A look at the network traffic shows that the client 
> connects to the server, sends the first request, gets the response, 
> sends the second request, and the server closes the connection (as 
> opposed to the client closing it).
> 
> Any insight into this would be appreciated.
> 
> Thanks,
> -Joe
> 
> Backtrace from GDB:
> (gdb) bt
> #0  0x402327ab in raise () from /lib/tls/libc.so.6
> #1  0x40233f12 in abort () from /lib/tls/libc.so.6
> #2  0x401b6f47 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.5
> #3  0x401b6f84 in std::terminate () from /usr/lib/libstdc++.so.5
> #4  0x401b70f6 in __cxa_throw () from /usr/lib/libstdc++.so.5
> #5  0x404cc6aa in xercesc_2_3::IGXMLScanner::scanNext ()
>     from /usr/lib/libxerces-c.so.23
> #6  0x40506c48 in xercesc_2_3::SAX2XMLReaderImpl::parseNext ()
>     from /usr/lib/libxerces-c.so.23
> #7  0x4035b5df in XMLParserXerces::next (this=0x805c198, isCharData=false)
>      at XMLParserXerces.cpp:94
> #8  0x400b0537 in axiscpp::SoapDeSerializer::getHeader (this=0x805b090)
>      at SoapDeSerializer.cpp:198
> #9  0x4007f68d in axiscpp::ClientAxisEngine::invoke (this=0x805a850,
>      pMsg=0x805a888) at ClientAxisEngine.cpp:208
> #10 0x4007f3b3 in axiscpp::ClientAxisEngine::process (this=0x805a850,
>      pSoap=0x804f518) at ClientAxisEngine.cpp:115
> #11 0x4008c98e in axiscpp::Call::invoke (this=0x804c3d0) at Call.cpp:145
> #12 0x0804987d in session::store (this=0xbffffad0,
>      Value0=0x804ab51 "more data") at session.cpp:61
> #13 0x08049161 in main (argc=1, argv=0xbffffba4) at test1.cpp:31
> (gdb)
> 
> 
> Carsten Blecken wrote:
> 
>>Hi Joe,
>>
>>yes the connection teardown at every call can be an issue.
>>
>>I played some time ago in the stub layer to expose the Call
>>initialization/deinit which keeps the connection :
>>
>>The Stub object AxisService.cpp is build structurally as :
>>
>>AxisService::AxisService() {}
>> 
>>AxisService::~AxisService() {}
>>
>>AxisService::setValue(int val) {
>>	m_pCall->initialize(CPP_DOC_PROVIDER);     // open the connection
>>      ...    // serializing
>>	m_pCall->invoke();
>>      ...    // deserializing
>>      m_pCall->unInitialize();			// closes the connection
>>}
>>
>>changing this to
>>
>>AxisService::AxisService() {}
>> 
>>AxisService::~AxisService() {}
>>
>>AxisService::init() {
>>	m_pCall->initialize(CPP_DOC_PROVIDER);     // open the connection
>>      m_isInitialized = true; 
>>}
>>
>>AxisService::deInit() {
>>      m_pCall->unInitialize();			// closes the connection	
>>      m_isInitialized = false; 
>>}
>>
>>AxisService::setValue(int val) {
>>	if (!m_isInitialized)
>>		m_pCall->initialize(CPP_DOC_PROVIDER);     // open the connection
>>      ...    // serializing
>>	m_pCall->invoke();
>>      ...    // deserializing
>>      if (!m_isInitialized)
>>      	m_pCall->unInitialize();			// closes the connection
>>}
>>
>>you would have in principle full control over the 
>>connection management. I'm not sure whether this works with
>>the current code, but this is something you could try
>>without changing the axis libraries.
>>
>>Carsten
>>
>>-----Original Message-----
>>From: Joe Love [mailto:joelove@lac.uic.edu]
>>Sent: Thursday, April 21, 2005 1:06 PM
>>To: axis-c-user@ws.apache.org
>>Subject: issues establishing a persistent connection
>>
>>
>>Is there a procedure for getting axis to establish persistent 
>>connections, so that calls to methods in a service will use the same 
>>connection, rather than establishing their own connection?
>>
>>Right now, I can have code along the lines of the following:
>>
>>AxisService as;
>>as.setvalue(5);
>>int val = as.getvalue();
>>
>>Every call establishes a new connection to the server; opens up a new 
>>port on the client side, creates a new tcp connection to the server, 
>>etc).  This is problematic, because I can't retrieve data I may have set 
>>already.  In the above example, if getvalue() returns the value stored 
>>by setvalue(), I cannot retrieve the value set.
>>
>>There was a previous email about persistent connections which suggested 
>>that they were the default behavior, however, my testing is not showing 
>>that axis is behaving this way.
>>
>>I'm not sure what information would be useful in trying to understand 
>>what is happening here, but I can provide any information that may be of 
>>interest.
>>
>>Thanks,
>>-Joe
>>
>>
> 
> 
> 
> 


Mime
View raw message