[Trac-dev] trac.edgewall.org in trouble ?

It seems t.e.o. is in trouble:

eblot <at> oulme:~$ ping trac.edgewall.org
PING www.edgewall.org (88.198.140.129): 56 data bytes
^C
--- www.edgewall.org ping statistics ---
23 packets transmitted, 0 packets received, 100% packet loss

eblot <at> qnap:~$ ping trac.edgewall.org
PING www.edgewall.org (88.198.140.129) 56(84) bytes of data.
^C
--- www.edgewall.org ping statistics ---
92 packets transmitted, 0 received, 100% packet loss, time 91012ms

(ping clients are connected on two distinct ISP networks)

I finally can connect to t.e.o. but it takes several seconds to render
a single page.
"login" for example takes over 30 seconds
"New ticket" takes over 1 minute

Cheers,
Manu

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en

[Trac-dev] Re: trac.edgewall.org in trouble ?

Emmanuel Blot wrote:
> It seems t.e.o. is in trouble:
>
> eblot <at> oulme:~$ ping trac.edgewall.org
> PING www.edgewall.org (88.198.140.129): 56 data bytes
> ^C
> --- www.edgewall.org ping statistics ---
> 23 packets transmitted, 0 packets received, 100% packet loss
> ...
>   

Yes, it's not the first time. Besides Jonas, Christopher has also access 
on t.e.o, and the other day he was able to verify that the issue was due 
to an excessive number of IDLE in transaction connections (#8443).

This is eventually fixable, but this raises the more general question of 
t.e.o.'s maintenance. Both Jonas and Christopher are not very active 
lately, and Christopher suggested that the "Trac community" should 
eventually takes over the maintenance of Trac's Trac, in the spirit of 
the recent Trac-Hacks move. I'm not sure he was referring to t.e.o 
alone, or the whole of edgewall.org, or even if a domain change was in 
order. In any case, a more responsive hosting for Trac could certainly 
help. So while waiting for the return of Jonas, we should eventually be 
ready to propose alternatives to him, and then let him decide on the 
further steps to take.

I personally can't offer any hosting solution, but I'd be interested to 
have at least some access to the future server, in order to help 
troubleshoot whatever problem might come up.

[Trac-dev] Re: trac.edgewall.org in trouble ?

> It seems t.e.o. is in trouble:
>

Definitely overloaded:

Trac detected an internal error:
TimeoutError: Unable to get database connection within 20 seconds

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: trac.edgewall.org in trouble ?

> This is eventually fixable, but this raises the more general question of
> t.e.o.'s maintenance.

I understand... no problem.
It would be great that you could get admin access to t.e.o. knowing
that you're the main contributor to the project.

[OT] I've managed to destroy the trac.ini file, so I had an important
bug to file in 

Cheers,
Manu

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: trac.edgewall.org in trouble ?

On 01/09/09 2:15 AM, Christian Boos wrote:
>

> I personally can't offer any hosting solution, but I'd be interested to
> have at least some access to the future server, in order to help
> troubleshoot whatever problem might come up.

We (ActiveState) would be happy to provide hosting that the trac 
community can manage and have full access to.  We do it for a couple 
other communities currently, including the primary systems for TCL.

Shane Caraveo

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: trac.edgewall.org in trouble ?

On Sep 1, 11:15 am, Christian Boos <cb...@neuf.fr> wrote:
> Emmanuel Blot wrote:
> > It seems t.e.o. is in trouble:
>
> > eblot <at> oulme:~$ ping trac.edgewall.org
> > PINGwww.edgewall.org(88.198.140.129): 56 data bytes
> > ^C
> > ---www.edgewall.orgping statistics ---
> > 23 packets transmitted, 0 packets received, 100% packet loss
> > ...
>
> Yes, it's not the first time. Besides Jonas, Christopher has also access
> on t.e.o, and the other day he was able to verify that the issue was due
> to an excessive number of IDLE in transaction connections (#8443).

As discussed on IRC yesterday Christian, we looked at Bitten as the
potential source for this - more specifically the graphs that render
test results and coverage data from the dawn of time (all report lines
for all platforms for all revisions in the configuration). Or, more to
the point; "don't render" as graphs take forever to appear - if at
all.

Chris appeared today, and I got him to disable the graph components
for now. We'll see how/if that improves things short term. He was also
going to see about getting a fresh db dump so that we can research
this issue.

:::simon

[Trac-dev] Re: trac.edgewall.org in trouble ?

osimons wrote:
> Chris appeared today, and I got him to disable the graph components
> for now. We'll see how/if that improves things short term.

Now that the graphs have disappeared, how about extending the build
table to fill the whole page width?

-- Remy

[Trac] WebAdmin

[Trac-dev] About your mails on Trac-dev

Hello,

I think I've already replied to one of your cross-posts on trac-dev, on 
the 8/22/2009:
----

Note to the (other) mailing list moderators: such mails should be 
filtered out of Trac-dev.
When I see similar misguided mails, I usually send a private mail 
advising to ask on Trac-users, not to cross-post, etc.

----

I thought this should have been enough to let you know that such a behavior was not desired, but apparently
that was not enough.

Please in the future restrict your posts to Trac-users, and avoid HTML mail as well, by the way.

-- Christian Boos (Trac-dev moderator)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Debugger for Trac

Hello,

I've setup Trac environment as described on TracDev/
DevelopmentEnvironmentSetup pages (valuable info indeed), but now I
need to get to the source of mysterious Error
(Error when calling the metaclass bases function() argument 1 must be
code, not str)

Logging console in DEBUG mode didn't provide enough info to pinpoint
the problem, so I've tried PDB to go step-by-step until the offending
line, but PDB has one big flaw - it doesn't understand threads. When I
set breakpoint at the code that is executed in thread PDB skips it.

So, the question is - how do you debug Trac? I can go into sources and
set breakpoints with pdb.set_trace() calls, but it is not as
convenient as with pure PDB itself. Maybe there are other useful tools
or I just do not know something?

Thanks.
--
anatoly y.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---