[JBoss JIRA] Created: (JBMESSAGING-1851) Failure to send changeRate message results in idle client
by Justin Bertram (JIRA)
Failure to send changeRate message results in idle client
---------------------------------------------------------
Key: JBMESSAGING-1851
URL: https://issues.jboss.org/browse/JBMESSAGING-1851
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.4.0.SP3.CP09
Reporter: Justin Bertram
Assignee: Yong Hao Gao
If a client fails to send a changeRate message, e.g.:
ERROR [org.jboss.jms.client.container.ClientConsumer] Failed to send changeRate message
org.jboss.jms.exception.MessagingNetworkFailureException
at org.jboss.jms.client.delegate.DelegateSupport.handleThrowable(DelegateSupport.java:245)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:205)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:160)
at org.jboss.jms.client.delegate.ClientConsumerDelegate.org$jboss$jms$client$delegate$ClientConsumerDelegate$changeRate$aop(ClientConsumerDelegate.java:138)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$changeRate_N952316153687074823.invokeNext(ClientConsumerDelegate$changeRate_N952316153687074823.java)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$changeRate_N952316153687074823.invokeNext(ClientConsumerDelegate$changeRate_N952316153687074823.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$changeRate_N952316153687074823.invokeNext(ClientConsumerDelegate$changeRate_N952316153687074823.java)
at org.jboss.jms.client.delegate.ClientConsumerDelegate.changeRate(ClientConsumerDelegate.java)
at org.jboss.jms.client.container.ClientConsumer.sendChangeRateMessage(ClientConsumer.java:754)
at org.jboss.jms.client.container.ClientConsumer.checkSendChangeRate(ClientConsumer.java:913)
at org.jboss.jms.client.container.ClientConsumer.access$1300(ClientConsumer.java:56)
at org.jboss.jms.client.container.ClientConsumer$ListenerRunner.run(ClientConsumer.java:1026)
at org.jboss.messaging.util.OrderedExecutorFactory$ChildExecutor.run(OrderedExecutorFactory.java:104)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.rmi.MarshalException: Failed to communicate. Problem during marshalling/unmarshalling; nested exception is:
java.io.EOFException
at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:131)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.handleOtherException(MicroSocketClientInvoker.java:812)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:725)
at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:458)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:141)
at org.jboss.remoting.Client.invoke(Client.java:1935)
at org.jboss.remoting.Client.invoke(Client.java:788)
at org.jboss.remoting.Client.invoke(Client.java:776)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189)
... 18 more
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:375)
at org.jboss.jms.wireformat.JMSWireFormat.read(JMSWireFormat.java:288)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1036)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:694)
... 24 more
The server will never know that the client needs more messages. Therefore the client will just sit there idle while messages on the server accumulate in its subscription.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (LOGTOOL-12) Generated classes should be using a different logger method
by David Lloyd (JIRA)
Generated classes should be using a different logger method
-----------------------------------------------------------
Key: LOGTOOL-12
URL: https://issues.jboss.org/browse/LOGTOOL-12
Project: Log Tool
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: David Lloyd
Fix For: 1.0.0.Beta6
Right now the generated classes are using the errorf/warnf/etc. methods. However using these methods causes an incorrectly-reported source file name/line number/class name/method name in logs which use these formats.
Instead, the logf and logv methods should be used. Specifically, this form:
{noformat}
logger.logf(FQCN, Level.INFO, cause, format, param1, param2, ...);
{noformat}
The FCQN should be a "private static final String" field defined in each logger class and initialized to "LoggerClassName.class.getName()". Be sure to import the org.jboss.logging.Logger.Level class either directly or use it via Logger.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JBAS-9188) Implement support for nested EJBs & WARs in .sar archives
by Richard Opalka (JIRA)
Implement support for nested EJBs & WARs in .sar archives
---------------------------------------------------------
Key: JBAS-9188
URL: https://issues.jboss.org/browse/JBAS-9188
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: EE
Reporter: Richard Opalka
Assignee: Richard Opalka
<opalka> dmlloyd, please review - https://github.com/ropalka/jboss-as/tree/sar-nested-archives-support
<dmlloyd> SAR nested archives, eh? not sure I like the sound of that :)
<opalka> dmlloyd, I'm not sure too
<dmlloyd> what is the motivation and what are the semantics?
<opalka> dmlloyd, we have some legacy tests
<opalka> dmlloyd, and I know that TX team uses .sar archives with nested WS JSE endpoints in it
<opalka> dmlloyd, The tests we have simply include EJB & WAR WS endpoints
<opalka> dmlloyd, in bundled separate archives inside .sar
<dmlloyd> Nihility: what do you think
<opalka> dmlloyd, If we're not going to support it it's fine with me too. But in such case I'd create JBAS jira and we'll mark it as won't fix and I'll exclude the tests with reference to that JIRA
<dmlloyd> my concern is that right now all of our nested deployment code assumes the outer deployment is an EAR
<opalka> dmlloyd, yes I know. In the past there used to be some problems with SAR
<opalka> dmlloyd, for example JNDI doesn't work in web archives bundled in .sar in AS6
<opalka> dmlloyd, maybe U can see some issues here in AS7 too?
<opalka> s/some/similar/
<opalka> dmlloyd, BTW, why do we have support for .sar archives? Was it really required/necessary?
<Nihility> i have no problem with allowing sars to be nested children, as it doesnt really mean much but as deployments that contain children i think we need to discourage that
<dmlloyd> opalka, basically we have SARs for compatibility purposes only. I'm not really that happy that we support them myself
<opalka> Nihility, dmlloyd OK, I'll create feature request JBAS JIRA - implement support for nested EJBs & WARs in .sar archives and will mark it as rejected/won't fix ?
<dmlloyd> yeah I think that's the thing to do, opalka.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months