Skip Menu |

This queue is for tickets about the Mail-IMAPClient CPAN distribution.

Report information
The Basics
Id: 31655
Status: resolved
Priority: 0/
Queue: Mail-IMAPClient

People
Owner: Nobody in particular
Requestors: lonnieb [...] kcsrcpas.com
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: (no value)
Fixed in: (no value)



Subject: get_header
I just recently updated to Mail::IMAPClient 3.02 via yum. I am on centOS 5. I have a script that was running before that doesn't seem to be working properly anymore. get_header() seems to not be returning the correct results. my $messageId = $imap->get_header($msg, "Message-Id"); returns Null and my $SpamStatus = $imap->get_header($msg, "X-Spam-Status"); doesn't init $SpamStatus. reverting back to 2.2.9 this will return the message id without changing the code. However $SpamStatus still does the same. Maybe another update broke this. I seem to think I remember message_string($msg) and fetch($msg,'RFC822') returning the headers above "Date:" (i.e. recieved, X-Spam-Status), not sure about this part or if it is related to the issue.
Subject: Re: [rt.cpan.org #31655] get_header
Date: Wed, 19 Dec 2007 09:38:21 +0100
To: Lonnie Boudreaux via RT <bug-Mail-IMAPClient [...] rt.cpan.org>
From: Mark Overmeer <mark [...] overmeer.net>
* Lonnie Boudreaux via RT (bug-Mail-IMAPClient@rt.cpan.org) [071218 17:03]: Show quoted text
> Tue Dec 18 12:03:30 2007: Request 31655 was acted upon. > Transaction: Ticket created by lonnieb > Queue: Mail-IMAPClient > Subject: get_header > Broken in: (no value) > Severity: Critical > Owner: Nobody > Requestors: lonnieb@kcsrcpas.com > Status: new > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=31655 > > > I just recently updated to Mail::IMAPClient 3.02 via yum. I am on > centOS 5. I have a script that was running before that doesn't seem to > be working properly anymore. get_header() seems to not be returning the > correct results.
The weird thing is: a lot of people are using the module, and they do not experience your problem. So... let's try to find-out what is happening. Could you send me the debug trace (initiate the module with "Debug) and a dump of the header structure, for instance made via sub get_header { my ($self, $msg, $field) = @_; my $headers = $self->parse_headers($msg, $field); + use Data::Dumper; + print Dumper $headers; $headers ? $headers->{$field}[0] : undef; } Looking at the code, I suspect that there is a casing problem; try $imap->get_header('message-id'); Show quoted text
> reverting back to 2.2.9 this will return the message id without changing > the code. However $SpamStatus still does the same. Maybe another > update broke this. I seem to think I remember message_string($msg) and > fetch($msg,'RFC822') returning the headers above "Date:" (i.e. recieved, > X-Spam-Status), not sure about this part or if it is related to the issue.
2.2.9 is 4 years old, so there is no "other update". If your last remark is true, then both releases should result in the same. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Subject: Re: [rt.cpan.org #31655] get_header
Date: Wed, 19 Dec 2007 08:39:14 -0600
To: bug-Mail-IMAPClient [...] rt.cpan.org
From: Lonnie Boudreaux <lonnieb [...] kcsrcpas.com>
Ok I will try to go back to 3.02 and do the debug sometime this week. I have tested this again, updating only IMAPClient from 2.2.9 to 3.02 will break it again. I have resolved the "X-Spam-Status" issue in 2.2.9 so that the script runs as it did pre update. This ended up being a slight difference in the way amavisd wrote the header. Not sure why it changed, but that is resolved now. I have tried several variances on the case: all upper, all lower, and how it is in the the message, they all yield the same result. My test script has it as all lowercase since the function description claims it is not case sensitive. 2.29 Output on Test script <47684440.5080104@kcsrcpas.com> No, score=-1.437 tagged_above=-150 required=3 tests=[ALL_TRUSTED=-1.44, AWL=0.003] autolearn=unavailable 3.02 Output on Test Script Use of uninitialized value in concatenation (.) or string at ./lon2 line 32. Use of uninitialized value in concatenation (.) or string at ./lon2 line 34. lines 32 and 34 or the print statements for the headers Mark Overmeer via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=31655 > > > * Lonnie Boudreaux via RT (bug-Mail-IMAPClient@rt.cpan.org) [071218 17:03]: >
>> Tue Dec 18 12:03:30 2007: Request 31655 was acted upon. >> Transaction: Ticket created by lonnieb >> Queue: Mail-IMAPClient >> Subject: get_header >> Broken in: (no value) >> Severity: Critical >> Owner: Nobody >> Requestors: lonnieb@kcsrcpas.com >> Status: new >> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=31655 > >> >> I just recently updated to Mail::IMAPClient 3.02 via yum. I am on >> centOS 5. I have a script that was running before that doesn't seem to >> be working properly anymore. get_header() seems to not be returning the >> correct results. >>
> > The weird thing is: a lot of people are using the module, and they do > not experience your problem. So... let's try to find-out what is > happening. > > Could you send me the debug trace (initiate the module with "Debug) > and a dump of the header structure, for instance made via > > sub get_header > { my ($self, $msg, $field) = @_; > my $headers = $self->parse_headers($msg, $field); > + use Data::Dumper; > + print Dumper $headers; > $headers ? $headers->{$field}[0] : undef; > } > > Looking at the code, I suspect that there is a casing problem; try > $imap->get_header('message-id'); > >
>> reverting back to 2.2.9 this will return the message id without changing >> the code. However $SpamStatus still does the same. Maybe another >> update broke this. I seem to think I remember message_string($msg) and >> fetch($msg,'RFC822') returning the headers above "Date:" (i.e. recieved, >> X-Spam-Status), not sure about this part or if it is related to the issue. >>
> > 2.2.9 is 4 years old, so there is no "other update". If your last > remark is true, then both releases should result in the same. >
From: gonullu [...] bluewin.ch
Hello All, My scripts have also stopped to work after my update (2.2.9 to 3.02) on my mac osx 10.4.11. The "body_string" method is returning undef (because of a timeout). In the test you see that the body is fetched (till the <END> mark) but the script stand there waiting... Below you will see the output with the Debug flag turned on. Using Mail::IMAPClient version 3.02 on perl 5.008008 Read: * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE AUTH=PLAIN ACL ACL2=UNION] Courier-IMAP ready. Copyright 1998-2005 Double Precision, Inc. See COPYING for distribution information. Sending: 1 LOGIN "salih.gonullu@....h" "***********" Sent 49 bytes Read: 1 OK LOGIN Ok. Sending: 2 SELECT Inbox.test Sent 21 bytes Read: * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent) * OK [PERMANENTFLAGS (\* \Draft \Answered \Flagged \Deleted \Seen)] Limited * 3 EXISTS * 0 RECENT * OK [UIDVALIDITY 1197991009] Ok * OK [MYRIGHTS "acdilrsw"] ACL 2 OK [READ-WRITE] Ok Sending: 3 UID SEARCH NOT DELETED Sent 26 bytes Read: * SEARCH 3 3 OK SEARCH done. Sending: 4 UID FETCH 3 BODY.PEEK[HEADER.FIELDS (To Cc Subject)] Sent 56 bytes LITERAL: received literal in line * 3 FETCH (UID 3 BODY[HEADER.FIELDS ("To" "Cc" "Subject")] of length 68; attempting to retrieve from the 94 bytes in: To: Salih Goenuellue <salih.gonullu@...h> Subject: test123 ) 4 OK FETCH completed. <END_OF_iBuffer> Read: * 3 FETCH (UID 3 BODY[HEADER.FIELDS ("To" "Cc" "Subject")] To: Salih Goenuellue <salih.gonullu@...h> Subject: test123 ) 4 OK FETCH completed. Sending: 5 UID FETCH 3 BODY.PEEK[TEXT] Sent 31 bytes LITERAL: received literal in line * 3 FETCH (UID 3 BODY[TEXT] of length 310; attempting to retrieve from the 0 bytes in: <END_OF_iBuffer> Received ret=310 and buffer = In this section, the Fourier technique used in section 1 is expanced to the 2-dimensional grid. This method sets up an integral for this resistance between any two nodes, and a solution is found for the resistance across the diagonal of a single square (between nodes (0,0) and (1,1) in Figure 2. <END> while processing LITERAL ERROR: Tag 5: Timeout after 30 seconds waiting for data from server ERROR: Timeout after 30 seconds during read from server ERROR: Unable to parse server response from 5 UID FETCH 3 BODY.PEEK[TEXT] Could not retrieve body at send-mails.pl line 252. (the script died because the body is undef) Thanks in advance
Subject: Re: [rt.cpan.org #31655] get_header
Date: Wed, 19 Dec 2007 22:36:30 +0100
To: Gonullu via RT <bug-Mail-IMAPClient [...] rt.cpan.org>
From: Mark Overmeer <solutions [...] overmeer.net>
* Gonullu via RT (bug-Mail-IMAPClient@rt.cpan.org) [071219 16:41]: Show quoted text
> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=31655 > > > Hello All, > > My scripts have also stopped to work after my update (2.2.9 to 3.02) > on my mac osx 10.4.11. The "body_string" method is returning undef > (because of a timeout). In the test you see that the body is fetched > (till the <END> mark) but the script stand there waiting...
Weird. Apparently, we stay in the while while($expected_size > length $litstring) where the "debug" says that we got everything. Show quoted text
> LITERAL: received literal in line * 3 FETCH (UID 3 BODY[TEXT] of length > 310; attempting to retrieve from the 0 bytes in: <END_OF_iBuffer> > Received ret=310 and buffer =
we received 310 out of 310! ?? We should leave the loop. Could you try $self->_debug("Received ret=$ret and buffer = " . "\n$litstring<END>\nwhile processing LITERAL"); + $self->_debug("length litstring = ", length $litstring); to help me thinking... -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
From: gonullu [...] bluewin.ch
Show quoted text
> Apparently, we stay in the while > while($expected_size > length $litstring) > where the "debug" says that we got everything.
It is not that while loop but I think it is the until that we stay in I have put: my $transno = $self->Transaction; + $self->_debug("in $transno entering until ", Dumper $oBuffer); and I see for transaction 5 2 times with $oBuffer is the following: Show quoted text
------------------- output -------------------------------------- in 5 entering until $VAR1 = []; LITERAL: received literal in line * 3 FETCH (UID 3 BODY[TEXT] of length 310; attempting to retrieve from the 0 bytes in: <END_OF_iBuffer> Received ret=310 and buffer = In this section, the Fourier technique used in section 1 is expanced to the 2-dimensional grid. This method sets up an integral for this resistance between any two nodes, and a solution is found for the resistance across the diagonal of a single square (between nodes (0,0) and (1,1) in Figure 2. <END> while processing LITERAL length litstring = 310 in 5 entering until $VAR1 = [ [ 1, 'OUTPUT', '* 3 FETCH (UID 3 BODY[TEXT]' ], [ 2, 'LITERAL', ' In this section, the Fourier technique used in section 1 is expanced to the 2-dimensional grid. This method sets up an integral for this resistance between any two nodes, and a solution is found for the resistance across the diagonal of a single square (between nodes (0,0) and (1,1) in Figure 2. ' ] ];
Subject: Re: [rt.cpan.org #31655] get_header
Date: Mon, 24 Dec 2007 12:36:05 +0100
To: Gonullu via RT <bug-Mail-IMAPClient [...] rt.cpan.org>
From: Mark Overmeer <mark [...] overmeer.net>
* Gonullu via RT (bug-Mail-IMAPClient@rt.cpan.org) [071221 16:27]: Show quoted text
> > Apparently, we stay in the while > > while($expected_size > length $litstring) > > where the "debug" says that we got everything.
> > It is not that while loop but I think it is the until that we stay in > I have put: > > my $transno = $self->Transaction; > + $self->_debug("in $transno entering until ", Dumper $oBuffer); > > and I see for transaction 5 2 times with $oBuffer is the following:
I am still puzzled. Is there any way that I can access your server to reproduce the problems? -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Subject: Re: [rt.cpan.org #31655] get_header
Date: Wed, 2 Jan 2008 14:18:55 +0100
To: Gonullu via RT <bug-Mail-IMAPClient [...] rt.cpan.org>
From: Mark Overmeer <solutions [...] overmeer.net>
* Gonullu via RT (bug-Mail-IMAPClient@rt.cpan.org) [071221 16:27]: Show quoted text
> It is not that while loop but I think it is the until that we stay in > I have put: > > my $transno = $self->Transaction; > + $self->_debug("in $transno entering until ", Dumper $oBuffer); > > and I see for transaction 5 2 times with $oBuffer is the following:
The until() should run at least 3 times, because we still miss the closing ')' of the FETCH, and the trailing 'OK'. The latter line is the reason we stay in the loop. I have re-frased the _read_line a little, to make it even more clear what happens. But I really need your help to get to the bottom of this... -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Download Mail-IMAPClient-3.03.tar.gz
application/x-gunzip 163.4k

Message body not shown because it is not plain text.

The bug-report probably did hide the real cause for the problem from me. Gladly, http://rt.cpan.org/Ticket/Display.html?id=32398 came in, which pointed my in the right direction. I suspect that also your problems were caused by missing out on the UID information which Windows Server 2003 hides in a very unusual place. So, the header information was received, but stored under the message ID, not the UID. Please confirm that 3.04 is working for you
Subject: Re: [rt.cpan.org #31655] get_header
Date: Fri, 25 Jan 2008 14:54:20 -0600
To: bug-Mail-IMAPClient [...] rt.cpan.org
From: Lonnie Boudreaux <lonnieb [...] kcsrcpas.com>
Sorry for the delay, I had some family issues to tend to. I am personally not using any windows products in relation to this issue, but I will upgrade to the new version and test to see if this fixes the issues that I was having. I will try to do this before COB today or on Monday. Thanks Mark Overmeer via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=31655 > > > The bug-report probably did hide the real cause for the problem from me. > Gladly, http://rt.cpan.org/Ticket/Display.html?id=32398 came in, which > pointed my in the right direction. > > I suspect that also your problems were caused by missing out on the UID > information which Windows Server 2003 hides in a very unusual place. So, > the header information was received, but stored under the message ID, > not the UID. > > Please confirm that 3.04 is working for you > > > >
Subject: Re: [rt.cpan.org #31655] get_header
Date: Thu, 31 Jan 2008 09:55:58 -0600
To: bug-Mail-IMAPClient [...] rt.cpan.org
From: Lonnie Boudreaux <lonnieb [...] kcsrcpas.com>
It seemed to fix the test script that I had written, but the main script where I noticed the problem still gives an error. I am still trying to narrow down the case that it happens on to write another test script. Will post back. Thanks
Didn't get additional information after fixing the original problem, so closing this ticket.
From: gonullu [...] bluewin.ch
Sorry for the delay. I just continued to use 2.2.9 I am still having the problem: I would like to add the following maybe it helps: 1. I have the problem in the body_string method 2. I am using SSL 3. The problem does not manifest itself on every call but *sometimes* (say 1/3 of the times) 4. When I set Timeout => 0, it seems that it works... (Timeout is 30s per default) 5. Here is the output with debug on Sending: 5 UID FETCH 3 BODY.PEEK[TEXT] Sent 31 bytes LITERAL: received literal in line * 1 FETCH (UID 3 BODY[TEXT] of length 310; attempting to retrieve from the 0 bytes in: <END_OF_iBuffer> Received ret=310 and buffer = In this section, the Fourier technique used in section 1 is expanced to the 2-dimensional grid. This method sets up an integral for this resistance between any two nodes, and a solution is found for the resistance across the diagonal of a single square (between nodes (0,0) and (1,1) in Figure 2. <END> while processing LITERAL ERROR: Tag 5: Timeout after 30 seconds waiting for data from server ERROR: Timeout after 30 seconds during read from server ERROR: Unable to parse server response from 5 UID FETCH 3 BODY.PEEK[TEXT] Could not retrieve body at imap-bug.pl line 260. Thanks in advance On Mon Apr 28 03:27:54 2008, MARKOV wrote: Show quoted text
> Didn't get additional information after fixing the original problem, so > closing this ticket.
Subject: Re: [rt.cpan.org #31655] get_header
Date: Sat, 17 May 2008 00:21:26 +0200
To: Gonullu via RT <bug-Mail-IMAPClient [...] rt.cpan.org>
From: Mark Overmeer <solutions [...] overmeer.net>
* Gonullu via RT (bug-Mail-IMAPClient@rt.cpan.org) [080515 08:23]: Show quoted text
> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=31655 > > > Sorry for the delay. I just continued to use 2.2.9 > > I am still having the problem: > I would like to add the following maybe it helps:
You have no idea how difficult debugging without access is... It's close to impossible to solve this, this way. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
From: gonullu [...] bluewin.ch
On Fri May 16 18:22:01 2008, solutions@overmeer.net wrote: Show quoted text
> > You have no idea how difficult debugging without access is... It's > close to impossible to solve this, this way.
Thanks for your help so far. I understand. It is not possible for me to have you access the server. I have the following findings: in sub _read_line (after the until at the beginning) the first control of timeout is relying on $self->{_select}->can_read returning a socket which in my case (IO::Socket::SSL) is returning undef although that the socket could be read. Replacing this with as it is done in another place later: my $rvec = 0; vec($rvec, fileno($self->Socket), 1) = 1; unless(CORE::select($rvec, undef, $rvec, $timeout)) { $self->LastError("Tag $transno: Timeout waiting for " . "literal data from server"); return undef; } which should have the same effect works then okay. I think it was already a problem in 2.2.9, but as the default value of timeout was not set per default (it is 30 sec now), this code was not working at all Regards,
Subject: Re: [rt.cpan.org #31655] get_header
Date: Fri, 23 May 2008 09:31:44 +0200
To: Gonullu via RT <bug-Mail-IMAPClient [...] rt.cpan.org>
From: Mark Overmeer <mark [...] overmeer.net>
* Gonullu via RT (bug-Mail-IMAPClient@rt.cpan.org) [080522 15:53]: Show quoted text
> I have the following findings: > > in sub _read_line (after the until at the beginning) the first control > of timeout is relying on $self->{_select}->can_read returning a socket > which in my case (IO::Socket::SSL) is returning undef although that the > socket could be read. Replacing this with as it is done in another place > later:
So, you mean: (around line 1300) until(@$oBuffer # there's stuff in output buffer: && $oBuffer->[-1][TYPE] eq 'OUTPUT' # that thing is an output line: && $oBuffer->[-1][DATA] =~ /\r?\n$/ # the last thing there has cr-lf: && !length $iBuffer # and the input buffer has been MT'ed: ) { my $transno = $self->Transaction; if($timeout) - { my @ready = $self->{_select}->can_read($timeout); - unless(@ready) + { my $rvec = 0; + vec($rvec, fileno($self->Socket), 1) = 1; + unless(CORE::select($rvec, undef, $rvec, $timeout)) { $self->LastError("Tag $transno: Timeout after $timeout seconds" . " waiting for data from server"); Internally, the can_read() does sub can_read { my $vec = shift; my $timeout = shift; my $r = $vec->[VEC_BITS]; defined($r) && (select($r,undef,undef,$timeout) > 0) ? handles($vec, $r) : (); } Which probably all you do, is adding the error bits? Do you get an error from the lower layers of SSL, for instance something like "connection not established (yet)" ? Just an idea. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
From: gonullu [...] bluewin.ch
On Fri May 23 03:32:13 2008, Mark@Overmeer.net wrote: Show quoted text
> So, you mean: (around line 1300) > > until(@$oBuffer # there's stuff in output buffer: > && $oBuffer->[-1][TYPE] eq 'OUTPUT' # that thing is an output > line: > && $oBuffer->[-1][DATA] =~ /\r?\n$/ # the last thing there has > cr-lf: > && !length $iBuffer # and the input buffer has > been MT'ed: ) > { my $transno = $self->Transaction; > > if($timeout) > - { my @ready = $self->{_select}->can_read($timeout); > - unless(@ready) > + { my $rvec = 0; > + vec($rvec, fileno($self->Socket), 1) = 1; > + unless(CORE::select($rvec, undef, $rvec, $timeout)) > { $self->LastError("Tag $transno: Timeout after $timeout > seconds" > . " waiting for data from server"); > > Internally, the can_read() does > > sub can_read > { > my $vec = shift; > my $timeout = shift; > my $r = $vec->[VEC_BITS]; > > defined($r) && (select($r,undef,undef,$timeout) > 0) > ? handles($vec, $r) > : (); > } > > Which probably all you do, is adding the error bits? > Do you get an error from the lower layers of SSL, for instance > something > like "connection not established (yet)" ? Just an idea.
yes: my $rvec = 0; vec($rvec, fileno($self->Socket), 1) = 1; CORE::select($rvec, undef, undef, $timeout) worked too the only difference is the initiation of $rvec. Initiating as in (per documentation the required way to initiate a bit vector): $rvec = ''; blocks and times out. Please not that this is used ($rvec =0), later in code around line 1336. It seems that this issue is not related to Mail::IMAPClient but appreciate the help anyway...
Subject: Re: [rt.cpan.org #31655] get_header
Date: Fri, 23 May 2008 17:06:56 +0200
To: Gonullu via RT <bug-Mail-IMAPClient [...] rt.cpan.org>
From: Mark Overmeer <solutions [...] overmeer.net>
* Gonullu via RT (bug-Mail-IMAPClient@rt.cpan.org) [080523 14:11]: Show quoted text
> $rvec = ''; > blocks and times out. Please not that this is used ($rvec =0), later in > code around line 1336. It seems that this issue is not related to > Mail::IMAPClient but appreciate the help anyway...
Of course that times-out. You are using SSL. Are you passing the SSL socket with RawSocket option? I suspect that your IO::Select object is not initialized correctly... See the related parts in the man-page. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
From: gonullu [...] bluewin.ch
On Fri May 23 13:37:35 2008, solutions@overmeer.net wrote: Show quoted text
> * Gonullu via RT (bug-Mail-IMAPClient@rt.cpan.org) [080523 14:11]:
> > $rvec = ''; > > blocks and times out. Please not that this is used ($rvec =0), later in > > code around line 1336. It seems that this issue is not related to > > Mail::IMAPClient but appreciate the help anyway...
> > Of course that times-out. > You are using SSL. Are you passing the SSL socket with RawSocket > option? I suspect that your IO::Select object is not initialized > correctly... See the related parts in the man-page.
Why should it ? No but with Socket. The documentation don't say that RawSocket is the only way to do SSL. Have I misunderstood?? This is how I am using it: my $ssl= IO::Socket::SSL->new("myserver.ch:993"); die ("Error connecting - $@") unless defined $ssl; my $imap = Mail::IMAPClient->new( User => $user, Password => $password, Debug => 1, Peek => 1, Socket => $ssl, Timeout => 60 ) or die("Could not connect to server"); As I have said, setting Timeout to zero my program than works. With 2.2.9 I was explicitly calling ->State etc... (which what I have to use with RawSocket I assume) Regards,
Subject: Re: [rt.cpan.org #31655] get_header
Date: Mon, 2 Jun 2008 10:28:55 +0200
To: Gonullu via RT <bug-Mail-IMAPClient [...] rt.cpan.org>
From: Mark Overmeer <solutions [...] overmeer.net>
* Gonullu via RT (bug-Mail-IMAPClient@rt.cpan.org) [080526 07:57]: Show quoted text
> my $imap = Mail::IMAPClient->new( > User => $user, > Password => $password, > Debug => 1, > Peek => 1, > Socket => $ssl, > Timeout => 60 > ) or die("Could not connect to server"); > > As I have said, setting Timeout to zero my program than works. > With 2.2.9 I was explicitly calling ->State etc... (which what I have to > use with RawSocket I assume)
I am now quite sure that the problem is that the lower layers of your socket implementation try to send you a message that something is happening, which is not a client-side timeout. Therefore, there are no readable filehandles returned. Your "fix" is working by accident. The filehandle of the complaining socket will be returned because you listen to the exception handles as well. But then the rest of the function continues accessing it, not handling the exception. So: the real fix must understand the reason for the exception or you should find the cause of the exception in your system. Your current patch may break systems of other users, which prefer to be informed about problem instead of ignoring them. For further investigation, see system man-pages feof/ferror and Perl function eof(). -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
if you are not investigating the problem any further, I cannot help you. So, unless there is some contuation I will close the ticket.
As you are unwilling to help me any further, I close the ticket.