[JBoss JIRA] (WFLY-3404) Major performance degradation from JBoss 7.1 to Wildfly 8.0.0-Final.
by Timothy Heider (JIRA)
[ https://issues.jboss.org/browse/WFLY-3404?page=com.atlassian.jira.plugin.... ]
Timothy Heider commented on WFLY-3404:
--------------------------------------
I found worker thread pool settings in Profile > Core > IO. They were very low by default. I guess the small thread pool would go into a blocking state until the Comet call broke (on a timeout).
We've decided to stop using Comet and instead use 2 second polling until we can implement something like WebSockets.
> Major performance degradation from JBoss 7.1 to Wildfly 8.0.0-Final.
> --------------------------------------------------------------------
>
> Key: WFLY-3404
> URL: https://issues.jboss.org/browse/WFLY-3404
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Final
> Reporter: Timothy Heider
> Assignee: Jason Greene
>
> I have deployed my application to Wildfly 8.0.0 Final and it is almost unusable now. We have rolled back to JBoss 7.1 (same application WARs) and it works fine.
> Specifically what seems to be slow is our SOAP web services are taking up to 8 to 10 seconds to respond. We have user concurrency of probably 10-30 users at once hitting these services every 10 seconds or so.
> On JBoss 7.1 these services all respond sub-second. The database is totally unburdened and the server is 90% idle all the time.
> We have one service endpoint that is a Comet queue wait call. Probably 10 users are waiting on that. Did something change between JBoss 7 and Wildfly 8 that might cause that to not work now? (e.g. too small a thread pool that blocks until the 10 second comet call breaks on a timeout?)
> We will try 8.1.0CR2 but I wanted to report we're investigating this and see if you can help us. Thanks!
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (WFLY-3072) Support Referrals for security realms using LDAP for authentication or group loading.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3072?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3072:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1066488|https://bugzilla.redhat.com/show_bug.cgi?id=1066488] from MODIFIED to ON_QA
> Support Referrals for security realms using LDAP for authentication or group loading.
> -------------------------------------------------------------------------------------
>
> Key: WFLY-3072
> URL: https://issues.jboss.org/browse/WFLY-3072
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.1.0.CR2, 8.1.0.Final
>
>
> I see the following scenarios to cover for this: -
> - Authentication - A search is performed e.g against 'uid' and a referral is encountered, the URL needs to be extracted from the referral and a new connection created using the referral URL to load any additional attributes for the user, the referral URL is then used to establish the connection as the user to verify that their password is correct.
> Group loading then has a couple of issues, firstly where the user was a referral.
> The search for group membership information is a fresh start but now we potentially have 2 simple named and 2 distinguished names that could be referenced from the group object. We may want a config option to specify which one to actually use and even possibly use both.
> Next could a group also be a referral, i.e. it contains the reference to the user as an attribute so was matched in the search but is also a referral to the true named group in another location. In this situation I suggest any iterative search takes into account the context containing the actual group definition and continues the search from there.
> And then where the principal contains an attribute that references, this one should be a simple following of a referral and once followed continue the attribute loading using the new connection.
> The connection manager logic is going to need reworking, ideally for a referral we should check if we have a connection definition that matches based on the URL returned otherwise we will need to try and establish a connection based on the settings of the last connection used, this probably also introduces a notion of some form of connection stack of the connections used for the current request - referrals could have us bouncing back and forth so connections should be cached and re-used where possible during authentication and group loading.
> * Connection Settings *
> We are going to need to support two different modes in relation to the 'java.naming.referral' property, follow and throw.
> - *follow* - In this mode when the InitialDirContext encounters a referral during a search it will automatically follow it, this means automatically connecting to the server in the URL. This is fine if the remaining connection settings are valid for the alternative server e.g. same bindDN and credential. We however need to take the following into account for subsequent operations such as password validation or further queries.
> - *throw* - When a referral is encountered and exception will be thrown instead, this mode should make it easier to have some more advanced referral handling logic that allows us control of which connection we subsequently use, e.g. we could not use a completely different host name to the one in the referral or use a different bind DN / credential pair.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (WFLY-2789) Remote client transaction timeout values are overwrote by hardcoded values
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2789?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2789:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1093128|https://bugzilla.redhat.com/show_bug.cgi?id=1093128] from ASSIGNED to POST
> Remote client transaction timeout values are overwrote by hardcoded values
> --------------------------------------------------------------------------
>
> Key: WFLY-2789
> URL: https://issues.jboss.org/browse/WFLY-2789
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Johnathon Lee
> Assignee: David Lloyd
> Fix For: 8.1.0.Final, 9.0.0.Alpha1
>
>
> The EJB3 interceptor is not using client values for timeouts, this is a problem for users trying to use EJB for transaction propagation.
> Refer to the code in https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...:
> private void createOrResumeXidTransaction(final XidTransactionID xidTransactionID) throws Exception {
> final TransactionManager transactionManager = this.ejbRemoteTransactionsRepository.getTransactionManager();
> final Transaction alreadyCreatedTx = this.ejbRemoteTransactionsRepository.getImportedTransaction(xidTransactionID);
> if (alreadyCreatedTx != null) {
> // resume the already created tx
> transactionManager.resume(alreadyCreatedTx);
> } else {
> // begin a new tx and add it to the tx repository
> // TODO: Fix the tx timeout (which currently is passed as 300 seconds)
> final Transaction newSubOrdinateTx = this.ejbRemoteTransactionsRepository.importTransaction(xidTransactionID, 300);
> // associate this tx with the thread
> transactionManager.resume(newSubOrdinateTx);
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (WFLY-2789) Remote client transaction timeout values are overwrote by hardcoded values
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2789?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2789:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1093128|https://bugzilla.redhat.com/show_bug.cgi?id=1093128] from NEW to ASSIGNED
> Remote client transaction timeout values are overwrote by hardcoded values
> --------------------------------------------------------------------------
>
> Key: WFLY-2789
> URL: https://issues.jboss.org/browse/WFLY-2789
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Johnathon Lee
> Assignee: David Lloyd
> Fix For: 8.1.0.Final, 9.0.0.Alpha1
>
>
> The EJB3 interceptor is not using client values for timeouts, this is a problem for users trying to use EJB for transaction propagation.
> Refer to the code in https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...:
> private void createOrResumeXidTransaction(final XidTransactionID xidTransactionID) throws Exception {
> final TransactionManager transactionManager = this.ejbRemoteTransactionsRepository.getTransactionManager();
> final Transaction alreadyCreatedTx = this.ejbRemoteTransactionsRepository.getImportedTransaction(xidTransactionID);
> if (alreadyCreatedTx != null) {
> // resume the already created tx
> transactionManager.resume(alreadyCreatedTx);
> } else {
> // begin a new tx and add it to the tx repository
> // TODO: Fix the tx timeout (which currently is passed as 300 seconds)
> final Transaction newSubOrdinateTx = this.ejbRemoteTransactionsRepository.importTransaction(xidTransactionID, 300);
> // associate this tx with the thread
> transactionManager.resume(newSubOrdinateTx);
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (WFLY-1513) remove operation on JMS queue/topic doesn't remove the destination but just unbinds from JNDI
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-1513?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-1513:
------------------------------
Fix Version/s: 9.0.0.Alpha1
> remove operation on JMS queue/topic doesn't remove the destination but just unbinds from JNDI
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-1513
> URL: https://issues.jboss.org/browse/WFLY-1513
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, JMS
> Affects Versions: 8.0.0.Alpha1, 8.0.0.Alpha2
> Reporter: jaikiran pai
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Alpha1
>
>
> The remove (management) operation on a JMS queue merely unbinds the queue from JNDI instead of destroying the queue. It appears that the change was done as part of https://issues.jboss.org/browse/AS7-1899 (the PR is here https://github.com/wildfly/wildfly/pull/398). The change done in that PR to address the original issue reported in that other JIRA doesn't look right.
> So the original issue reported in that thread is that a server has a queue with messages and the server is stopped. Upon restart the messages have disappeared because upon stop, the JMSQueueService's stop() method used to destroy the queue. The real fix would have been to differentiate the "remove()" operation from a mere service stop. The explicit remove (handler) would then be responsible for destroying the queue (which even means a JNDI unbind) and not that service's stop method.
> All of this even applies to the JMS topic which has a similar problem.
> On a related note, the add() operation too seems suspicious because it ends up calling a createXXX on the JMSServer API which says:
> {code}
> /**
> * Creates a JMS Queue.
> *
> * @param queueName
> * The name of the queue to create
> * @param selectorString
> * @param durable
> * @return true if the queue is created or if it existed and was added to
> * JNDI
> * @throws Exception
> * if problems were encountered creating the queue.
> */
> boolean createQueue(boolean storeConfig, String queueName, String selectorString, boolean durable, String ...bindings) throws Exception;
> {code}
> Notice the "if the queue is created or if it existed and was added to JNDI" part. So it appears that the management "add" operation can end up behaving like an update (write-attribute) kind of operation in some cases. I'm not sure if that's good thing.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (WFLY-2789) Remote client transaction timeout values are overwrote by hardcoded values
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2789?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2789:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1093752|https://bugzilla.redhat.com/show_bug.cgi?id=1093752] from ASSIGNED to POST
> Remote client transaction timeout values are overwrote by hardcoded values
> --------------------------------------------------------------------------
>
> Key: WFLY-2789
> URL: https://issues.jboss.org/browse/WFLY-2789
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Johnathon Lee
> Assignee: David Lloyd
> Fix For: 8.1.0.Final, 9.0.0.Alpha1
>
>
> The EJB3 interceptor is not using client values for timeouts, this is a problem for users trying to use EJB for transaction propagation.
> Refer to the code in https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...:
> private void createOrResumeXidTransaction(final XidTransactionID xidTransactionID) throws Exception {
> final TransactionManager transactionManager = this.ejbRemoteTransactionsRepository.getTransactionManager();
> final Transaction alreadyCreatedTx = this.ejbRemoteTransactionsRepository.getImportedTransaction(xidTransactionID);
> if (alreadyCreatedTx != null) {
> // resume the already created tx
> transactionManager.resume(alreadyCreatedTx);
> } else {
> // begin a new tx and add it to the tx repository
> // TODO: Fix the tx timeout (which currently is passed as 300 seconds)
> final Transaction newSubOrdinateTx = this.ejbRemoteTransactionsRepository.importTransaction(xidTransactionID, 300);
> // associate this tx with the thread
> transactionManager.resume(newSubOrdinateTx);
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (DROOLS-506) Example project: massive number of code quality / correctness warnings
by Peter Horvath (JIRA)
[ https://issues.jboss.org/browse/DROOLS-506?page=com.atlassian.jira.plugin... ]
Peter Horvath updated DROOLS-506:
---------------------------------
Attachment: eclipse_warnings.png
Screenshot of Eclipse displaying warnings found in Drools example projects
> Example project: massive number of code quality / correctness warnings
> ----------------------------------------------------------------------
>
> Key: DROOLS-506
> URL: https://issues.jboss.org/browse/DROOLS-506
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Peter Horvath
> Assignee: Mark Proctor
> Attachments: eclipse_warnings.png
>
>
> The Drools example project contains code snippets that yield warnings: *while I absolutely understand that resources are limited and examples might not be the priority and the core code of the engine is of good quality*, I do think it is important to display dedication to high quality products.
> Having an example project full of code quality issues just gives a very bad first impression of the whole Drools project...
> Examples:
> {code:title=org.drools.examples.cashflow.CashFlowMain|borderStyle=solid}
> public class CashFlowMain {
> public static void main(String[] args) throws Exception {
> SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
> {code}
> yields {color:red}WARNING: The value of the local variable sdf is not used {color}
> {code:title=org.drools.examples.sudoku.Sudoku.dumpGrid()|borderStyle=solid}
> /**
> * Nice printout of the grid.
> */
> public void dumpGrid() {
> Formatter fmt = new Formatter(System.out);
> {code}
> yields {color:red}WARNING: Resource leak: 'fmt' is never closed {color}
> {code:title=org.drools.games.pong.PongUI|borderStyle=solid}
> import java.awt.*;
> import java.awt.event.KeyEvent;
> import java.awt.event.KeyListener;
> import java.awt.event.MouseEvent;
> import java.awt.event.MouseListener;
> import java.awt.font.FontRenderContext;
> import java.awt.font.TextLayout;
> import java.awt.image.BufferedImage;
> import javax.swing.*;
> import org.drools.games.GameConfiguration;
> import org.drools.games.GameUI;
> import org.kie.api.runtime.KieSession;
> import org.kie.internal.runtime.StatefulKnowledgeSession;
> import org.kie.api.runtime.rule.FactHandle;
> import org.kie.api.runtime.rule.EntryPoint;
> public class PongUI extends GameUI {
> {code}
> yields {color:red}WARNING: The import java.awt.event.KeyEvent is never used {color} \\
> {color:red}WARNING: The import java.awt.event.KeyListener is never used {color} \\
> {color:red}WARNING: The import java.awt.event.MouseEvent is never used {color} \\
> {color:red}WARNING: The import java.awt.event.MouseListener is never used {color} \\
> {color:red}WARNING: The import java.awt.image.BufferedImage is never used {color} \\
> {color:red}WARNING: The import javax.swing.* is never used {color} \\
> {color:red}WARNING: The import org.kie.internal.runtime.StatefulKnowledgeSession is never used {color} \\
> {color:red}WARNING: The import org.kie.api.runtime.rule.FactHandle is never used {color} \\
> {color:red}WARNING: The import org.kie.api.runtime.rule.EntryPoint is never used {color} \\
> etc
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months