Jump to content

Wikipedia talk:WikiProject Java

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Wikipedia talk:JAVAP)
Wikipedia:WikiProject_Java
Wikipedia:WikiProject_Java
Wikipedia_talk:WikiProject_Java
Wikipedia_talk:WikiProject_Java
Wikipedia:WikiProject_Java/Things_you_can_do
Wikipedia:WikiProject_Java/Things_you_can_do
Wikipedia:WikiProject_Java/Sandbox
Wikipedia:WikiProject_Java/Sandbox
Wikipedia:WikiProject_Java/New articles
Wikipedia:WikiProject_Java/New articles
Wikipedia:WikiProject_Java/Peer_Review
Wikipedia:WikiProject_Java/Peer_Review
Wikipedia:WikiProject_Java/Assessment
Wikipedia:WikiProject_Java/Assessment
Wikipedia:WikiProject_Java/Announcement
Wikipedia:WikiProject_Java/Announcement
Wikipedia_talk:WikiProject_Java/Things_you_can_do/to_do
Wikipedia_talk:WikiProject_Java/Things_you_can_do/to_do



java thread pools

[edit]

Most of server based applications, like Web servers, database servers, or mail servers, are responsible for controlling a large number of tasks that arrive from some remote source it can be fast task.
Any request can received by the servers in any manner, which can be from a network protocol (HTTP, FTP, or POP), through a JMS queue, MQ, myth be by polling a database or any socket based connection. It’s often the case in server applications that the processing of each individual task is short-lived and the number of requests is large.
One simplistic model for building a server application would be to create a new thread each time a request arrives and service the request in the new thread.
This approach actually works fine for prototyping, but has significant disadvantages that would become apparent if you tried to deploy a server application that worked this way. One of the disadvantages of the thread-per-request approach is that the overhead of creating a new thread for each request is significant; a server that created a new thread for each request would spend more time and consume more system resources creating and destroying threads than it would processing actual user requests.
A thread pool offers a solution to thread life-cycle overhead and the resource thrashing. By reusing threads for multiple tasks, the thread-creation overhead is spread over many tasks. As a bonus, because the thread already exists when a request arrives, the delay introduced by thread creation is eliminated. Thus, the request can be serviced immediately, rendering the application more responsive. Furthermore, by properly tuning the number of threads in the thread pool, you can prevent resource thrashing by forcing any requests in excess of a certain threshold to wait until a thread is available to process it.

Dear Ehsaniara, many thanks for your invaluable contribution to this project. I don't see much Java stuff in there so may we point you to the Thread pool pattern article... The only intriguing thing is that your bit is not as well 'written' as the source you took it from... AR 18 December 2009, 14:36 (UTC)

Request for comment on Biographies of living people

[edit]

Hello Wikiproject! Currently there is a discussion which will decide whether wikipedia will delete 49,000 articles about a living person without references, here:

Wikipedia:Requests for comment/Biographies of living people

Since biographies of living people covers so many topics, nearly all wikiproject topics will be effected.

The two opposing positions which have the most support is:

  1. supports the deletion of unreferenced articles about a living person, User:Jehochman
  2. opposes the deletion of unreferenced articles about a living person, except in limited circumstances, User:Collect

Comments are welcome. Keep in mind that by default, editor's comments are hidden. Simply press edit next to the section to add your comment.

Please keep in mind that at this point, it seems that editors support deleting unreferenced article if they are not sourced, so your project may want to pursue the projects below.

User script to detect unreliable sources

[edit]

I have (with the help of others) made a small user script to detect and highlight various links to unreliable sources and predatory journals. Some of you may already be familiar with it, given it is currently the 39th most imported script on Wikipedia. The idea is that it takes something like

  • John Smith "Article of things" Deprecated.com. Accessed 2020-02-14. (John Smith "[https://www.deprecated.com/article Article of things]" ''Deprecated.com''. Accessed 2020-02-14.)

and turns it into something like

It will work on a variety of links, including those from {{cite web}}, {{cite journal}} and {{doi}}.

The script is mostly based on WP:RSPSOURCES, WP:NPPSG and WP:CITEWATCH and a good dose of common sense. I'm always expanding coverage and tweaking the script's logic, so general feedback and suggestions to expand coverage to other unreliable sources are always welcomed.

Do note that this is not a script to be mindlessly used, and several caveats apply. Details and instructions are available at User:Headbomb/unreliable. Questions, comments and requests can be made at User talk:Headbomb/unreliable.

- Headbomb {t · c · p · b}

This is a one time notice and can't be unsubscribed from. Delivered by: MediaWiki message delivery (talk) 16:01, 29 April 2022 (UTC)[reply]

Nomination of AppletViewer for deletion

[edit]
A discussion is taking place as to whether the article AppletViewer is suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or whether it should be deleted.

The article will be discussed at Wikipedia:Articles for deletion/AppletViewer until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines.

Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article until the discussion has finished.