Anonymous_User Absent Member.
Absent Member.
1593 views

Connecting to Session and objects, Destroying objects question - Best Practices?

I've written a .dll that can be used to send and receive mail through the
GroupWise Object API to a GroupWise server.

This .dll is used by an existing Service, and it ends up that the Service
calls a Disconnect and Connect function after 15 minutes of inactivity. For
instance,

1.Service starts. Calls Connect function.
2. Check for new mail and process all send/receive requests every 1 minute.
3. After 15 minutes of inactivity, call disconnect function.
4. 15 minutes later: Call Connect function and check for new mail, etc.

Problem: After 1 or 2 reconnects/disconnects, it crashes/cores out.

I'm going to work on pinpointing the problem, it likely is my own error, but
I wanted to verify that I'm creating/destroying all of the Object API
objects correctly. Here is my disconnect code that destorys the objects
(which I really suspect as the problem), followed by my connect code (which
I suspect less, since it is patterned after the samples.)

One thing I'm thinking off the bat is that I don't need to destroy/re-create
the Session object...

int CGroupWiseInterface::DisconnectFromMailSrv()
{
try
{
// Release messages object
if (m_pIGWMessages)
m_pIGWMessages->Release();
if (m_pIGWMessage)
m_pIGWMessage->Release();
if (m_pDIGWMessage)
m_pDIGWMessage->Release();
if(m_pIGWMessagesList)
m_pIGWMessagesList->Release();
if (m_pIGWAccount)
m_pIGWAccount->Release();
if (m_pIGWSession)
m_pIGWSession->Release();

m_pIGWMessages = NULL;
m_pIGWMessage = NULL;
m_pDIGWMessage = NULL;
m_pIGWMessagesList = NULL;
m_pIGWAccount = NULL;
m_pIGWSession = NULL;
}
catch(...)
{
m_pIGWMessages = NULL;
m_pIGWMessage = NULL;
m_pDIGWMessage = NULL;
m_pIGWAccount = NULL;
m_pIGWSession = NULL;
m_pIGWMessagesList = NULL;
}

return 1;
}

BOOL CGroupWiseInterface::CreateSession(CString csUserID, CString
csServerName, CString csPort,
CString csTrustAppName, CString csTrustAppKey)
{
DIGWAccount* pDIGWAccount = NULL; BOOL toReturn;
VARIANT vUserId, vCmdLine, vPassword, vWhenToPrompt, vReserved;
BSTR bstrUserID = NULL; BSTR bstrCmdLine = NULL;

try
{
// Create the Session Object
if(FAILED(CoCreateInstance(CLSID_GroupWare, NULL, CLSCTX_INPROC_SERVER |
CLSCTX_INPROC_HANDLER | CLSCTX_LOCAL_SERVER, IID_IGWSession4,
(void**)&m_pIGWSession))) {
ErrorMessage(_T("Could not create GroupWise session object. Please
confirm that Groupwise is installed on this computer."));
return FALSE;
}

if(!SUCCEEDED(m_pIGWSession->SetTrustedApplicationCredentials(csTrustAppName.AllocSysString(),
csTrustAppKey.AllocSysString())))
{
ErrorMessage(_T("Error starting GroupWise Session: Couldn't establish
Trusted Application Credentials. Check Trusted App Name and Trusted App
Key."));
return FALSE;
}

//Calculate the CmdLine using this example: "/ipa-199.99.99.99 /ipp-1677"
CString csCmdLine = _T("");
csCmdLine.Format("/ipa-%s /ipp-%s", csServerName, csPort);

bstrUserID = csUserID.AllocSysString();
bstrCmdLine = csCmdLine.AllocSysString();

VariantInit(&vUserId);
VariantInit(&vCmdLine);
VariantInit(&vPassword);
VariantInit(&vWhenToPrompt);
VariantInit(&vReserved);

V_VT(&vUserId) = VT_BSTR;
V_VT(&vCmdLine) = VT_BSTR;
V_VT(&vPassword) = VT_EMPTY;
V_VT(&vWhenToPrompt) = VT_I2;
V_VT(&vReserved) = VT_EMPTY;

V_I2(&vWhenToPrompt) = egwNeverPrompt;
V_BSTR(&vUserId) = bstrUserID;
V_BSTR(&vCmdLine) = bstrCmdLine;

// Login
if(!SUCCEEDED(m_pIGWSession->MultiLogin(bstrUserID, vCmdLine, vPassword,
vWhenToPrompt, vReserved, &pDIGWAccount))) {
CString csErrMsg = _T("");
csErrMsg.Format("Could not login to GroupWise with userid: %s and
command: %s", csUserID, csCmdLine);
ErrorMessage(csErrMsg);
toReturn = FALSE;
}
else
{
// Get the Root Account's Interface
if(FAILED(pDIGWAccount->QueryInterface(IID_IGWAccount3,
(LPVOID*)&m_pIGWAccount)))
{
ErrorMessage(_T("Error starting GroupWise Session: Couldn't obtain
Account from Dispatch Interface"));
toReturn = FALSE;
}
else
{
pDIGWAccount->Release();
toReturn = TRUE;
}
}
}
catch(CException* exp)
{
CString csErrMsg = _T("");
csErrMsg.Format("Error connecting. User: %s Server:%s Port:%s Error:",
csUserID, csServerName, csPort);
HandleException(csErrMsg, exp);
toReturn = FALSE;
}
catch(...)
{
ErrorMessage(_T("Uknown Exception ocurred while sending mail."));
toReturn = FALSE;
}
return toReturn;

}


Labels (1)
0 Likes
4 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Connecting to Session and objects, Destroying objects question - Best Practices?

I've figured out that the problem isn't with the Disconnect/Connect code,
per se. Instead, my current guess is that the problem is due to persisting
the objects for long periods of time (i.e. one minute or more). I haven't
gotten to the bottom of which is the culprit, but occasionally an exception
will be thrown when I call release() on a DIGWMessage object. While that
object has only persisted for milliseconds/a few seconds, the
messages/messageslist object it came from may have persisted for as long as
15 minutes. Which begs the question: Which objects should I not leave
hanging around for extended periods of time? All of them? All but Session
and Account?

Jason
"Jason Foster" <jasonphos@pobox.com> wrote in message
news:w8LUj.11066$Dh4.10796@kovat.provo.novell.com...
> I've written a .dll that can be used to send and receive mail through the
> GroupWise Object API to a GroupWise server.
>
> This .dll is used by an existing Service, and it ends up that the Service
> calls a Disconnect and Connect function after 15 minutes of inactivity.
> For instance,
>
> 1.Service starts. Calls Connect function.
> 2. Check for new mail and process all send/receive requests every 1
> minute.
> 3. After 15 minutes of inactivity, call disconnect function.
> 4. 15 minutes later: Call Connect function and check for new mail, etc.
>
> Problem: After 1 or 2 reconnects/disconnects, it crashes/cores out.



0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Connecting to Session and objects, Destroying objects question- Best Practices?

The problem is not in the duration, but in getting all of the objects
released.
We've implemented the code to support free threading.
That means there is only one instance of an object for all threads.
To support this we sometimes have to hold on to objects until all objects
that are dependent on them can be released. For example a message object
is dependent on the messages object which is dependent on the folder
object.
When of reference counts in all of the objects go to zero, we then can
remove
all of the objects. You have to take more care than normal COM objects to
make sure all objects get released.

If you can create a sample app that recreates the problem, I could debug
through it to see what the problem is.

Preston

>>> On Thursday, May 08, 2008 at 8:37 PM, Jason Foster<jasonphos@pobox.com>

wrote:
> I've figured out that the problem isn't with the Disconnect/Connect code,


> per se. Instead, my current guess is that the problem is due to persisting


> the objects for long periods of time (i.e. one minute or more). I haven't


> gotten to the bottom of which is the culprit, but occasionally an

exception
> will be thrown when I call release() on a DIGWMessage object. While that
> object has only persisted for milliseconds/a few seconds, the
> messages/messageslist object it came from may have persisted for as long

as
> 15 minutes. Which begs the question: Which objects should I not leave
> hanging around for extended periods of time? All of them? All but Session


> and Account?
>
> Jason
> "Jason Foster" <jasonphos@pobox.com> wrote in message
> news:w8LUj.11066$Dh4.10796@kovat.provo.novell.com...
>> I've written a .dll that can be used to send and receive mail through the


>> GroupWise Object API to a GroupWise server.
>>
>> This .dll is used by an existing Service, and it ends up that the Service


>> calls a Disconnect and Connect function after 15 minutes of inactivity.
>> For instance,
>>
>> 1.Service starts. Calls Connect function.
>> 2. Check for new mail and process all send/receive requests every 1
>> minute.
>> 3. After 15 minutes of inactivity, call disconnect function.
>> 4. 15 minutes later: Call Connect function and check for new mail, etc.
>>
>> Problem: After 1 or 2 reconnects/disconnects, it crashes/cores out.

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Connecting to Session and objects, Destroying objects question - Best Practices?

Nevermind most of this thread, I've decided I was wrong on several counts.

I believe I have fixed this. My final discovery is that in some
circumstances I was calling release() without setting the variable to NULL,
and then calling it again later. That caused the exception.

"Jason Foster" <jasonphos@pobox.com> wrote in message
news:0OOUj.11108$Dh4.2812@kovat.provo.novell.com...
> I've figured out that the problem isn't with the Disconnect/Connect code,
> per se. Instead, my current guess is that the problem is due to persisting
> the objects for long periods of time (i.e. one minute or more). I haven't
> gotten to the bottom of which is the culprit, but occasionally an
> exception will be thrown when I call release() on a DIGWMessage object.
> While that object has only persisted for milliseconds/a few seconds, the
> messages/messageslist object it came from may have persisted for as long
> as 15 minutes. Which begs the question: Which objects should I not leave
> hanging around for extended periods of time? All of them? All but Session
> and Account?
>
> Jason
> "Jason Foster" <jasonphos@pobox.com> wrote in message
> news:w8LUj.11066$Dh4.10796@kovat.provo.novell.com...
>> I've written a .dll that can be used to send and receive mail through the
>> GroupWise Object API to a GroupWise server.
>>
>> This .dll is used by an existing Service, and it ends up that the Service
>> calls a Disconnect and Connect function after 15 minutes of inactivity.
>> For instance,
>>
>> 1.Service starts. Calls Connect function.
>> 2. Check for new mail and process all send/receive requests every 1
>> minute.
>> 3. After 15 minutes of inactivity, call disconnect function.
>> 4. 15 minutes later: Call Connect function and check for new mail, etc.
>>
>> Problem: After 1 or 2 reconnects/disconnects, it crashes/cores out.

>
>



0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Connecting to Session and objects, Destroying objects question- Best Practices?

Hi Preston,

Thank you for the response. I did find one or two problems with my release
code in other parts of the program, and resolved them. At this point, I
think I'm running fine, except for the seperate issue I posted about a
window popping up. I'll let you know if I have more memory problems. Thank
you again,

Jason
"Preston Stephenson" <PStephenson@gw.novell.com> wrote in message
news:4823D156.07F1.0037.1@gw.novell.com...
> The problem is not in the duration, but in getting all of the objects
> released.
> We've implemented the code to support free threading.
> That means there is only one instance of an object for all threads.
> To support this we sometimes have to hold on to objects until all objects
> that are dependent on them can be released. For example a message object
> is dependent on the messages object which is dependent on the folder
> object.
> When of reference counts in all of the objects go to zero, we then can
> remove
> all of the objects. You have to take more care than normal COM objects to
> make sure all objects get released.
>
> If you can create a sample app that recreates the problem, I could debug
> through it to see what the problem is.
>
> Preston



0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.