axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Blecken" <>
Subject RE: issues establishing a persistent connection
Date Fri, 22 Apr 2005 17:35:53 GMT
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

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)?


-----Original Message-----
From: Joe Love []
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.


Backtrace from GDB:
(gdb) bt
#0  0x402327ab in raise () from /lib/tls/
#1  0x40233f12 in abort () from /lib/tls/
#2  0x401b6f47 in __cxa_call_unexpected () from /usr/lib/
#3  0x401b6f84 in std::terminate () from /usr/lib/
#4  0x401b70f6 in __cxa_throw () from /usr/lib/
#5  0x404cc6aa in xercesc_2_3::IGXMLScanner::scanNext ()
    from /usr/lib/
#6  0x40506c48 in xercesc_2_3::SAX2XMLReaderImpl::parseNext ()
    from /usr/lib/
#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

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 []
> Sent: Thursday, April 21, 2005 1:06 PM
> To:
> 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

View raw message