Object Restructures, and a Deadlock?

[Ekaika]

This is a long informational read, be sure to check out the links on topics you're unfamiliar with!

As you know, our Test Center will "crash" operation from time to time, lately more often than not. Why, you ask?

If you've been keeping up on current affairs, you know that the focus of development shifted some time ago from content "branches" to the fundamental codebase.

Throughout the past few years this project has seen many Developers come and go, each with their own unique contributions to the code. However, the sheer number of contributions placed a severe burden on a few Core Devs that assumed the responsibility of Integrating all this new code into the "Tree" successfully. This is not without challenges. Things such as deadlocks, crashes, memory-leaks, etc are a constant threat.

When these issues arise, a condition known as a "Deadlock" can occur. In our case, a Deadlock means that several aspects of the code are awaiting one another to complete, causing the server to grind to a halt. Please take some time to understand what a Deadlock is.

At a certain point, the decision was made (and wisely) to take stock of what had been accomplished, reviewing current code and ensuring that the "Tree" was sufficiently workable. It was determined that modifications were necessary, not only to clean up the current code, but to ensure that future contributions would be EASILY adapted to the complete Tree, without reconfiguration and coding of the entire codebase each addition.

As a result, the OR was born. SWGEmu has been many months into this, and significant progress has been made. However this post isn't to note progress, it's intention is to inform about the OR and what a "Deadlock" actually is. The community needs a place to be able to point new members to, so they can become informed. Hopefully this post is a start. I encourage all who read this to FURTHER review the Announcements, Community News posts, and the Bi-Weekly Updates. All available information is represented there.

At this point the emphasis on the current revision was marginalized in light of the need to lean out what was going to be the workable code moving forward. However, you guys are playing, and a few of our guys have made valiant attempts (read: TA, Kyle etc etc, Kellina, Learning, all QA) to make what's here, work. As a result you've seen a lot of jedi work. Please understand that this is not a permafix, nor is it intended to be the end all of Jedi/SWGemu. Things will change, and this is only temporary.

HOWEVER! Please do not assume that Jedi is the Emu's focus, it is not. This was done for you folks, as a gift, while the slow process of the OR is worked through.

Please be patient while our 100% volunteer staff continues to chip away at the OR. As you can see, we're still here. This is simply not a time for momentous leaps and bounds. However that time will come, and we'll need to you help us test the new code and prepare for the final push.

Thank you, as always, for your ongoing support of Pre-Cu and SWGEmu!

* Please remember, you can check server status in the Java client at SWGEmu IRC or your favorite IRC client. Please see #test and #status for the latest status updates.

** You can also find current status reporting (excluding the deadlock condition) at www.swgemu.org

SWGEmu