-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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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
