Optimizing Question

We have Client users who user the great Client ability to send and receive to POP3 and IMAP accounts that are "outside" of the GroupWise system (like gmail and yahoo). However, when large file attachments come in, the Client "freezes" during the duration the attachment is downloaded. ... None of these "outside" email imports flow through the GWIA and I wouldn't think they would. So this is probably a stupid question, but is there a way to make use of great Client ability to send and receive email from "outside" accounts and avoid the "freeze" that happens when large attachments come in? Clients are running direct access with Post Office (which works fine). ... Probably no solution, but just thought I would post.

Tags:

Parents
  • In article <holub457.8dvge0@no-mx.forums.microfocus.com>, Holub457
    wrote:
    > but is there a way to make use of great Client ability to send
    > and receive email from "outside" accounts and avoid the "freeze" that
    > happens when large attachments come in? Clients are running direct
    > access with Post Office (which works fine).


    Try running those instances of the client in caching mode to make sure
    that multi threading logic is running. I typically run in caching mode
    and haven't seen such issues, but then I don't recall much in the way
    of large attachments on those accounts.
    Does the system the Client runs on have multiple cores? How tight do
    the run on RAM? When such a message is coming it, is the hard drive
    activity light on most of the time?


    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!

Reply
  • In article <holub457.8dvge0@no-mx.forums.microfocus.com>, Holub457
    wrote:
    > but is there a way to make use of great Client ability to send
    > and receive email from "outside" accounts and avoid the "freeze" that
    > happens when large attachments come in? Clients are running direct
    > access with Post Office (which works fine).


    Try running those instances of the client in caching mode to make sure
    that multi threading logic is running. I typically run in caching mode
    and haven't seen such issues, but then I don't recall much in the way
    of large attachments on those accounts.
    Does the system the Client runs on have multiple cores? How tight do
    the run on RAM? When such a message is coming it, is the hard drive
    activity light on most of the time?


    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!

Children
  • We'll give caching mode a try. Typical system is running Intel i7 CPU with 32 GB RAM and SSD. Very fast machines and very fast internet connect. Slowness is likely at the gmail and yahoo server levels.
  • Just FYI, caching mode is, if anything, even slower. This is definitely Groupwise Client issue and way it it deals with pop3 and imap external accounts. Logging into a gmail account via browser yields near instant download of a 13,000 kb file attachment that will take 10 minutes to download in Groupwise.
  • In article <holub457.8dvwhz@no-mx.forums.microfocus.com>, Holub457
    wrote:
    > This is definitely
    > Groupwise Client issue and way it it deals with pop3 and imap external
    > accounts.


    What other pop or imap clients have you tested against the same accounts
    for the same messages?
    What we want to do is isolate if it is those services being slow or not.
    Then is it just that GroupWise client is running a blocking thread or
    that it is also just slow with those protocols.
    Which build(s) of the client have you seen this with?
    If you have maintenance, you could open an SR and see if you get some
    results as I haven't heard of this issue on previous versions of the
    client.

    Because of the different caching mailboxes I juggle for different
    clients, I tend to keep my pop/imap accounts separately over with
    Thunderbird, so I can vouch for that combination working well.


    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!

  • Using Client Release 18.0.0 Build 129299. This problem is same with earlier versions of Client. Keeping accounts separate defeats the purpose of having one unified inbox. Is there perhaps a log with detail that can generated when Client connects to an external POP or IMAP? There appears to be a very sparse log created called statuslog.txt. grpwise.exe seems to utlize 79,780 K memory no matter what is happening with client.
  • Just a further update. ... Set user external account access (gmail, yahoo, etc) to IMAP. Large attachments download very rapidly under IMAP. So POP3 slow attachment downloads (and Client freezing for duration of download) are function of Client presumably, or ALL third party POP3 servers are slow (which is highly unlikely). ... The problem with using IMAP is that Client creates isolated Inbox folders for each account, and Client rules for moving email automatically to specified folders do not work on any of the multiple IMAP inbox. So pulling all email accounts into Groupwise Client using IMAP is essentially worthless, since none of downloaded emails can be automatically manipulated by the client. ... So POP3 download either needs to be tinkered with in future client versions, OR segregating IMAP messages needs to be abolished (this would be preference it would seem).
  • holub457 wrote:

    >
    > Just a further update. ... Set user external account access (gmail,
    > yahoo, etc) to IMAP. Large attachments download very rapidly under
    > IMAP. So POP3 slow attachment downloads (and Client freezing for
    > duration of download) are function of Client presumably, or ALL third
    > party POP3 servers are slow (which is highly unlikely).


    One cannot determine an appropriate solution until the actual caused is
    determined. You have suggested a couple of possible causes. The next
    step is to validate your assumptions.

    If you Google "pop3 download slow" there are lots of hits, many going
    back ten years and many involving Outlook so I would suspect this is
    not specifically a GroupWise issue.

    You say that IMAP doesn't experience the same issue. Perhaps you could
    run a packet trace with Wireshark while retrieving the same email via
    POP3 and IMAP4. Comparing the two packet traces may provide some
    insight.

    You may also test using different POP3 clients, perhaps trying one
    running on Linux. The results of these tests may show similar results
    to those you describe using GroupWise. If so, that would suggest the
    issue is unrelated to the GroupWise client.


    --
    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below this post.
    Thank you.
  • Well, Wireshark trace shows simply that the packets transmitted with POP3 are small packets. 54 bytes. No actual errors show. Just small packets. However, packet size for IMAP is also small 54 bytes. Nothing whatsoever shows basis of slow transmission. However, and this might be big, every 25 packets the POP3 times out with a Zero Window. Apparently, this means "... client is not able to receive further information at the moment, and the TCP transmission is halted until it can process the information in its receive buffer." ... This seems to fit with the old posts about Outlook. ... But, no idea how to fix.
  • holub457 wrote:

    > This seems to fit with the old
    > posts about Outlook. ... But, no idea how to fix.


    Does this KB article apply or help?
    https://support.microsoft.com/en-us/help/935400/it-takes-much-longer-than-expected-to-download-an-e-mail-message-from

    --
    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below this post.
    Thank you.
  • Well either with settings of
    netsh interface tcp set global autotuninglevel=disabled
    or
    netsh interface tcp set global autotuninglevel=normal

    the result is the same in the Wireshark logs.
  • holub457 wrote:

    >
    > Well either with settings of
    > netsh interface tcp set global autotuninglevel=disabled
    > or
    > netsh interface tcp set global autotuninglevel=normal
    >
    > the result is the same in the Wireshark logs.


    That's unfortunate but at least it eliminates one possible cause.

    If the packet traces of the IMAP4 and POP3 downloads are essentially
    the same other than...
    > every 25 packets the POP3 times out with a Zero Window.

    I would try to determine why this is happening.

    See if you observe the same behaviour using a different POP3 client
    and/or running from a different platform (Mac or Linux).

    The goal is to try to identify what conditions might cause these slow
    downloads or to eliminate the timeout as the issue.

    At the moment I don't have any additional ideas.

    --
    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below this post.
    Thank you.