Contribution help for the Confluence connector patch

2018-10-23 Thread 白井 隆/ Shirai Takashi
Hi, there.

I've just made the patch to extend mcf-confluence-connector.
The official site says that I can create a JIRA ticket for improvements.
But I cannot access the JIRA via the firewall in our office.
Can someone create a ticket instead of me?

The patch is attached to this mail.
[Extension]
o Support the page type 'blogpost' as well as 'page'. (*1)
o Include the Japanese message catalog.
[Bug Fix]
o Ugly message when the 'Port' value is invalid.
o Ugly message of 'Process Attachments' in 'View a Job'.
o Some null pointer exceptions.

(*1)
Confluence has 2 different types of page.
The current connector can only find 'page' typed pages.
This extension can find both of them selectively.

Thanks.


Nintendo, Co., Ltd.
Product Technology Dept.
Takashi SHIRAI
PHONE: +81-75-662-9600
mailto:shi...@nintendo.co.jp

apache-manifoldcf-2.11-confl-blog.patch.gz
Description: apache-manifoldcf-2.11-confl-blog.patch.gz


Re: error when running jobs

2018-10-23 Thread Gustavo Beneitez
Thanks Karl, we are going to make new crawls with that property enable and
will get back to you.

El mar., 23 oct. 2018 a las 10:09, Karl Wright ()
escribió:

> Add this to your properties.xml:
>
> 
>
> This keeps stuff in memory and dumps a lot to the log as well.
>
> I'm afraid that groveling through the logs after a failure to confirm it's
> the same kind of thing we've seen before takes many hours.  I can only
> promise to do this when I have the time.
>
> Karl
>
>
> On Tue, Oct 23, 2018 at 2:34 AM Gustavo Beneitez <
> gustavo.benei...@gmail.com> wrote:
>
>> I Karl,
>>
>> MySQL. As per config variables:
>> version  5.7.23-log
>> version comment MySQL Community Server (GPL)
>>
>> which file should I enable logging/debugging?
>>
>> Thanks!
>>
>> El lun., 22 oct. 2018 a las 21:36, Karl Wright ()
>> escribió:
>>
>>> Hi Gustavo,
>>>
>>> I have seen this error before; it is apparently due to the database
>>> failing to properly gate transactions and behave according to the
>>> concurrency model selected for a transaction.  We have a debugging setting
>>> you can configure which logs the needed information so that forensics get
>>> dumped, and when they do, it's apparent what is happening.
>>>
>>> Note well that I have never been able to make this problem appear here,
>>> so I suspect that the issue is related to network latency or some other
>>> external factor I cannot easily reproduce.
>>>
>>> Just so I know -- what database is this?  The place where we've seen
>>> this is postgresql; later versions of MySql do not seem to have an issue.
>>>
>>> Thanks,
>>> Karl
>>>
>>>
>>> On Mon, Oct 22, 2018 at 1:44 PM Gustavo Beneitez <
>>> gustavo.benei...@gmail.com> wrote:
>>>
 Hi Karl,

 lately we are facing job status problems. After a few minutes the job
 ends suddenly, always the same way:

 Error: Unexpected jobqueue status - record id 1539339908660, expecting
 active status, saw 2
 Error: Unexpected jobqueue status - record id 1539291541171, expecting
 active status, saw 2
 Error: Unexpected jobqueue status - record id 1539294182173, expecting
 active status, saw 2
 Error: Unexpected jobqueue status - record id 1539338949797, expecting
 active status, saw 2

 I did some investigations and a select to the database after the error
 appeared and BEFORE rerunning the job:

 SELECT * FROM `jobqueue` WHERE id = 1539336459053 and jobid =
 1539269973731


 it returned status = 'G'


 After the run was repeated, it finished OK  and same query returned
 status = 'C'.

 I don't understand much of the "active" workers but it seems the item
 is processed twice. Do you have an idea about what we should investigate?


 Thanks in advance!

>>>


Re: error when running jobs

2018-10-23 Thread Karl Wright
Add this to your properties.xml:



This keeps stuff in memory and dumps a lot to the log as well.

I'm afraid that groveling through the logs after a failure to confirm it's
the same kind of thing we've seen before takes many hours.  I can only
promise to do this when I have the time.

Karl


On Tue, Oct 23, 2018 at 2:34 AM Gustavo Beneitez 
wrote:

> I Karl,
>
> MySQL. As per config variables:
> version  5.7.23-log
> version comment MySQL Community Server (GPL)
>
> which file should I enable logging/debugging?
>
> Thanks!
>
> El lun., 22 oct. 2018 a las 21:36, Karl Wright ()
> escribió:
>
>> Hi Gustavo,
>>
>> I have seen this error before; it is apparently due to the database
>> failing to properly gate transactions and behave according to the
>> concurrency model selected for a transaction.  We have a debugging setting
>> you can configure which logs the needed information so that forensics get
>> dumped, and when they do, it's apparent what is happening.
>>
>> Note well that I have never been able to make this problem appear here,
>> so I suspect that the issue is related to network latency or some other
>> external factor I cannot easily reproduce.
>>
>> Just so I know -- what database is this?  The place where we've seen this
>> is postgresql; later versions of MySql do not seem to have an issue.
>>
>> Thanks,
>> Karl
>>
>>
>> On Mon, Oct 22, 2018 at 1:44 PM Gustavo Beneitez <
>> gustavo.benei...@gmail.com> wrote:
>>
>>> Hi Karl,
>>>
>>> lately we are facing job status problems. After a few minutes the job
>>> ends suddenly, always the same way:
>>>
>>> Error: Unexpected jobqueue status - record id 1539339908660, expecting
>>> active status, saw 2
>>> Error: Unexpected jobqueue status - record id 1539291541171, expecting
>>> active status, saw 2
>>> Error: Unexpected jobqueue status - record id 1539294182173, expecting
>>> active status, saw 2
>>> Error: Unexpected jobqueue status - record id 1539338949797, expecting
>>> active status, saw 2
>>>
>>> I did some investigations and a select to the database after the error
>>> appeared and BEFORE rerunning the job:
>>>
>>> SELECT * FROM `jobqueue` WHERE id = 1539336459053 and jobid =
>>> 1539269973731
>>>
>>>
>>> it returned status = 'G'
>>>
>>>
>>> After the run was repeated, it finished OK  and same query returned
>>> status = 'C'.
>>>
>>> I don't understand much of the "active" workers but it seems the item is
>>> processed twice. Do you have an idea about what we should investigate?
>>>
>>>
>>> Thanks in advance!
>>>
>>


Re: error when running jobs

2018-10-23 Thread Gustavo Beneitez
I Karl,

MySQL. As per config variables:
version  5.7.23-log
version comment MySQL Community Server (GPL)

which file should I enable logging/debugging?

Thanks!

El lun., 22 oct. 2018 a las 21:36, Karl Wright ()
escribió:

> Hi Gustavo,
>
> I have seen this error before; it is apparently due to the database
> failing to properly gate transactions and behave according to the
> concurrency model selected for a transaction.  We have a debugging setting
> you can configure which logs the needed information so that forensics get
> dumped, and when they do, it's apparent what is happening.
>
> Note well that I have never been able to make this problem appear here, so
> I suspect that the issue is related to network latency or some other
> external factor I cannot easily reproduce.
>
> Just so I know -- what database is this?  The place where we've seen this
> is postgresql; later versions of MySql do not seem to have an issue.
>
> Thanks,
> Karl
>
>
> On Mon, Oct 22, 2018 at 1:44 PM Gustavo Beneitez <
> gustavo.benei...@gmail.com> wrote:
>
>> Hi Karl,
>>
>> lately we are facing job status problems. After a few minutes the job
>> ends suddenly, always the same way:
>>
>> Error: Unexpected jobqueue status - record id 1539339908660, expecting
>> active status, saw 2
>> Error: Unexpected jobqueue status - record id 1539291541171, expecting
>> active status, saw 2
>> Error: Unexpected jobqueue status - record id 1539294182173, expecting
>> active status, saw 2
>> Error: Unexpected jobqueue status - record id 1539338949797, expecting
>> active status, saw 2
>>
>> I did some investigations and a select to the database after the error
>> appeared and BEFORE rerunning the job:
>>
>> SELECT * FROM `jobqueue` WHERE id = 1539336459053 and jobid =
>> 1539269973731
>>
>>
>> it returned status = 'G'
>>
>>
>> After the run was repeated, it finished OK  and same query returned
>> status = 'C'.
>>
>> I don't understand much of the "active" workers but it seems the item is
>> processed twice. Do you have an idea about what we should investigate?
>>
>>
>> Thanks in advance!
>>
>