[Datasource Configuration] - MySQL problem with multiple instances of JBOSS
by Unmesh Kulkarni
Unmesh Kulkarni [http://community.jboss.org/people/unmesh_kulkarni] created the discussion
"MySQL problem with multiple instances of JBOSS"
To view the discussion, visit: http://community.jboss.org/message/584318#584318
--------------------------------------------------------------
I have setup two IPs on my machine.
eth0 Link encap:Ethernet HWaddr 00:0C:29:B3:6B:25
inet addr:192.168.6.128 Bcast:192.168.6.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:feb3:6b25/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:921323 errors:0 dropped:0 overruns:0 frame:0
TX packets:127221 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:721968842 (688.5 MiB) TX bytes:12898679 (12.3 MiB)
eth0:1 Link encap:Ethernet HWaddr 00:0C:29:B3:6B:25
inet addr:192.168.6.129 Bcast:192.168.6.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
I am starting up two instances of JBOSS AS 6.0.0 Final on the same server using -b option.
/etc/jboss-as/testenv1/bin/run.sh -c testenv1 -b 192.168.6.128
/etc/jboss-as/testenv2/bin/run.sh -c testenv2 -b 192.168.6.129
I have two databases, *testenv1* & *testenv2* on MySQL Server installed on same machine.
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| test |
| testenv1 |
| testenv2 |
+--------------------+
Also I have two dedicated users testenv1 and testenv2 for connecting those databases.
+----------+---------------+
| user | host |
+----------+---------------+
| admin | % |
| root | 127.0.0.1 |
| *testenv1 | 192.168.6.128 |*
| *testenv2 | 192.168.6.129 |*
| | JBOSS-SS |
| root | JBOSS-SS |
| | localhost |
| root | localhost |
+----------+---------------+
They have been setup such a way that testenv1 user will have access to tesnv1 database from 192.168.6.128 and
testenv2 user will have access to testenv2 databse from 192.168.6.129.
I have attached datasource files which I am using.
Here is a code which i have deployed on both the servers for testing JDBC connectivity
<%
DataSource ds = null;
Connection con = null;
PreparedStatement pr = null;
InitialContext ic;
try {
ic = new InitialContext();
ds = (DataSource)ic.lookup( "java:/MySqlDS" );
con = ds.getConnection();
pr = con.prepareStatement("SELECT * FROM jdbctest");
ResultSet rs = pr.executeQuery();
while (rs.next()) {
out.println("<br> " +rs.getString("comp_inst_status"));
}
rs.close();
pr.close();
}catch(Exception e){
out.println("Exception thrown " +e);
}finally{
if(con != null){
con.close();
}
} %>
When I access my JSP from first instance (i.e. 192.168.6.128 ) it works fine but when I access it from other server it fails. It gives following exception
*Caused by: java.sql.SQLException: Access denied for user 'testenv2'@'**192.168.6.128**' (using password: YES)*
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073) [:]
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3593) [:]
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3525) [:]
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:931) [:]
at com.mysql.jdbc.MysqlIO.secureAuth411(MysqlIO.java:4031) [:]
at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1296) [:]
at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2338) [:]
at com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2371) [:]
at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2163) [:]
at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:794) [:]
at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:47) [:]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [:1.6.0_23]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [:1.6.0_23]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [:1.6.0_23]
at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [:1.6.0_23]
at com.mysql.jdbc.Util.handleNewInstance(Util.java:407) [:]
at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:378) [:]
at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:305) [:]
As the user testenv2 is not having access rights from *192.168.6.128* it throws exception.
But I have bound testenv2 instance on 192.168.6.129 but still it tries to access MySQL from 192.168.6.128.
Any idea if I am missing anything in configuration?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/584318#584318]
Start a new discussion in Datasource Configuration at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 2 months
[JBoss Remoting] - ClassCastException under heavy load
by Markus Falk
Markus Falk [http://community.jboss.org/people/cornhoolio22] created the discussion
"ClassCastException under heavy load"
To view the discussion, visit: http://community.jboss.org/message/584322#584322
--------------------------------------------------------------
Hi,
I'm looking at the same problems as described here:
http://community.jboss.org/thread/111357 http://community.jboss.org/thread/111357
Under heavy load ClassCastExceptions are thrown.
The situation:
2 ears on one server (4.2.3, jbm 1.4.5, jboss-remoting 2.2.3.SP1) calling the same ejb on another appserver (same configuration) with the same value object.
When producing heavy load on ear 1 (10 threads parallel as clients) and then calling one time ear 2, a ClassCastException is thrown. Will list it below the text.
I found a fix for the problem in https://issues.jboss.org/browse/JBREM-900 https://issues.jboss.org/browse/JBREM-900. This fix seems not to be in the 2.2.3SP1 nor in the 2.2.3.SP3 release.
I also read in the JIRA ( http://community.jboss.org/message/583757#583757 http://community.jboss.org/message/583757) that there will be a 2.2.3SP4 release (hope soon ;-) ) and found a preversion from Ron ( https://issues.jboss.org/browse/JBREM-1144 https://issues.jboss.org/browse/JBREM-1144). But the fix is also not in there (the test fails again).
When I use the 2.4.0.SP1 remoting version, the test succeeds. But the Messaging System is not able to work with this version, because of changes in the Client class (the connect method params were changed).
Is it possible, to release the Bugfix described in https://issues.jboss.org/browse/JBREM-900 https://issues.jboss.org/browse/JBREM-900 with the 2.2.3.SP4 release?
Thx and Regards,
Markus
javax.ejb.EJBException: java.lang.ClassCastException:
org.cornhoolio22.ejbclassloadertestservice.ejbclassloadertestservice_calledclient.dto.CalledDto cannot be cast to org.cornhoolio22.ejbclassloadertestservice.ejbclassloadertestservice_calledclient.dto.CalledDto
at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:63)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at com.oneandone.coredev.swistec.cxfinterceptor.CxfInterceptorSpringBusCleanup.invoke(CxfInterceptorSpringBusCleanup.java:109)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:304)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:900)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:634)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:409)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:176)
Caused by: java.lang.ClassCastException: org.cornhoolio22.ejbclassloadertestservice.ejbclassloadertestservice_calledclient.dto.CalledDto cannot be cast to org.cornhoolio22.ejbclassloadertestservice.ejbclassloadertestservice_calledclient.dto.CalledDto
at $Proxy336.callService(Unknown Source)
at org.cornhoolio22.ejbclassloadertestservice.ejbclassloadertestservice_callejb2.impl.ServiceBean.callService(ServiceBean.java:38)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at com.oneandone.coredev.swistec.cxfinterceptor.CxfInterceptorSpringBusCleanup.invoke(CxfInterceptorSpringBusCleanup.java:109)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:304)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:900)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:634)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:409)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:176)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
at org.jboss.remoting.Client.invoke(Client.java:1634)
at org.jboss.remoting.Client.invoke(Client.java:548)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)
at $Proxy4.callService(Unknown Source)
at org.cornhoolio22.ejbclassloadertestservice.ejbclassloadertestservice_callejb2.SampleServiceTestCall3.testSampleServiceCall3(SampleServiceTestCall3.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)
at $Proxy4.callService(Unknown Source)
at org.cornhoolio22.ejbclassloadertestservice.ejbclassloadertestservice_callejb2.SampleServiceTestCall3.testSampleServiceCall3(SampleServiceTestCall3.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/584322#584322]
Start a new discussion in JBoss Remoting at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 2 months
[JBoss Tools] - Some Experiences with JBoss Tools, Eclipse Helios and M2E
by Thomas Kriechbaum
Thomas Kriechbaum [http://community.jboss.org/people/Thomas.Kriechbaum] created the discussion
"Some Experiences with JBoss Tools, Eclipse Helios and M2E"
To view the discussion, visit: http://community.jboss.org/message/580245#580245
--------------------------------------------------------------
Hello,
what are your experiences with JBoss Tools (1.1.0..-Beta2 maven-feature, 2.2.0..-beta2 as-feature), Eclipse Helios (3.6.1), JBoss AS 6 Final and M2Eclipse (0.10.2, 0.11.1 wtp-feature)?
At the moment, I'm facing the following problems:
* context root of web-module
* republish after changes
* module name is part of global JNDI name
For testing purposes I have created some maven modules with m2e.
business (root module)
+ business-ear (application.xml is generated)
+ business-core (ejb module containing the EJB implementation)
+ business-services (ejb client view)
+ business-ws (web module containing a WS that references the local EJB)
ticket (root module)
+ ticket-ear (application.xml is generated)
+ ticket-core (ejb module containing the EJB implementation)
+ ticket-services (ejb client view)
*context root of the web-module*
Although business-ear/pom.xml contains a specific context-root, the web-module is only accessible under module-name-version (e.g. business-ws-1.0.0)
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<version>5</version>
<generateApplicationXml>true</generateApplicationXml>
<modules>
<ejbModule>
<groupId>org.foo</groupId>
<artifactId>business-core</artifactId>
</ejbModule>
<webModule>
<groupId>org.foo</groupId>
<artifactId>business-ws</artifactId>
<contextRoot>business-services_v1_0</contextRoot>
</webModule>
</modules>
</configuration>
</plugin>
Do I have to provide some specific settings/configuration in this case?
*republish after changes*
The republishing of JEE modules (e.g. WS-Implementation within the web-module) works only, if I perform a "project > clean" on all maven modules. In this case, all maven modules get redeployed correctly. Otherwise, the server state shortly changes to "republish", but the server does not reload the components (=> service behaviour does not change!).
Do I have to change any Eclipse settings to avoid "project > clean" after any changes?
*module name is part of global JNDI name*
AFAIK, the EAR name is part of the EJBs global JNDI name.
For example:
TicketService - EJB3.x Default Remote Business Interface
ticket-ear/TicketServiceBean/remote-at.logis.was.ticket.TicketService - EJB3.x Remote Business Interface
This global name is used to reference this EJB via injection
@EJB(mappedName="ticket-ear/TicketServiceBean")
private TicketService ticketService;
Within Eclipse, the module's version number is not recognized. But when building the components at command line, the version number is added to the EAR by default (e.g. ticket-ear-1.0.0). Therefore, the mapped-name has to be changed to “ticket-ear-1.0.0/TicketServiceBean” before. From my point of view, it is good to have version numbers to support parallel installation of different versions. But how can I tell Eclipse/M2E/... to use version numbers within my workspace as well?
Thanks,
Thomas
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/580245#580245]
Start a new discussion in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 2 months
[JBoss Remoting] - LeasePinger, sessionId, jboss messaging
by Mark Torres
Mark Torres [http://community.jboss.org/people/mark_v_torres] created the discussion
"LeasePinger, sessionId, jboss messaging"
To view the discussion, visit: http://community.jboss.org/message/577764#577764
--------------------------------------------------------------
Hi,
We're experiencing intermittent connection issues with jboss messaging.
Client
jboss app server 4.2.3.GA
jboss messaging 1.4.5.GA
jboss remoting 2.2.3.SP3
Server
jboss app server 4.2.3.GA
jboss messaging 1.4.5.GA
jboss remoting 2.2.3.SP3
We've set up an exception listener on the client side that "reconnects" upon failure. However, we do get into situations where the connection becomes dead on the server side, but the exception listener does not fire on the client side.
We're able to recreate the issue locally when we pause the client...
kill -s STOP <pid>
wait till the server detects and disconnects the client, and resume the client
kill -s CONT <pid>
I tried tracing the issue and come across a possible cause...
During the resume, 2 ping threads awake, one for LeasePinger and one for ConnectionValidator
LeasePinger does not set ServerInvoker.INVOKER_SESSION_ID on the requestPayload map, but ConnectionValidator.doCheckConnectionWithLease does.
On the server side, ServerInvoker.invoke, if ServerInvoker.INVOKER_SESSION_ID is not in the requestPayloadMap, the server creates/updates the lease.
I think the issue happens when the LeasePinger thread fires before the ConnectionValidator thread.
Can you please give us insights on how we can overcome this problem.
I attached the remoting-bisocket config on the server side.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/577764#577764]
Start a new discussion in JBoss Remoting at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 2 months
[jBPM] - JBPM 4.4 - exception recovery
by Yuriy Fuksenko
Yuriy Fuksenko [http://community.jboss.org/people/yfuksenk] created the discussion
"JBPM 4.4 - exception recovery"
To view the discussion, visit: http://community.jboss.org/message/576183#576183
--------------------------------------------------------------
I have a Spring based web application with JBPM embeded.
I defined a workflow, that have a task followed by 3 custom activities:
activity1 - calls webservice
activity2 - sends email
activity3 - sends JMS message
At some point my application calls taskService.finishTask, and those activities will be executed.
What I need, is in a case of error (let say SMTPserver is unreachable or web service is not up):
1. Activity should be retried until it succeed (I understand that a lot of logic could be suggested around this, like retry count, notifications, etc, but I am simplifying this on purpose)
2. Activities that succeeded should not be repeated, i.e. if activity2 fails, activity1 should not be executed again (and this is what happens now if any of those activities throws an exception - I guess it has to do with transaction being rolled back)
So my question is - Is there an easy or at least standard way of doing this in JBPM?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/576183#576183]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 2 months