Hi Norman,
I just made the following tests:
- Fresh checkout from trunk and mvn package (some new dependencies were
downloaded such as jsieve, mailet-sdk,...) => same problem on a local
deployment with thunderbird : it hangs when mailbox is empty.
- I after defined my production account on evolution
(http://www.gnome.org/projects/evolution) : I didn't have the problem
anymore, but really strange, evolution downloaded some messages from
yesterday. Those messages had been deleted from my inbox via
thunderbird, but was retrieved via evolution...
- I tested with evolution the local deployment I just made : I can read
the inbox even if empty.
The problem seems to reside on the thunderbird/james conversation when
inbox is empty.
Tks,
Eric
On 03/27/2010 10:08 PM, Norman Maurer wrote:
Hi Eric,
I just tested pop3 with imail and no messages in inbox and everything
"just works". Will try to test it with thunderbird later..
Bye,
Norman
2010/3/27 Norman Maurer<nor...@apache.org>:
Hi Eric,
I will try to find out whats wrong with the pop3 inbox stuff. If you
find out anything else please feel free to just report it..
Thx,
Norman
2010/3/27 Eric Charles<eric.char...@u-mangate.com>:
Hi Norman,
Many tks for your quick answer.
I had defined in my Thunderbird 3.0.3 client (on linux) the pop3 account as
the default one.
When launching thunderbird, the connection was succefully done "Host
contacted, sending login information", saying after 1 second "Determining
which messages to index" (never saw that message before...), hanging there a
few minutes, and finally saying "connection to server ... timed out". After
that, Imap account behaved also such a way...
I also tried with latest Thundrebird 3.0.3: same result...
I have now defined the imap account as the default one, and it's working
fine even without any mail in the inbox.
However, for the pop3 account, I still have the same behaviour. Anyway, I
have a temporary workaround right now.
I will try to debug it but it may take some time to jump into the new
architecture (I hacked james 3 years ago, but now we have some new great
stuff such as jpa, activemq, jackrabbit,...).
Regarding the OOM, I saw some days ago the JAMES-981 regarding the
ConsumerTemplate.
However, the problem was still present even after you commited JAMES-981
into trunk, so I don't think the problem was coming from that.
I tried to analyse the 2GB heap dump with eclipse memory analyser, but it
failed (too much swapping, my RAM is only 1GB).
Currently, the process memory with the new trunk version I deployed today
seems stable.
I will keep posted if I still have the issue, or if finally, the memory
remains stable.
Tks a lot and keep up the excellent work,
Eric
On 01/-10/-28163 08:59 PM, Norman Maurer wrote:
Hi Eric,
thx for the feedback . Does this happens with pop3 or imap ? Or with
both? What client you use?
About the OOM Exception, chances are good that this is fixed now. I
did something bad with ConsumerTemplate in RemoteDelivery nailet,
which could lead to such problems.
Bye
Norman
2010/3/27, Eric Charles<eric.char...@u-mangate.com>:
Great Norman,
I just upgraded to the current trunk to benefit from :
- JAMES-983: common POP3/IMAP MailRepository.
- JAMES-984: activemq 5.3.1 hoping it will resolve some OutOfMemory
exceptions I had (*)
I deployed and now (configured with enableVirtualHosting=true and
JDBCDomainList), I've got the following:
- When my mailbox contains at least one mail, No problem: I can read it
without any problem.
- When my mailbox is empty, my mail client simply waits and finally give
me a timeout (closing my client and launching it again with mails in the
inbox, everything is fine again).
Can anybody else reproduce it?
Is there additional specific configuration I have to apply ?
Tks a lot,
Eric
(*) Just for information, about the OutOfMemory I had with activemq
3.5.0:
- Testing different configurations from
http://activemq.apache.org/javalangoutofmemory.html didn't help.
- Stressing a local deployment with apache-sever-postage, server was
holding the pressure during hours, however, memory was slightly but
constantly growing.
- I have a heap dump to be analyzed (still todo)
- Reading 6 memory leak bugs resolved in activemq 3.5.1.
(https://issues.apache.org/activemq/secure/ReleaseNote.jspa?projectId=10520&styleName=Html&version=12183),
I decided to try to migrate to activemq 5.3.1, and by chance, Norman
checked it in two days ago. I still have to wait a few days to see if
the OutOfMemory problem is resolved.
On 12/23/-28158 08:59 PM, Norman Maurer wrote:
Ok it seems like this works for everyone so far.. I will commit it
this weekend ..
Thanks again for all the feedback / questions.
Bye,
Norman
2010/3/26 Stefano Bagnara<apa...@bago.org>:
2010/3/24 Norman Maurer<nor...@apache.org>:
Hi all,
I want to propose some really heavy change in current JAMES trunk, and
so next version. As all of you knows we are supporting IMAP in current
development version, which ships with its own mail store backend
called MailboxManager / Mailbox. For POP3 we use MailRepository as
backend.
I think this is a no go for a number of reasons, but the major one is
that we should be able to switch between IMAP and POP3 without the
need to migrate mails. So I rewrote the POP3Server to re-use the
MailboxManager / Mailbox stuff which is used by IMAP.
I think this is a good think. I also hope MailboxManager/Mailbox API
can be improved and simplified, but using a single API is the only way
to go. Once we use only one we'll better understand how to improve it.
So if a user login via POP3 he will just see the folder called INBOX
and nothing else. With IMAP he will see all folders. Thats exactly
what dovecot and courier does ( both heavy used unix imap/pop3
servers).
A good extension would be to have a "login pattern" to read custom
folders..
e.g: I login as "username#FOLDER" with username password and this way
I get access to FOLDER instead of INBOX.
The same could be applied to the delete behaviour (something like the
"recent:" prefix hack in gmail).
Another advance is that we elimate one more dependency on storing
mails via javamail, which is not the way to go for the future ...
On the downside we will break backward-compatibility with every James
release we did before. So we will need to write a "migration" tool,
but this should not be to hard.
IMO at this point we should plainly ignore backward compatibility.
AFTER we'll have a working release we'll define a migration path (with
the help of users wanting to upgrade).
Because the change is so heavy, I dedicited to attach it to JIRA for
review and not commit it directly.
You can find it here:
https://issues.apache.org/jira/browse/JAMES-983
So what do you think ?
+1
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
