[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Cluster - Destination SecurityConfig Lost
by timfox
So just to clarify, the way clustered temporary destinations currently work is as folllows:
You create a connection on a node, and create the temporary destination. That temp destination is owned by that connection, and only that connection can create consumers on it.
The clustered request / response pattern goes as follows.
The connection sends a message to some other destination (non temporary), the message is consumed, and the consumer sends back a reply to the replyTo which contains the name of the temporary destination.
The consumer of the non temp destination can be on a *different* node to the sending node - this allows processing to be spread across nodes.
The reply can be sent from any node and the reply will make it back to the original sender which is pinned to a particular node.
For this to work, the temporary queue can only be consumed by a single connection otherwise the response correlation wouldn't work.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085342#4085342
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085342
18 years, 6 months
[Deployers on JBoss (Deployers/JBoss)] - Error on jboss server
by worldhelp
Hi,
I have deployed my application on jBoss with Mysql5 Db.
But every few hours getting errors like below and restarting my jboss srever and working fine: what it causes
08:38:28,307 INFO [STDOUT] javax.ejb.EJBException: Transaction marked for rollback - probably a timeout.
08:38:28,307 INFO [STDOUT] at org.jboss.ejb.plugins.lock.SimpleReadWriteEJBLock.checkTransaction(SimpleReadWriteEJBLock.java:326)
08:38:28,307 INFO [STDOUT] at org.jboss.ejb.plugins.lock.SimpleReadWriteEJBLock.waitAWhile(SimpleReadWriteEJBLock.java:205)
08:38:28,307 INFO [STDOUT] at org.jboss.ejb.plugins.lock.SimpleReadWriteEJBLock.getWriteLock(SimpleReadWriteEJBLock.java:183)
08:38:28,307 INFO [STDOUT] at org.jboss.ejb.plugins.lock.SimpleReadWriteEJBLock.schedule(SimpleReadWriteEJBLock.java:89)
08:38:28,307 INFO [STDOUT] at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:206)
08:38:28,307 INFO [STDOUT] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:212)
08:38:28,307 INFO [STDOUT] at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:90)
08:38:28,308 INFO [STDOUT] at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:117)
08:38:28,308 INFO [STDOUT] at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:61)
08:38:28,308 INFO [STDOUT] at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:28)
08:38:28,308 INFO [STDOUT] at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:41)
08:38:28,308 INFO [STDOUT] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:109)
08:38:28,308 INFO [STDOUT] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:313)
08:38:28,308 INFO [STDOUT] at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:126)
08:38:28,308 INFO [STDOUT] at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:101)
08:38:28,308 INFO [STDOUT] at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:121)
08:38:28,309 INFO [STDOUT] at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:93)
08:38:28,309 INFO [STDOUT] at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:508)
08:38:28,309 INFO [STDOUT] at org.jboss.ejb.Container.invoke(Container.java:891)
08:38:28,309 INFO [STDOUT] at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:342)
08:38:28,309 INFO [STDOUT] at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:118)
08:38:28,309 INFO [STDOUT] at $Proxy386.create(Unknown Source)
08:38:28,309 INFO [STDOUT] at net4nuts.mobilemail.sessionbeans.mmaillogs.MMailLogsBean.moRequestResponseLogging(MMailLogsBean.java:135)
08:38:28,309 INFO [STDOUT] at net4nuts.mobilemail.sessionbeans.mmaillogs.MMailLogsBean.moRequestResponseLogging(MMailLogsBean.java:108)
08:38:28,309 INFO [STDOUT] at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
08:38:28,309 INFO [STDOUT] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Please send me the valuable solution if any one have experienced with this kind of errors.Its really appreciate if any one help me out here.
Thanks
Biswajit
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085341#4085341
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085341
18 years, 6 months
[Design of JBoss Profiler] - Re: Exception thrown sorting profile data
by forumer
Start the web application
Click on MBean=Native-Profiler
Invoke
Exercise application
Stop
Go to JBoss-Profiler page
Select the process Id
Keep all boxes checked
Submit
List of Processed XXXX registers displayed
Then there is a line: 20:37:42,765 INFO [STDOUT] sort -
Then a long pause - and then:
20:40:14,171 INFO [STDOUT] ok
20:40:16,421 ERROR [STDERR] java.lang.NullPointerException
20:40:16,421 ERROR [STDERR] at org.jboss.profiler.engine.LogFileEngine.processGC(LogFileEngine.java:840)
20:40:16,421 ERROR [STDERR] at org.jboss.profiler.engine.LogFileEngine.processGCS(LogFileEngine.java:823)
20:40:16,421 ERROR [STDERR] at org.jboss.profiler.engine.LogFileEngine.doProcess(LogFileEngine.java:144)
20:40:16,421 ERROR [STDERR] at org.jboss.profiler.engine.LogFileEngine.doProcess(LogFileEngine.java:79)
20:40:16,421 ERROR [STDERR] at org.jboss.profiler.web.servlets.ServletProcess.doGet(ServletProcess.java:155)
20:40:16,421 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
20:40:16,421 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
20:40:16,421 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterCha
in.java:252)
20:40:16,421 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
173)
20:40:16,421 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
20:40:16,421 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterCha
in.java:202)
20:40:16,421 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
173)
20:40:16,421 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
20:40:16,421 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
20:40:16,421 ERROR [STDERR] at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:5
4)
20:40:16,421 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValv
e.java:174)
20:40:16,421 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
20:40:16,421 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
20:40:16,421 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
20:40:16,421 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
20:40:16,421 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
20:40:16,437 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
20:40:16,437 ERROR [STDERR] at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
(Http11BaseProtocol.java:664)
20:40:16,437 ERROR [STDERR] at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
20:40:16,437 ERROR [STDERR] at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:1
12)
20:40:16,437 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595)
Please let me know if I can provide any more data.
Thanks!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085306#4085306
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085306
18 years, 6 months
[Design of JBoss Remoting, Unified Invokers] - Re: Interruption and the Remoting 3 API
by trustin
If the invocation is interrupted by Thread.interrupt(), throwing InterruptedException would be reasonable, but as you pointed out, it's painful to take care of another catch block.
We could provide both interruptable and uninterruptable invocation methods; invoke and invokeUninterruptably (or invoke and invokeInterruptably) Then user could choose what they want.
What confuses me though is if we are talking about the InterruptedException raised by Thread.interrupt() or any other interruption caused by means such as cancellation request for the invocation. Or are they treated as the same thing? Do we need to discriminate these two cases?
I'd prefer to have a subclass of RemotingException (e.g. CancelledInvocationException) if we need discrimination. Users can deal with the interruption when they really want to do. This will also help users to find out if its interrupted by Thread.interrupt(), any system signal or request for cancellation from the type of the raised exception.
Users will not consider the possibility of the interrupted invocation at all at the first time, but they will start to consider once they see the exception log, so I think it's not a big deal.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085300#4085300
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085300
18 years, 6 months
[Design of JBoss Remoting, Unified Invokers] - Interruption and the Remoting 3 API
by david.lloyd＠jboss.com
Some operations in Remoting 3 might be long-running under normal conditions, and thus it is be desirable to provide a means to interrupt them. This is means is provided by way of allowing the synchronous request methods (and, of course, the methods on Future) to throw InterruptedException. Examples are in the Context, FutureReply, and ReplyContext interfaces.
However there are also methods that may not be long-running under normal circumstances, but might run long under conditions such as network connection problems or heavily loaded servers. Such methods include the transaction control methods (begin/commit/rollback and the XAResource implementation), and probably a few others as well.
So here's the question: should these normally-quick-but-possibly-sometimes-slow methods:
a) throw InterruptedException,
b) translate the InterruptedException into a RemotingException (and keep the thread's interruption status set),
or c) just run uninterruptably (and propagate the thread's interruption status)?
Right now the code is a mishmash of all three. :-)
The advantage of (a) is that the user's code can be the most "correct" in its handling of interruption. Which is to say, interruption stops execution (more or less) immediately, and is easy to detect. On the other hand, it is pretty unlikely that it will happen, and if there's one good way to annoy users, it is to make them write handlers for things that don't happen often.
Option (b) has the advantage of being simpler to code for the user. The operation is still stopped immediately. But it's harder now to figure out that it was due to interruption. Probably the user will never even consider that possibility. I don't know if this is a disadvantage in *practical* terms though.
Option (c) is the easiest of all for the user - but it makes it impossible for the user to stop the operation using interruption, in the unlikely event that it runs long.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085281#4085281
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085281
18 years, 6 months