On Friday, December 25, 2015 at 1:54:43 AM UTC-8, Torge Riedel wrote: > > Am 24.12.2015 um 02:13 schrieb RjOllos: > > > > > > On Wednesday, December 23, 2015 at 9:39:06 AM UTC-8, RjOllos wrote: > > > > > > > > On Wednesday, December 23, 2015 at 3:42:43 AM UTC-8, Torge Riedel > wrote: > > > > Am 22.12.2015 um 19:07 schrieb RjOllos: > > > > > > > > > On Monday, December 21, 2015 at 6:37:36 AM UTC-8, Riedel, > Torge wrote: > > > > > > Hi, > > > > > > today I faced a problem with TracTicketChangeLogPlugin: > > > > > > After analyzing the code and adding some debug outputs I > can say the following: > > > > > > 1.Ticket number is #39 > > > > > > 2.The db-query gives 46 revisions where LIKE '%#39%' > matches (which is much more than really necessary, since revisions > referencing tickets e.g. #391 are returned too) > > > > > > 3.The reg-ex matching hangs when there is a long commit > message (sorry I cannot post it here since it contains confidential > information) > > > > > > a.The message contains Unicode chars, but changing the > encoding of the message to match to ‘ascii’ with ‘ignore’ option does not > help > > > > > > b.The message has 41 lines (it’s a message of a tag > commit in subversion, where we list all tickets solved in this version, the > format is: > > > Version vX.Y > > > ---- > > > * #n1 Fixed this > > > * #n2 Fixed that > > > … and so on > > > > > > c.The whole message has a count of 3073 chars > > > > > > The log pattern is configured to: > > > > > > [ticketlog] > > > > > > log_pattern = (\n|.)*#%s($|\D(\n|.)*) > > > > > > Which gives very good results. In general. Since I’m not > a python developer, help is appreciated. > > > > > > Regards > > > > > > Torge > > > > > > > > > You could try the patterns mentioned in this ticket: > > > https://trac-hacks.org/ticket/7884 < > https://trac-hacks.org/ticket/7884> > > > See also: > > > https://trac-hacks.org/ticket/12436 < > https://trac-hacks.org/ticket/12436> > > > > > > I suspect the issue you describe as "hanging on a long commit > message" is due to searching every log message on every request. I hope to > fix that in #11821, but I don't have a timetable yet for implementing the > changes. > > > https://trac-hacks.org/ticket/11821 < > https://trac-hacks.org/ticket/11821> > > > > > > - Ryan > > > > > > -- > > > You received this message because you are subscribed to the > Google Groups "Trac Users" group. > > > To unsubscribe from this group and stop receiving emails from > it, send an email to [email protected] <mailto: > trac-users%[email protected]> <mailto: > [email protected] <mailto: > trac-users%[email protected]>>. > > > To post to this group, send email to > [email protected] <mailto:[email protected]> <mailto: > [email protected] <mailto:[email protected]>>. > > > Visit this group at > https://groups.google.com/group/trac-users < > https://groups.google.com/group/trac-users>. > > > For more options, visit https://groups.google.com/d/optout < > https://groups.google.com/d/optout>. > > > > Hi Ryan, > > > > well my issue is not really due to the number of log messages. > There is a pre-selection of the log messages by a SELECT-query using a > "LIKE" on the message. I added debug prints in the plug-in, activated the > log to the file in the trac instance and called "tail -f trac.log" to see > what happens when visiting the ticket page. And I see that the long message > (it is the 11th of 46 log messages to check) is passed to the > re.match()-method and then nothing more is logged. Apache is no more > responding to other requests. > > Maybe this is a bug in python regex code? Can you help me to > check this? I'm not a python developer so I need help. Everything more > complex than adding debug prints is out of my possibilities! ;-) I think of > a small python script where I can pass the ticket id ("python test.py 39") > executed in the directory where the trac.db is located. This script is > running the code snippet of the plug-in with log of debug prints. So I can > check whether this is a python issue and maybe it's possible for me to > reduce it to non-confidential data and open an issue. > > > > Thanks > > Torge > > > > > > #11821 also proposes to improve the regex. I think we should only > extract tokens like "Refs #1", rather than just "#1", like > CommitTicketUpdater does. Approximately how many tickets are referenced in > the log message? > > > > - Ryan > > > > > > Are your ticket references of the form #\d+, or do you prefix the ticket > ID references in your log messages #\d+ with a CommitTicketUpdater command? > > http://trac.edgewall.org/wiki/CommitTicketUpdater#Configure > > > > - Ryan > > Well, it's a tag commit where we always list all fixed issues. The message > has 41 lines, two lines for version and horizontal delimiter -> 39 ticket > references. Our format is always like this: > > Version vX.Y > ---- > * #n1 Fixed this > * #n2 Fixed that > ... > > Where "..." stands for more list points. We do not use > CommitTicketUpdater. > Again: It looks to me, that regex engine of python is hanging when trying > to find a match for (\n|.)*#39($|\D(\n|.)*) in the long message. I like to > verify this using a small python script, but I'm not a python developer. > > Improving the regex is only one solution and - in my case - not suitable > if the reference format changes. This would skip all existing commits ins > svn, where the new format is not used. > > BTW: Merry christmas! > > Regards > Torge >
Thank you for the additional details. I added a note to #12621 to investigate. I'll try to make those changes backward compatible. I think it would be best to continue the discussion in ticket #12621, so you can receive notifications of changesets. - Ryan -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
