[JBoss JIRA] (AS7-4862) Remote EJB SFSB load balancing still very suboptimal
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4862:
-----------------------------------
Summary: Remote EJB SFSB load balancing still very suboptimal
Key: AS7-4862
URL: https://issues.jboss.org/browse/AS7-4862
Project: Application Server 7
Issue Type: Bug
Components: Clustering, EJB
Affects Versions: 7.1.2.Final (EAP)
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.3.Final (EAP)
Looking at the load-balancing again, it seems still wrong. Checking the logs, servers were started *and cluster was formed* ~10 seconds prior to starting the client and load-balancing was roughly:
* node perf18: ~50% of sessions
* node perf19: 0
* node perf20: 0
* node perf21: ~50% of sessions
I let all the session to be created in one minute (not all at once).
The nodes were also specified in the properties.
{noformat}
node perf18
[JBossINF] 07:01:53,991 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (CacheService lifecycle - 1) ISPN000094: Received new cluster view: [perf19/ejb|3] [perf19/ejb, perf21/ejb, perf20/ejb, perf18/ejb]
node perf19
[JBossINF] 07:01:53,781 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-19,null) ISPN000094: Received new cluster view: [perf19/ejb|3] [perf19/ejb, perf21/ejb, perf20/ejb, perf18/ejb]
node perf20
[JBossINF] 07:01:53,781 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-14,null) ISPN000094: Received new cluster view: [perf19/ejb|3] [perf19/ejb, perf21/ejb, perf20/ejb, perf18/ejb]
node perf21
[JBossINF] 07:01:53,780 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-12,null) ISPN000094: Received new cluster view: [perf19/ejb|3] [perf19/ejb, perf21/ejb, perf20/ejb, perf18/ejb]
controller node
2012/05/22 07:02:02:932 EDT [DEBUG][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Setting thread count: 2000, was: 0
2012/05/22 07:02:53:731 EDT [DEBUG][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - All runners (2000) started in 50799 milliseconds
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (AS7-5792) Deadlock detection for Entity beans
by Christian Inzko (JIRA)
Christian Inzko created AS7-5792:
------------------------------------
Summary: Deadlock detection for Entity beans
Key: AS7-5792
URL: https://issues.jboss.org/browse/AS7-5792
Project: Application Server 7
Issue Type: Feature Request
Components: EJB
Affects Versions: 7.1.1.Final
Environment: Windows 7 64 bit, Java 1.7.0 64 bit
Reporter: Christian Inzko
Assignee: jaikiran pai
Deadlock detection with EJB 2.1 entity beans and pessimistic locking does not work.
We are migrating our application from Jboss 4.05 where we used entity beans. This jboss version was able to detect deadlock situations and throw a org.jboss.util.deadlock.ApplicationDeadlockException. This mechanism does no longer work - instead of that both transactions just hang until a transaction timeout is reached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (AS7-4707) Preventing reconnect attempt of remote ejb client
by Serkan Yıldırım (JIRA)
Serkan Yıldırım created AS7-4707:
------------------------------------
Summary: Preventing reconnect attempt of remote ejb client
Key: AS7-4707
URL: https://issues.jboss.org/browse/AS7-4707
Project: Application Server 7
Issue Type: Bug
Components: Remoting, Server
Affects Versions: 7.1.1.Final
Reporter: Serkan Yıldırım
Assignee: David Lloyd
Priority: Blocker
Hi,
I have a remote ejb client and a custom login module. I am testing my login module, i enter an invalid password in remote client. My login module runs correctly and send an exception. However, remote client attempts to recall login module again to login user. But i do not want this. Because when there is an exception in my custom login module, i update some values in my database. Therefore the same code in login module runs twice and my db has inconsistent values. So how can i prevent this reconnect attemp of remote ejb client? I use JBOSS 7.1.2 Final SNAPSHOT version in server and jboss 7.1.1 client maven dependencies. Thanks.
My Client code is like below:
Properties pr = new Properties();
pr.put("endpoint.name", "client-endpoint");
pr.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false");
pr.put("remote.connections", "default");
pr.put("remote.connection.default.port", "4447");
pr.put("remote.connection.default.host", "localhost");
pr.put("remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS", "JBOSS-LOCAL-USER");
pr.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false");
pr.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");
pr.put("remote.connection.default.username", "user1");
pr.put("remote.connection.default.password", "Test12345");
EJBClientConfiguration cc = new PropertiesBasedEJBClientConfiguration(pr);
ContextSelector < EJBClientContext > selector = new ConfigBasedEJBClientContextSelector(cc);
EJBClientContext.setSelector(selector);
Properties props = new Properties();
props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
props.put("jboss.naming.client.ejb.context", true);
try {
Context c = new InitialContext(props);
kullaniciEJB = (KullaniciEJBRemote) c.lookup("ejb:merveys-kayit-tckkys/merveys-kayit-ejb-tckkys//KullaniciEJB!tr.gov.tubitak.bilgem.uekae.deys.tckk.merveys.common.controller.ejb.kullanici.KullaniciEJBRemote");
} catch (NamingException e) {
e.printStackTrace();
}
int count = kullaniciEJB.countKartIslemList(1L, null, null);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (AS7-5700) WSBAParticipantCompletionTestCase XTS integration test fails intermittently
by Paul Robinson (JIRA)
Paul Robinson created AS7-5700:
----------------------------------
Summary: WSBAParticipantCompletionTestCase XTS integration test fails intermittently
Key: AS7-5700
URL: https://issues.jboss.org/browse/AS7-5700
Project: Application Server 7
Issue Type: Bug
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Priority: Minor
Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
When a WSBA participant employs the ParticipantCompletion protocol, it is the responsibility of the participant to notify the coordinator when it has completed its work. This notification is asynchronous.
In the 'WSBAParticipantCompletionTestCase' test, the client invokes the participant's web service who notifies completion just before returning from the invocation. The client then sends a message to the coordinator requesting to close (complete) the activity.
As the "complete" message is asynchronous, we now have a race. If the Client's close message is processed by the coordinator before the participant's "complete" message, then the coordinator cancels the BA as not all participants have completed. This results in the client receiving a TransactionRolledBackException and the completed participant is (eventually) compensated. The outcome is atomic, but a BA that would have otherwise succeeded, is unsuccessful.
In reality we only expect this scenario to happen in the rather artificial scenario where all parties (client, coordinator and participants) are on the same server. It also only seems to happen on very slow machines. Therefore, it's fine to fix the test to prevent this scenario from arising, rather than to somehow change the protocol (without breaking the WS-BA standard) to prevent it.
We have two options, that I can see to fix the test:
1) Byteman Rendezvous. Here we would introduce a dependency on Byteman and write a script that delays the client's close message until all participants' 'complete' messages have been acknowledged by the coordinator. This is probably an over-engineered solution as we would be introducing Byteman, to these tests, for this single case.
2) We add a Thread.sleep(10000) to the test, just before the client sends the 'cloe' message to the coordinator. This is what we did to the XTS tests in the JBossTS project as a stop-gap until we decided how to do it "properly".
I suggest we go with 2) as it is the simplest solution. The extra time added to the test is just 20s as there are only two tests affected by this. In the future, when we have more tests we should reduce this sleep period or consider using another solution (such as Byteman), in order to keep the test duration acceptable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (AS7-4782) NoSuchMethodError: org.jboss.logmanager.LogContext.getLoggerIfExists
by Juergen Zimmermann (JIRA)
Juergen Zimmermann created AS7-4782:
---------------------------------------
Summary: NoSuchMethodError: org.jboss.logmanager.LogContext.getLoggerIfExists
Key: AS7-4782
URL: https://issues.jboss.org/browse/AS7-4782
Project: Application Server 7
Issue Type: Bug
Components: Logging
Affects Versions: 7.1.2.Final (EAP)
Environment: Compilation: JBossAS 7.1.2.Final checked out from github.com and compiled with JDK 7u4 32-Bit on Win7 64-Bit.
Runtime: JDK 7u4 64-Bit on same Windows box.
Reporter: Juergen Zimmermann
Assignee: James Perkins
I'm running just a simple test which was working fine on JBossAS 7.1.1. Now on 7.1.2 (see description in the Environment section) I'm getting this stacktrace:
java.lang.RuntimeException: Could not create a new instance of class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor see cause.
at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:170)
at org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder.build(TestRunnerAdaptorBuilder.java:52)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:93)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:166)
... 14 more
Caused by: java.lang.RuntimeException: Could not create a new instance of class org.jboss.arquillian.core.impl.ManagerImpl see cause.
at org.jboss.arquillian.core.spi.SecurityActions.newInstance(SecurityActions.java:157)
at org.jboss.arquillian.core.spi.ManagerBuilder.create(ManagerBuilder.java:77)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.<init>(EventTestRunnerAdaptor.java:55)
... 19 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.jboss.arquillian.core.spi.SecurityActions.newInstance(SecurityActions.java:153)
... 21 more
Caused by: java.lang.NoSuchMethodError: org.jboss.logmanager.LogContext.getLoggerIfExists(Ljava/lang/String;)Lorg/jboss/logmanager/Logger;
at org.apache.log4j.JBossLogManagerFacade.updateParents(JBossLogManagerFacade.java:197)
at org.apache.log4j.JBossLogManagerFacade.getLogger(JBossLogManagerFacade.java:145)
at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:130)
at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:125)
at org.apache.log4j.LogManager.getLogger(LogManager.java:57)
at org.apache.log4j.Logger.getLogger(Logger.java:35)
at org.jboss.logging.Log4jLogger.<init>(Log4jLogger.java:35)
at org.jboss.logging.Log4jLoggerProvider.getLogger(Log4jLoggerProvider.java:33)
at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:37)
at org.jboss.logging.LoggerProviders.<clinit>(LoggerProviders.java:32)
at org.jboss.logging.Logger.getLogger(Logger.java:2163)
at org.jboss.logging.Logger.getLogger(Logger.java:2188)
at org.jboss.as.arquillian.protocol.jmx.ArquillianServiceDeployer.<clinit>(ArquillianServiceDeployer.java:47)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.jboss.arquillian.core.impl.Reflections.createInstance(Reflections.java:128)
at org.jboss.arquillian.core.impl.ManagerImpl.createExtensions(ManagerImpl.java:410)
at org.jboss.arquillian.core.impl.ManagerImpl.fireProcessing(ManagerImpl.java:345)
at org.jboss.arquillian.core.impl.ManagerImpl.<init>(ManagerImpl.java:98)
... 26 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JBJCA-914) Support @ArquillianResource
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-914:
-------------------------------------
Summary: Support @ArquillianResource
Key: JBJCA-914
URL: https://issues.jboss.org/browse/JBJCA-914
Project: IronJacamar
Issue Type: Task
Components: Arquillian
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.1.0.Beta3
Support
{code}
org.jboss.jca.embedded.Embedded
javax.naming.Context
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month