Ok I got the patch and agree this is now going in the good direction.
This errorhandling should be kept very simple, remember that if an
error happens there they will be swallowed and hidden - some logging
is all I asked for.
Also we're not always capable of telling which exact operation failed;
th
Hi Amin,
I couldn't find your patch, could you attach it to the issue?
I don't think this mail list accepts attachments.
Cheers,
Sanne
2010/3/25 Amin Mohammed-Coleman :
> Hi
>
> I have created a patch based on Emmanuel's thoughts. I haven't applied the
> usage of the ErrorHandler yet as I wante
Hi
I have created a patch based on Emmanuel's thoughts. I haven't applied the
usage of the ErrorHandler yet as I wanted to get an idea on whether it was the
right path. I have mentioned this before but I'm not sure how to capture the
operation at fault followed by subsequent failures. I'd ap
On 23 mars 2010, at 19:01, Amin Mohammed-Coleman wrote:
> Thanks for your input. I've just had the eureka moment which I was struggling
> with. Please give me a day or two and create a patch that conforms to your
> thoughts
Glad to be a eureka moment generator ;)
__
Hi Emmanuel
Thanks for your input. I've just had the eureka moment which I was
struggling with. Please give me a day or two and create a patch that
conforms to your thoughts
Thanks for your patience!
Cheers
Amin
Sent from my iPhone
On 22 Mar 2010, at 17:43, Emmanuel Bernard
wrote:
> H
Hello,
Sorry, I've been a bit out of this particular problem for a long time, so if I
ask already answers questions forgive me.
Thanks for all the work, sorry it take so long on our part for each review :(
Here are some comments on the patch:
- your code rules don't seem to match Hibernate's in
Hi
Please find updated patch with the removal of the enum singleton.
Thanks
Amin
On 17 Mar 2010, at 12:58, Sanne Grinovero wrote:
> Hi Amin,
> thanks for the update, see some thoughts:
>
> 2010/3/16 Amin Mohammed-Coleman :
>> Hi folks,
>>
>> I've removed the enum singleton and created a clas
Hi Amin,
thanks for the update, see some thoughts:
2010/3/16 Amin Mohammed-Coleman :
> Hi folks,
>
> I've removed the enum singleton and created a class(BackendExceptionHandler)
> which has 2 methods:
>
>
> public Thread.UncaughtExceptionHandler
> getUncaughtExceptionHandler(SearchConfiguration
Hi folks,
I've removed the enum singleton and created a class(BackendExceptionHandler)
which has 2 methods:
public Thread.UncaughtExceptionHandler
getUncaughtExceptionHandler(SearchConfiguration configuration);
public boolean logException(SearchConfiguration configuration)
The issue that I
yes that is it;
There has been some talking about other strategies as well on previous
mails, like jms, but that lead to nowhere so yes I'm suggesting now to
forget about other default implementations at the moment and proceed
as you just said.
2010/3/9 Emmanuel Bernard :
> I thought the goal was
Hi Amin,
thanks to you, and sorry for the delay.
I've committed a first step that you obviously need - indipendently
from how we manage it - please see:
http://fisheye.jboss.org/changelog/Hibernate/search?cs=18939
So this should simplify your patch having impact only on the exception
handling stra
Hi Sanne
You are right and Im not happy with the enum class. I wanted to have a
single configuration that was available on the creation of the search
factory and re use when required. I'll take a look at changing that
with a better solution.
Cheers
Amin
Sent from my iPhone
On 9 Mar 20
I thought the goal was to have something pluggable with two default impls
(exception and log). If that's what you are describing I am ok, if not, then I
don't understand ;)
On 9 mars 2010, at 12:08, Sanne Grinovero wrote:
> Emmanuel are you ok with this if we either log or rethrow the
> excepti
Hello Amin,
Have you had a chance to work on this?
Emmanuel
On 9 janv. 2010, at 15:59, Amin Mohammed-Coleman wrote:
> Hi Sanne
>
> Thanks for the advice! I'll take a look at it.
>
>
> Cheers
> Amin
>
> On Sat, Jan 9, 2010 at 1:34 PM, Sanne Grinovero
> wrote:
>
>> Hi Amin,
>> I've been looki
I forgot about this behavior, I thought you were raising an exception during
the sync mode (even if run with parallel processes). That definitely looks like
the right thing to do.
So an exception strategy should:
- know if it's a synchronized call or not
- know the list of operations that are
Hi Amin,
I'm looking at way too much stuff, it's very welcome that you look at
it. I didn't assign it to me as I've too much other stuff already
assigned.
Sometimes I do some experiments locally but I do only commit if it's
looking good, most of the time I need to bring something up here for
feedba
Hi Sanne
Thanks for the advice! I'll take a look at it.
Cheers
Amin
On Sat, Jan 9, 2010 at 1:34 PM, Sanne Grinovero
wrote:
> Hi Amin,
> I've been looking a bit in this, but didn't take any action as we
> didn't discuss any strategy, so glad you join in propose something.
> I didn't think of jm
Hi Amin,
I've been looking a bit in this, but didn't take any action as we
didn't discuss any strategy, so glad you join in propose something.
I didn't think of jms, it's ok we provide some way for the end user to
override whatever we provide, but I think we should just provide
the basic stuff: log
Hi All
Emmanuel asked me to look at this issue (HSearch 421) where exceptions
happening in backend process which are going unnoticed. I was wondering if
I could get some advice/thoughts on how to tackle the problem.The issue
mentioned providing the user the option to decide how to handle exce
19 matches
Mail list logo
