i've been observing sporadic exceptions in my fetchmail->sieve->IMAP.
the exceptions are thrown even though the mail filtering works fine
when the script is run offline. the majority of these exceptions have
been fixed by adding read/write locking to the torque mailbox. so,
i've been able to focus
On 8/6/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
http://svn.apache.org/repos/asf/james/jsieve/trunk/src/main/java/org/apache/jsieve/commands/CommandStateManager.java.
> i think that it may better to eliminate the static per-thread
> singleton manipulation methods and replace them with a
Robert Burrell Donkin ha scritto:
> i've been observing sporadic exceptions in my fetchmail->sieve->IMAP.
> the exceptions are thrown even though the mail filtering works fine
> when the script is run offline. the majority of these exceptions have
> been fixed by adding read/write locking to the to
What types of exceptions do you get? NPE?
if it wasn't for a ThreadLocal, I'd say that this method's init is not
atomic, if fieldInstance is NULL:
static protected void setInstance(CommandStateManager conditionManager)
{
if (null == fieldInstance)
fieldInstance = new Th
Bernd Fondermann ha scritto:
> What types of exceptions do you get? NPE?
>
> if it wasn't for a ThreadLocal, I'd say that this method's init is not
> atomic, if fieldInstance is NULL:
>
>static protected void setInstance(CommandStateManager conditionManager)
> {
> if (null == fiel
I agree to a previous post that the whole construct is very hard to
get and a little bit overengineered. +1 to try and remove ThreadLocal.
+1 to at least use a subclass. +1 to reduce complexity by inlining
methods or other appropriate refactorings.
Bernd
On 8/9/07, Stefano Bagnara <[EMAIL PROTE
Stefano Bagnara ha scritto:
> /**
> * Method execute executes a Block within the context of a new
> ConditionManager.
> * @param mail
> * @param block
> * @return Object
> * @throws SieveException
> */
> protected Object execute(MailAdapter mail, Block block) throws
> SieveException {
> //
On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Bernd Fondermann ha scritto:
> > What types of exceptions do you get? NPE?
mostly ones related to the state machine. it's the same script and it
filters the mail fine in a single threaded test environment but
occasionally fails when run from
On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Stefano Bagnara ha scritto:
> > /**
> > * Method execute executes a Block within the context of a new
> > ConditionManager.
> > * @param mail
> > * @param block
> > * @return Object
> > * @throws SieveException
> > */
> > protected Objec
Robert Burrell Donkin ha scritto:
> On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> I don't get how it works. ConditionManager.resetInstance will set the
>> static thread local fieldInstance to null: doesn't this invalidate also
>> instances of every other thread using the ConditionManager
Robert Burrell Donkin ha scritto:
> On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> Stefano Bagnara ha scritto:
>>> /**
>>> * Method execute executes a Block within the context of a new
>>> ConditionManager.
>>> * @param mail
>>> * @param block
>>> * @return Object
>>> * @throws Sieve
On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin ha scritto:
> > On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> >> Shouldn't
> >> resetInstance simply remove the conditionManager from the fieldInstance
> >> ThreadLocal using a fieldInstance.set(null) ?
> >
On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin ha scritto:
> > On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> >> Stefano Bagnara ha scritto:
> >>> /**
> >>> * Method execute executes a Block within the context of a new
> >>> ConditionManager.
> >>> * @param
On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Bernd Fondermann ha scritto:
> > What types of exceptions do you get? NPE?
> >
> > if it wasn't for a ThreadLocal, I'd say that this method's init is not
> > atomic, if fieldInstance is NULL:
> >
> >static protected void setInstance(Comman
On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Stefano Bagnara ha scritto:
> > /**
> > * Method execute executes a Block within the context of a new
> > ConditionManager.
> > * @param mail
> > * @param block
> > * @return Object
> > * @throws SieveException
> > */
> > protected Objec
Robert Burrell Donkin ha scritto:
> On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> Bernd Fondermann ha scritto:
>>> What types of exceptions do you get? NPE?
>>>
>>> if it wasn't for a ThreadLocal, I'd say that this method's init is not
>>> atomic, if fieldInstance is NULL:
>>>
>>>sta
On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin ha scritto:
> > On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> >> Forgot to say that if this is the case it should be pretty easy to
> >> create a test case to prove it.
> >
> > how would you approach the mana
Robert Burrell Donkin ha scritto:
> On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> Furthermore, I see that this block is allowed to send SieveException.
>> Maybe the setInstance(oldManager) should be called in a finally to make
>> sure we place back the status to the right one (well, mayb
Robert Burrell Donkin ha scritto:
> On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> So, was this simply a test for us?? You already found that.. was it a
>> secret?? :-P
>
> i only found one problem: you and bernd found another three. i'd much
> rather do a comprehensive job than quickly
On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin ha scritto:
> > On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > https://issues.apache.org/jira/browse/JSIEVE-10 suggests removing the
> > singletons and injecting the dependency instead. not sure how much
> > wo
On 8/9/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > Robert Burrell Donkin ha scritto:
> > > On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > > https://issues.apache.org/jira/browse/JSIEVE-10 suggests removing the
> > > sin
Fondermann [mailto:[EMAIL PROTECTED]
> Sent: 09 August 2007 23:24
> To: James Developers List
> Subject: Re: [JSieve] Sporadic Mysterious Exceptions
>
>
> On 8/9/07, Robert Burrell Donkin
> <[EMAIL PROTECTED]> wrote:
> > On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED
Steve Brewin wrote:
> The intent is that in
> deployments
> where synchronization is required, you subclass to add
> synchronization,
...should have read...
> The intent is that in
> deployments
> where synchronization is required, you subclass OR WRAP to add
> synchronization,
I also recommend
Steve Brewin ha scritto:
> I also recommend Quinta das Seten Costas, an excellent red wine best
> consumed apres email!
+1, even if you don't have fresh emails ;-)
Stefano
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additio
Steve Brewin ha scritto:
> As to the synchronization issues, the lazy initialization pattern (that
> Stefano so loves) is not an accident. The intent is that in deployments
> where synchronization is required, you subclass to add synchronization,
> normally just on the getter method. In single thre
On 8/10/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
> Hi Guys
hi steve
> +1 to using DI, -1 to static initializers for anything other than types
> without dependencies, for example, primitives and Strings.
in general, i agree
in this case, though, the possibility of a 0.2 release needs to be co
> Hi Steve,
>
> I have no problem with lazy initialization, I have problems with too
> many granular methods not used by anyone and creating problems in
> reading the code.
+1
The architectonical approach described by Steve - while worthwhile on
its own - is not in use currently.
Instead, there ar
27 matches
Mail list logo
