November 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-1132) Use blocking mode for callbacks with Remoting http transport

by Ron Sigal (JIRA)

Use blocking mode for callbacks with Remoting http transport ------------------------------------------------------------ Key: JBMESSAGING-1132 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1132 Project: JBoss Messaging Issue Type: Task Reporter: Ron Sigal Assigned To: Tim Fox Fix For: 2.0.0 Alpha In response to JBREM-641 "re-implement the callback polling for http transport to reduce latency", an alternative way of handling callbacks was introduced in Remoting. In particular, instead of the client periodically polling for callbacks, in "blocking" mode, the request to download callbacks blocks on the server until either (1) a callback is available, or (2) the timeout period has expired. The advantage is reduced latency in retrieving callbacks. In fact, some JBM http transport stress tests which fail in "nonblocking" mode now pass in "blocking" mode. 1. The default mode is "nonblocking", so it is necessary to explicitly configure "blocking" mode. One way to do so is to add the appropriate parameter to the metadata map when installing the callback listener. E.g., add the following line to org.jboss.jms.client.remoting.JMSRemotingConnection.createCallbackMetadata(): if (reportPollingStatistics != null) { metadata.put(CallbackPoller.REPORT_STATISTICS, reportPollingStatistics); } metadata.put(ServerInvoker.BLOCKING_MODE, ServerInvoker.BLOCKING); // <<=== add this line metadata.put(ServerInvoker.BLOCKING_TIMEOUT, "7777"); // optional: default is 5000 milliseconds 2. The line <attribute name="callbackPollPeriod" isParam="true">102</attribute> may be removed from remoting-http-service.xml, since it's no longer relevant. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

3
8
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1411) Wrong DEFAULT_RECOVER_DELIVERIES_TIMEOUT value

by Takayoshi Kimura (JIRA)

Wrong DEFAULT_RECOVER_DELIVERIES_TIMEOUT value ---------------------------------------------- Key: JBMESSAGING-1411 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1411 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP3_CP01 Reporter: Takayoshi Kimura Assignee: Tim Fox org.jboss.messaging.core.impl.MessagingQueue: DEFAULT_RECOVER_DELIVERIES_TIMEOUT = 5 * 60 * 10000; The last number should be 1000. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1281) JBossBytesMessage generates NullPointerException on 0-byte messages

by Patrick Dolan (JIRA)

JBossBytesMessage generates NullPointerException on 0-byte messages ------------------------------------------------------------------- Key: JBMESSAGING-1281 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1281 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.0.SP3 Environment: JBoss 4.3.0GA on RHEL Reporter: Patrick Dolan Assigned To: Tim Fox Priority: Minor Sometimes we get sent zero-byte BytesMessages through our system via user error or other and when such a message is read by JBoss Messaging and converted into a JBossBytesMessage object, a NullPointerException occurs. The source of the error is in the checkRead method: bais = new ByteArrayInputStream(payloadAsByteArray); In this case the payloadAsByteArray object is not initialized since the message was empty and the BAIS throws a NullPointerException. This is certainly not a high-priority issue but it might be better to either check that condition or throw a more meaningful JMS exception when empty messages are encountered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

3
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1279) ServerSessionEndpoint: Verbose logging

by Jesper Pedersen (JIRA)

ServerSessionEndpoint: Verbose logging -------------------------------------- Key: JBMESSAGING-1279 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1279 Project: JBoss Messaging Issue Type: Task Components: Messaging Core Affects Versions: 1.4.1.CR1 Reporter: Jesper Pedersen Assigned To: Clebert Suconic I'm getting a lot 09:59:21,442 INFO [ServerSessionEndpoint] Received send for ID:JBM-fd27f536-cf76-4280-a367-847d5443f04f reliable: true 09:59:21,456 INFO [ServerSessionEndpoint] Done send with 1.4.1.CR1. Could you change them to TRACE instead ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

3
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1430) org.jboss.jms.server.messagecounter.MessageCounter class is not Serializable

by Ji-Woong Choi (JIRA)

org.jboss.jms.server.messagecounter.MessageCounter class is not Serializable ---------------------------------------------------------------------------- Key: JBMESSAGING-1430 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1430 Project: JBoss Messaging Issue Type: Bug Components: Configuration and Management Affects Versions: 1.4.0.SP3_CP03 Environment: JBoss Messaging 1.4.0 SP3_CP03 in JBoss EAP4.3 HP-UX B11.23 JDK 1.5.0_14 Reporter: Ji-Woong Choi Assignee: Tim Fox Hi~ Tim There is a problem with class serialization of org.jboss.jms.server.messagecounter.MessageCounter during I am making a GUI QueueBrowser outside of JBoss container. I found that MessageCounter class was not implemented java.io.Serializable. I have to get total message count after server startup and current message count in queue for displaying data. This is the access code thru JMX: QueueMBean queueMBean = (QueueMBean) MBeanServerInvocationHandler .newProxyInstance(server, objName, QueueMBean.class, false); currentMessageCount = queueMBean.getMessageCount(); totalMessageCount = queueMBean.getMessageCounter().getCount(); Exception is following : Created LoginContext jboss.messaging.destination:service=Queue,name=testQueue java.lang.reflect.UndeclaredThrowableException at $Proxy1.getMessageCounter(Unknown Source) at com.jboss.monitor.QueueBrowser.retrieve(QueueBrowser.java:49) at com.jboss.monitor.QueueBrowser.main(QueueBrowser.java:69) Caused by: java.io.NotSerializableException: org.jboss.jms.server.messagecounter.MessageCounter at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at java.rmi.MarshalledObject.<init>(MarshalledObject.java:92) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:423) 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:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133) at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197) at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70) at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100) at $Proxy0.getAttribute(Unknown Source) at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:175) ... 3 more Is there any reason for this(not serialization)? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1377) Typo in default HSQL persistence config

by Tim Fox (JIRA)

Typo in default HSQL persistence config --------------------------------------- Key: JBMESSAGING-1377 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1377 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.4.0.SP3_CP03, Stable branch There is a typo in the default HSQL config in JDBCPersistenceManager.java: map.put("CREATE_ID_CACHE", "CREATE TABLE JBM_ID_CACHE (NODE_ID INTEGER, CNTR INTEGER, JBM_ID VARCHAR(255), PRIMARY KEY(NODEID, CNTR))"); should be: map.put("CREATE_ID_CACHE", "CREATE TABLE JBM_ID_CACHE (NODE_ID INTEGER, CNTR INTEGER, JBM_ID VARCHAR(255), PRIMARY KEY(NODE_ID, CNTR))"); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1239) http example should use JNDI via HTTP

by David Smiley (JIRA)

http example should use JNDI via HTTP ------------------------------------- Key: JBMESSAGING-1239 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1239 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP3 Reporter: David Smiley Assigned To: Tim Fox The http example uses the http connector to for JMS transport. However, the example is using the typical JNDI configuration which is jnp's protocol. Instead, a complete HTTP transport should be used, even for JNDI. To fix this, simply change jndi.properties to this: java.naming.factory.initial=org.jboss.naming.HttpNamingContextFactory java.naming.provider.url=http://localhost:8080/invoker/JNDIFactory java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

3
6
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1422) Set clustered to false by default in persistence configs

by Tim Fox (JIRA)

Set clustered to false by default in persistence configs -------------------------------------------------------- Key: JBMESSAGING-1422 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1422 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assignee: Tim Fox Fix For: 1.4.0.SP3.CP04, 1.4.1.GA We should set clustered to false by default in our persistence-service configs. It's a classic user mistake to copy e.g. mysql-persistence-service.xml over to the AS in a non clustered config, but forget to set clustered to false -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1395) Testsuite hangs on windows after SelectorTest

by Phillip Thurmond (JIRA)

Testsuite hangs on windows after SelectorTest --------------------------------------------- Key: JBMESSAGING-1395 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1395 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP3_CP03 Environment: Windows 2003, MySQL DB Reporter: Phillip Thurmond Assigned To: Clebert Suconic Fix For: Stable branch Attachments: ant-launcher.dump, RMITestServer.dump The testsuite hangs after running SelectorTest remotely. This leaves two java processes: the ant launcher process, and the RMITestServer process. Thread dumps from each of these are attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

3
13
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1402) Node failure does not trigger failover for new nodes entering the cluster.

by Jay Howell (JIRA)

Node failure does not trigger failover for new nodes entering the cluster. -------------------------------------------------------------------------- Key: JBMESSAGING-1402 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1402 Project: JBoss Messaging Issue Type: Bug Reporter: Jay Howell Assignee: Tim Fox When a node fails, users are reporting that the failure doesn't trigger a cluster failover. When a member starts back up and tries to join, it experiences a failure trying to reconnect to the downed node causing the container not to start. Users are getting.. 2008-07-18 08:42:53,211 144578 DEBUG [org.jboss.messaging.core.impl.postoffice.GroupMember] (main:) We are the first member of the group so no need to wait for state 2008-07-18 08:42:53,221 144588 INFO [STDOUT] (UpHandler (MPING):) ------------------------------------------------------- GMS: address is 69.52.50.155:7900 ------------------------------------------------------- 2008-07-18 08:42:56,251 147618 WARN [org.jgroups.protocols.pbcast.GMS] (main:) join(69.52.50.155:7900) sent to 69.52.24.96:7900 timed out, retrying 2008-07-18 08:43:02,303 153670 WARN [org.jgroups.protocols.pbcast.GMS] (main:) join(69.52.50.155:7900) sent to 69.52.24.96:7900 timed out, retrying 2008-07-18 08:43:10,791 162158 WARN [org.jgroups.protocols.pbcast.GMS] (main:) join(69.52.50.155:7900) sent to 69.52.24.96:7900 timed out, retrying 2008-07-18 08:43:15,811 167178 WARN [org.jgroups.protocols.pbcast.GMS] (main:) join(69.52.50.155:7900) sent to 69.52.24.96:7900 timed out, retrying 2008-07-18 08:43:20,832 172199 WARN [org.jgroups.protocols.pbcast.GMS] (main:) join(69.52.50.155:7900) sent to 69.52.24.96:7900 timed out, retrying 2008-07-18 08:43:25,852 177219 WARN [org.jgroups.protocols.pbcast.GMS] (main:) join(69.52.50.155:7900) sent to 69.52.24.96:7900 timed out, retrying which occurs every 5 seconds and prevents the container from starting up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

3
11
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2008