Jump to content

Question

Posted

Hello,

 

I'm using lastest H5 L2J Revision. In general.properties, i've some unknown properties, so i'm here to know what this properties deals with..

 

 ---------------------------------------------------------------------------
# Thread Configuration
# ---------------------------------------------------------------------------
# Extreme caution should be here, set to defaults if you do not know what you are doing.
# These could possibly hurt your servers performance or improve it depending on your server's configuration, size, and other factors.
# Default: 10
ThreadPoolSizeEffects = 10

# Default: 13
ThreadPoolSizeGeneral = 13

# Default: 2
UrgentPacketThreadCoreSize = 2

# Default: 4
GeneralPacketThreadCoreSize = 4

# Default: 4
GeneralThreadCoreSize = 4

# Default: 6
AiMaxThread = 6

# Dead Lock Detector (a separate thread for detecting deadlocks).
# For improved crash logs and automatic restart in deadlock case if enabled.
# Check interval is in seconds.
# Default: True
DeadLockDetector = True

# Default: 20
DeadLockCheckInterval = 20

# Default: False
RestartOnDeadlock = False

 

They are useful to adapt for hardware?

10 answers to this question

Recommended Posts

  • 0
Posted

That configures the threadpools, which can be considered the engine running the server. As you dont know what those parameters are, dont touch them

  • 0
Posted

I wouldn't be too concerned with trying to make java work with your hardware. Java code has to be run through a virtual machine first anyway before it starts talking to hardware (or so I believe, correct me if I'm wrong).

 

I highly doubt you will need to touch these values.

  • 0
Posted

bad configured, they will ruin your server

well configured, wont be a big performance impact, in fact, server wont feel so much difference between default config and custom config.

 

This is a little explanation:

A thread pool is a "recipent" where threads are create to execute enqueued tasks (Runnable). As you see, first parameters talk about sizes. That size is the number of threads which are created and used to execute those tasks in each Thread pool

 

L2J Server uses various thread pools:

General thread pool: to execute general-purpose code

IO Thread pool: to read from/write to packet bytebuffers packets

General packet thread pool: to execute the code with the data from bytebuffers packet

 

It also has scheduled thread pool (thread pools wich executes the task in the future)

Effect scheduled pool: used to manage effects time, add and removal

General scheduled pool: general-purpose scheduled thread pool

AI Scheduled thread pool: used to execute the events comming from AI execution

 

In total, 6 thread pool, each one with his configured thread pool size.

 

Now, what you must know and think before change the config is: There will not be never more threads in execution than your machine core processor.

If you have a Intel i7 quad core with 4x processors, there will not be never more than 4 thread executing at the same time.

 

Now, to proceed to configure it you should know about the kernel switch context and how it works, how threads are release (even if they are not finished) to give time to other threads, and how to get rid and use the time the cores are released by blocking access from threads.

 

Resuming, dont touch them

  • 0
Posted

dont confuse io and general packet thread pools with mmocore tasks

oww my bad.

One more thing, now i have been looking for priority system used in java and didnt found too much information. But are the 2 urgent I/O packets threads needed if a proirity system is implemented? Anyway i know that those 2 threads are only created when needed but we still use a pool for them. And if they are rly urgent (cant even wait to any of other 4 to finish) is there a block active thread if urgent income politic?

Thx for the info

  • 0
Posted

Priority just give to the JVM the order in which threads must be executed, from 1 (lower priority) to 10 (max priority). And dont confuse yourself with the configs name. That "urgent" is not supossed for a critical execution peek or smth, the config itself is just the IOPacket thread pool core size.

Guest
This topic is now closed to further replies.


  • Posts

    • “Hello, I’d like to present a short description of the server. Everyone starts equally at max level 80. The server includes a custom buffer, custom class master, custom weapons and armors, custom zones, custom teleporter, custom raid bosses, and much more. I’ll leave a link in the description for those who want to see how everything looks inside. The server is only open on weekends, and you can find more news via the Facebook link.”   https://www.facebook.com/profile.php?id=61578869175323
    • 1. You where subscriber 3 years ago. 2. There is no current L2jMobius 2.8 Seven Signs version. Subcriber or not. 3. You have your answer from multiple forums that more items is more delay.  
    • 1. Optimize Packet Serialization Look in ItemList.java or wherever the inventory packet is constructed. Instead of building the packet with inefficient string concatenation or repeated allocations, use a preallocated buffer and avoid creating new objects for each item. Mobius sources are Java-based, so profiling with something like VisualVM or YourKit can help see where most time is spent. 2. Avoid Sending the Full List Each Time Modify the server to send only changed items (diff packets) when the inventory window opens. Some newer forks implement this as “lazy loading” or paged inventory so the client only loads e.g. 100 items at a time. 3. Limit the Inventory Size Per Page Instead of showing all 500 slots at once, split the inventory into pages/tabs (100 slots each). When the user switches a tab, send only that page’s items. This requires some client-side editing, but it’s the most user-friendly long-term fix. 4. Database & Cache Optimizations Ensure your items table is indexed by owner_id to make the query for player items fast. Cache item templates and static data so they are not reloaded every time the inventory is shown. ⚠️ Things to Keep in Mind Increasing slots from 80 → 500 does not just change a number — it multiplies the workload for packet building and UI rendering. You can’t fully avoid some extra cost with 500 items, but you can keep it under a few milliseconds if you optimize how and when the data is sent.    
    • i think it's the auto sorting of the interface that sucks, check InventoryWnd script in interface.u, or completely disable the request item list packet when toggling the inventory window (also in InventoryWnd script or similar name)
  • Topics

×
×
  • Create New...

AdBlock Extension Detected!

Our website is made possible by displaying online advertisements to our members.

Please disable AdBlock browser extension first, to be able to use our community.

I've Disabled AdBlock