Page MenuHomePhabricator

Multithreading does not seem to work on uwsgi in toollabs
Closed, ResolvedPublic

Description

Even after enabling threading in uwsgi.ini, the log says enabled but it isn't.

Event Timeline

Mjbmr created this task.Feb 28 2015, 4:32 AM
Mjbmr raised the priority of this task from to Needs Triage.
Mjbmr updated the task description. (Show Details)
Mjbmr added projects: Cloud-Services, Toolforge.
Mjbmr added a subscriber: Mjbmr.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 28 2015, 4:32 AM
coren closed this task as Declined.Feb 28 2015, 7:33 PM
coren claimed this task.
coren added a subscriber: coren.

uwsgi configuration can be made by plqcing directives in ~/www/python/uwsgi.ini, including threads.

yuvipanda renamed this task from Please enable multithreading for uwsgi on labs tools. to Multithreading does not seem to work on uwsgi in toollabs.Mar 8 2015, 12:00 PM
yuvipanda reopened this task as Open.
yuvipanda triaged this task as Medium priority.
yuvipanda updated the task description. (Show Details)
yuvipanda set Security to None.
yuvipanda added a subscriber: yuvipanda.

Retitling and re-opening based on comment in T91155

@Mjbmr heya! Can you point us to the code that is having problems?

Mjbmr added a comment.Mar 8 2015, 12:07 PM

@yuvipanda you really want my code? it don't document my code, but if you're a root you can check it out on /data/project/xmlfeed/www/python/src/app.py when I run it separately using ./app.py it works great, I use a php script located at /data/project/xmlfeed/public_html/index.php to proxy it. but it's not definitely my code, I'm a pro. and I don't feel comfortable with you look at my code. but if you want go ahead a look at it.

@Mjbmr You do know that your code has to be open source to live on labs, right?

Mjbmr added a comment.EditedMar 8 2015, 12:14 PM

@yuvipanda the only way you can put a code on wmf projects is to be hosted on labs, I can't host them somewhere else, beside I know sysadmins has access to my codes and I don't care. I have limited access for others. but what's point? are you going to use my codes?! I don't think that the issue here. we're talking about threads on uwsgi not anything else.

Mjbmr added a comment.Mar 8 2015, 12:18 PM

@yuvipanda there are passwords being stored on labs, you can't count any privacy as open source.

Alright, so two unrelated issues here.

  1. Code on labs has to be open source. It has to have a OSI compatible license (https://wikimediafoundation.org/wiki/Terms_of_Use). I just wanted to make sure yours is.
  2. uwsgi reports threads are enabled, and so I suspect it is enabled. I will try out a simple test app in a few days time to see if the bug is in uwsgi, and if so report it upstream / tweak config.

@yuvipanda there are passwords being stored on labs, you can't count any privacy as open source.

Sure, but your code itself can be Open Source and available with an OSI License. For example, all of Wikimedia's code is open source, and that does not mean our passwords are out in the open.

Mjbmr added a comment.Mar 8 2015, 12:24 PM

@yuvipanda I count my codes as privacy, unless you want me stop helping these projects. are you going to debug and fix uwsgi? or you just want keep talking about owning my codes.

As an admin on toollabs I think it is my duty to investigate non open source applications on toollabs. I'll start an internal thread amongst other admins and figure out how to deal with this situation.

I'll also investigate the uwsgi issue when I have time.

Mjbmr closed this task as Declined.Mar 8 2015, 12:27 PM
yuvipanda reopened this task as Open.Mar 8 2015, 12:28 PM

Re-opening. Why was this closed?

Mjbmr closed this task as Declined.Mar 8 2015, 12:30 PM

I removed my codes.

I'm not going to wheel war on the status of this bug.

I'll take a look next week on the actual bug.

Aklapper reopened this task as Open.Mar 8 2015, 2:11 PM

The actual issue reported in this ticket looks valid so far as per T91156#1098922. Hence this ticket should remain open for the time being until the reason for the current behavior is clear and it has been decided whether there is something to fix in the Tool Labs setup or not, regardless of the specific use case (and code) of the task reporter.
Please do not change task status as a sign of disagreement or disappointment. Thank you for your understanding! :)

Mjbmr added a comment.EditedMar 8 2015, 3:20 PM

@Aklapper I don't need him to do anything for me, if he doesn't know what privacy means.

coren added a comment.Mar 8 2015, 5:50 PM

@Mjbmr: you are welcome to keep code private or proprietary at some place other than the Wikimedia Labs. The Foundation offers free hosting for tools and utilities made to support our projects and allied projects under the explicit condition that they are Open Source as clearly stated in the terms of use.

Regardless of whether you chose to abide the terms of use you have agreed upon by signing up or seek hosting elsewhere, this task tracks a specific bug that may need to be investigated.

Mjbmr added a comment.Mar 8 2015, 5:57 PM

@coren I totally understand that and knew it, the only problem here is to solve the issue without trying to run my code, I don't like people giving me advice how to code, that's what always happens when people my codes are wrong, you check if there was no issue say there is no issue, not saying your code first, and you better be solving the problem instead telling me what I already know.

Krenair added a subscriber: Krenair.Mar 8 2015, 5:57 PM
scfc added a subscriber: scfc.Mar 8 2015, 9:55 PM

@Mjbmr: @yuvipanda probably didn't want to advise you on how to code, but solve the issue you claimed there is.

There are various helpful hints for good bug reporting, with Simon Tatham's "How to Report Bugs Effectively" probably the most cited one, but saying: "It doesn't work!" and then not providing any steps to reproduce the faulty behaviour is not one of them.

Usually, bug reporters are expected to provide a minimal example that shows the error. Because you didn't do that, @yuvipanda graciously offered to debug your actual application. Most people would have been thankful for that.

So please state what you did, what you expected to happen and what happened instead so that this issue can be looked into.

Mjbmr added a comment.Mar 9 2015, 10:36 AM

System admins must be able to debug anything, coren told me it's solvable by uwsgi.ini which didn't help and even I told him on the channel he ignored now I asked yuvipanda on T91155 now coren showed up. besides I told you I don't need you to solve anything I always find alternative ways when sysadmins don't do anything beside restarting servers. and you better do your job well for what you getting paid for instead of telling me how to report a bug, now close this ticket or don't update it unless you've solved it.

yuvipanda closed this task as Declined.Mar 9 2015, 11:01 AM

So I set up a small flask app to test this (P373).

The thread did get started, and run to completion. I got the output '1', which is what I should have gotten when the thread works. So uwsgi is fine, looks like a bug somewhere else in your code?

@Mjbmr: Please review https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette as well. Be nice to people whose help you are asking for.

scfc added a comment.Mar 9 2015, 11:30 AM

@Mjbmr: Eh, I don't get paid, and if, it wouldn't be enough.

Mjbmr changed the task status from Declined to Resolved.Mar 9 2015, 11:46 AM

@yuvipanda Thank you for fixing it, it works now.

yw. I didn't actually do anything, though :)