Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[GonoszTopi]

@Stu: wxBase-2.x does have sockets.

@freddy77: The limitation is that wxBase doesn't support events so we had to write our own event loop using system functions like select(2).

[Stu Redman]

@Stu: wxBase-2.x does have sockets.

So why are we using different socket code in amuled than in aMule? I'm refering to WoWoW30:

support to wxBase was added for events loops, timers and sockets for writing event-based client or server apps with wxWidgets 3.0

[Kry]

Because it doesn't have an event loop and we don't support 3.0 (and won't switch the code to it until a) it's out and b) it's been out for a while and everyone uses it).

[stoatwblr]

Before you start digging into it:

- The 1024 is only a amuled issue, not an amule issue. With amule, file handles are unlimited (if they are unlimited in your OS at least). For amuled there is a chance to get rid of the limit and the legacy code when wx 3.0 comes out and sockets/events for non-gui apps become available.
- 600 downloads at a time is overdoing things anyway. A machine capable of that can also run amule instead of amuled and so work around the problem.

I have a _lot_  more than 600 requests open (mostly old/rare stuff that's been in the queue for months and only shows up for a few hours at a time).

Above about 1500 entries (Stopped!) in the queue, Amule is highly unstable and drops out with Wx errors at the slightest provokation - anything such as changing views, or opening the preferences window.

Switching from Stopped to Waiting makes things even more unstable.

This is happening in 2.2.4 and in SVN

(Linux, 100k file handle limt)

There are definitely stability issues that need looking at. While the developers may feel that I'm crazy to push things to breaking point, it's usually at breaking point that security issues and trivially fixed bugs  may show up

Holding filehandles open unecessarily is counterproductive - AND it means that disk space isn't being released when files are deleted out of the Incoming directory (ie, moved to another partition).

[Stu Redman]

Above about 1500 entries (Stopped!) in the queue, Amule is highly unstable and drops out with Wx errors at the slightest provokation - anything such as changing views, or opening the preferences window.

AMule or aMuled?
Can you post a backtrace?

Holding filehandles open unecessarily is counterproductive

Not if 99000 are still left.

- AND it means that disk space isn't being released when files are deleted out of the Incoming directory (ie, moved to another partition).

Only temp files get a permanent handle, not completed shared files. So you're wrong.

I admit that it makes no sense assigning a file handle for paused downloads without completed parts, and I'd like to change that.

[Kry]

I admit that it makes no sense assigning a file handle for paused downloads without completed parts, and I'd like to change that.

There was an interesting approach by some dude here long time ago that closed the handles when they weren't used for a while. You can search for it.

[stoatwblr]

Above about 1500 entries (Stopped!) in the queue, Amule is highly unstable and drops out with Wx errors at the slightest provokation - anything such as changing views, or opening the preferences window.

AMule or aMuled?

Amule. Amuled is already borked at 1024.

Can you post a backtrace?

Here? or in the Backtrace area forum?

I'll have to load up a version with debugging symbols. Is SVn preferred?

Holding filehandles open unecessarily is counterproductive

Not if 99000 are still left.

Not many people are going to go and tweak their ulimits.

- AND it means that disk space isn't being released when files are deleted out of the Incoming directory (ie, moved to another partition).

Only temp files get a permanent handle, not completed shared files. So you're wrong.

OK.

I admit that it makes no sense assigning a file handle for paused downloads without completed parts, and I'd like to change that.

Even in "waiting" state, there's no need to keep the filehandle open. Please try not to emulate Windows resource-hogging operational models. It makes things difficult to run on older hardware (I just updated from a 1Gb P41.8 to a 2Gb P4 3.0. In general it's all I need for Linux and this comes from $orkplace junkbox...)

[Kry]

You realize you upload in addition to download, right?

EDIT: Other than files with no complete parts, of course.

[stoatwblr]

You realize you upload in addition to download, right?

Of course - but the program should only need to open filehandles when upload requests come in (or when downloading, of course)

Again: Why hold filehandles open if they're not needed? It's wasteful.

[Kry]

Because it's easy and makes it faster to access the files when the requests come. OTOH of course we shouldn't do it, and again, we have already sad it should be fixed.

[stoatwblr]

This is the  backtrace I'm seeing in the version without debugging symbols enabled.

----------------------------=| BACKTRACE FOLLOWS: |=----------------------------
Current version is: aMule 2.2.4 using wxGTK2 v2.8.9
Running on: Linux 2.6.28-11-generic i686

[2] wxString::~wxString() in amule [0x8086311]
[3] wxFatalSignalHandler in /usr/lib/libwx_baseu-2.8.so.0[0xb75bef26]
[4] ?? in [0xb7ee6400]
[5] wxStringTokenizer::~wxStringTokenizer() in amule [0x8096396]
[6] CryptoPP::FileSource::~FileSource() in amule [0x80bd2f3]
[7] wxStringTokenizer::~wxStringTokenizer() in amule [0x80962b6]
[8] wxTimer::IsRunning() const in amule [0x81e88e8]
[9] std::vector<bool, std::allocator<bool> >::_M_fill_insert(std::_Bit_iterator, unsigned int, bool) in amule [0x80c7fc3]
[10] wxString::~wxString() in amule [0x808adf8]
[11] wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const in /usr/lib/libwx_baseu-2.8.so.0[0xb751b2a1]
[12] wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) in /usr/lib/libwx_baseu-2.8.so.0[0xb75ba60a]
[13] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) in /usr/lib/libwx_baseu-2.8.so.0[0xb75bb824]
[14] wxEvtHandler::ProcessEvent(wxEvent&) in /usr/lib/libwx_baseu-2.8.so.0[0xb75bb92b]
[15] wxEvtHandler::ProcessPendingEvents() in /usr/lib/libwx_baseu-2.8.so.0[0xb75baa89]
[16] wxAppConsole::ProcessPendingEvents() in /usr/lib/libwx_baseu-2.8.so.0[0xb751b601]
[17] wxAppBase::ProcessIdle() in /usr/lib/libwx_gtk2u_core-2.8.so.0[0xb781f58f]
[18] ?? in /usr/lib/libwx_gtk2u_core-2.8.so.0 [0xb776e123]
[19] ?? in /usr/lib/libglib-2.0.so.0 [0xb6b5ac81]
[20] g_main_context_dispatch in /usr/lib/libglib-2.0.so.0[0xb6b5cb88]
[21] ?? in /usr/lib/libglib-2.0.so.0 [0xb6b600eb]
[22] g_main_loop_run in /usr/lib/libglib-2.0.so.0[0xb6b605ba]
[23] gtk_main in /usr/lib/libgtk-x11-2.0.so.0[0xb6fa07d9]
[24] wxEventLoop::Run() in /usr/lib/libwx_gtk2u_core-2.8.so.0[0xb7787cb5]
[25] wxAppBase::MainLoop() in /usr/lib/libwx_gtk2u_core-2.8.so.0[0xb781f3fe]
[26] wxAppBase::OnRun() in /usr/lib/libwx_gtk2u_core-2.8.so.0[0xb781efd1]
[27] wxEntry(int&, wchar_t**) in /usr/lib/libwx_baseu-2.8.so.0[0xb7554eea]
[28] wxEntry(int&, char**) in /usr/lib/libwx_baseu-2.8.so.0[0xb75550e7]
[29] std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf() in amule [0x815fff0]
[30] __libc_start_main in /lib/tls/i686/cmov/libc.so.6[0xb723b775]
[31] ?? in amule [0x8085121]

[Stu Redman]

There was an interesting approach by some dude here long time ago that closed the handles when they weren't used for a while. You can search for it.

You mean this one? Too bad the patch is not attached anymore. 
Does someone still have it?
I like the approach of a CFileAutoClose class that handles opening/closing internally. And a simple policy like closing after 10min of inactivity should do. Really, if a client has waited 2 hours for a download slot he won't notice 20ms required to open a file. 

[PacoBell]

Ooh! That does sound tasty. Please implement. Meanwhile, I'll just continue to jack up my maxfilesperproc to some ridiculous number

[Kry]

Weird how the attachments are gone, this might have been before the forum migration...


... wait, since when do I have this awesome memory?

[Kry]

BTW stu, careful with such a class. Functions don't get called magically, so you would need to poll the classes for status/timeout/etc...