[JBoss JIRA] Created: (JBWEB-186) Using the native connector causes the JVM to crash when shutting down on Windows
by Mike Millson (JIRA)
Using the native connector causes the JVM to crash when shutting down on Windows
--------------------------------------------------------------------------------
Key: JBWEB-186
URL: https://jira.jboss.org/browse/JBWEB-186
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core
Affects Versions: JBossWeb-3.0.0.Beta7
Reporter: Mike Millson
Assignee: Remy Maucherat
Boss server is crashing with an "EXCEPTION_ACCESS_VIOLATION" once shutdown has started.
Setting a breakpoint in AccessLogValve.invoke() then doing shutdown, then releasing the break point crashes the JVM.
The fatal error log shows the following:
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0d74c90e, pid=3204, tid=5944
#
# JRE version: 6.0_20-b02
# Java VM: Java HotSpot(TM) Server VM (16.3-b01 mixed mode windows-x86 )
# Problematic frame:
# C [libapr-1.dll+0xc90e]
#
...
Current thread (0x05973400): JavaThread "http-127.0.0.1-8080-2" daemon [_thread_in_native, id=5944, stack(0x0efe0000,0x0f030000)]
...
Stack: [0x0efe0000,0x0f030000], sp=0x0f02f628, free space=13d0f02f15ck
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libapr-1.dll+0xc90e]
C [libtcnative-1.dll+0x1150]
j org.apache.tomcat.jni.Address.get(IJ)J+0
j org.apache.coyote.http11.Http11AprProcessor.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V+196
j org.apache.coyote.Request.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V+56
j org.apache.catalina.connector.Request.getRemoteAddr()Ljava/lang/String;+18
j org.apache.catalina.connector.Request.getRemoteHost()Ljava/lang/String;+19
j org.apache.catalina.valves.AccessLogValve$HostElement.addElement(Ljava/lang/StringBuffer;Ljava/util/Date;Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;J)V+2
j org.apache.catalina.valves.AccessLogValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V+115
...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (JGRP-1194) Revisit implementation of TUNNEL and shared transport
by Vladimir Blagojevic (JIRA)
Revisit implementation of TUNNEL and shared transport
-----------------------------------------------------
Key: JGRP-1194
URL: https://jira.jboss.org/jira/browse/JGRP-1194
Project: JGroups
Issue Type: Task
Affects Versions: 2.9, 2.8
Reporter: Vladimir Blagojevic
Assignee: Vladimir Blagojevic
Fix For: 3.0
TUNNEL and shared transport are not supported at the moment (2.10.Alpha5). The main complexity behind TUNNEL and shared transport is that we have to change StubReceiver model. StubReceiver reads messages of the socket on the TUNNEL side. With shared transport turned on StubReceiver would have to be changed because we are receiving byte arrays for all channels sharing transport. We need some special StubReceiver multiplexer so to speak which will read messages and then pass off the byte arrays to other Receivers which will in turn pass them as messages to appropriate channel above transport. Each byte array passed around have to be pre appended with some identifier....and so on.
--
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
13 years, 1 month
[JBoss JIRA] Created: (AS7-718) Jboss AS 7 request a version of tcnative that has not been released yet.
by Sebastian Otaegui (JIRA)
Jboss AS 7 request a version of tcnative that has not been released yet.
-------------------------------------------------------------------------
Key: AS7-718
URL: https://issues.jboss.org/browse/AS7-718
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.0.0.Beta3
Environment: ubuntu 11.04
x64
Reporter: Sebastian Otaegui
Assignee: Jason Greene
Priority: Trivial
Fix For: Open To Community
Jboss AS 7 request a version of tcnative that has not been released yet.
16:27:12,920 INFO [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-4) An older version 1.1.20 of the Apache Tomcat Native library is installed, while Tomcat recommends version greater then 1.1.21
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (JBAS-9273) Support for ls of a leaf node in admin console equating to :read-resouce
by Scott Stark (JIRA)
Support for ls of a leaf node in admin console equating to :read-resouce
------------------------------------------------------------------------
Key: JBAS-9273
URL: https://issues.jboss.org/browse/JBAS-9273
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: CLI
Affects Versions: 7.0.0.Beta2
Reporter: Scott Stark
I was taking the cli jboss-admin.sh tool for a test drive, and using ls and tab completion to navigate down to the socket-binding-group=standard-sockets/socket-binding=http leaf, and was expecting an ls or at least an ls -l to display the attributes. Brian noted this might be expected, so this request is to have the ls dump out the leaf attributes as though a :read-resource operation was performed on the node.
[localhost:9999 /] ls
extension path subsystem
deployment management-interfaces interface
socket-binding-group
[localhost:9999 /] ls socket-binding-group=standard-sockets/socket-binding=
socket-binding=http
socket-binding=https
socket-binding=jmx-connector-registry
socket-binding=jmx-connector-server
socket-binding=jndi
socket-binding=messaging
socket-binding=messaging-throughput
socket-binding=osgi-http
socket-binding=remoting
socket-binding=txn-recovery-environment
socket-binding=txn-socket-process-id
socket-binding=txn-status-manager
[localhost:9999 /] ls socket-binding-group=standard-sockets/socket-binding=http
[localhost:9999 /] ls -l socket-binding-group=standard-sockets/socket-binding=http
[localhost:9999 /]
[localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=http:read-resource
{
"outcome" => "success",
"result" => {
"name" => "http",
"interface" => undefined,
"port" => 8080,
"fixed-port" => undefined,
"multicast-address" => undefined,
"multicast-port" => undefined
},
"compensating-operation" => undefined
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (JBMESSAGING-1836) java.lang.IllegalStateException: Channel id map for node 21 already contains binding for queue 2
by Mayank Mittal (JIRA)
java.lang.IllegalStateException: Channel id map for node 21 already contains binding for queue 2
------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1836
URL: https://issues.jboss.org/browse/JBMESSAGING-1836
Project: JBoss Messaging
Issue Type: Bug
Components: JMS Clustering
Affects Versions: 1.4.2.GA.SP1
Environment: JBoss AS 4.2.3,
Database PostgreSQL 8.4
JGroups 2.4.4GA
OS Debian Lenny 64-bit
Reporter: Mayank Mittal
I tried to setup 2 node cluster setup on Debian Linux Machines with Jboss AS 4.2.3 GA with shared database.
I've some clustered queues deployed and whenever I perform fail over following exception is coming from MessagingPostOffice.
The same exception is coming for all queues and topics.
java.lang.IllegalStateException: Channel id map for node 21 already contains binding for queue 2
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.addBindingInMemory(MessagingPostOffice.java:2384)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.internalAddBinding(MessagingPostOffice.java:1872)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.addBinding(MessagingPostOffice.java:454)
at org.jboss.jms.server.destination.QueueService.startService(QueueService.java:126)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
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.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304)
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.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy52.start(Unknown Source)
at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy9.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:508)
at java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (JGRP-809) Copyless stack
by Bela Ban (JIRA)
Copyless stack
--------------
Key: JGRP-809
URL: https://jira.jboss.org/jira/browse/JGRP-809
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
Currently (as of 2.7), the transport reads the contents of a received packet into a buffer, then passes a *copy* of the buffer to a thread from the OOB or incoming thread pools. To prevent this copy, we can
- have the receiver read only the version and OOB flag (to see which thread pool to dispatch the packet to)
- pass a ref to the socket to a thread from the incoming of OOB pool, have that thread read the packet and return
- each thread in the pool has its own buffer into which the buffer is read from the socket
Possibly use NIO: we can install a selector and get woken up whenever data to be read is present. At that point, we can pass the ref to the socket to the handler thread and return immediately. NIO with channels for multicast sockets is available only in JDK 7 (or 8?), so this is a bit off... However, we can already implement this with reading the version and flags bytes and then passing the socket to the handler
--
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
13 years, 1 month
[JBoss JIRA] Created: (JGRP-815) Scatter/Gather to avoid copying
by Bela Ban (JIRA)
Scatter/Gather to avoid copying
-------------------------------
Key: JGRP-815
URL: https://jira.jboss.org/jira/browse/JGRP-815
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
When we invoke Channel.send(), we pass a bufffer to JGroups. At the transport level, JGroups marshals the sender and destination address, plus all headers and the buffer into a new byte[] buffer, which is then passed to the socket (DatagramSocket, MulticastSocket, Socket).
We cannot do gathering writes on a DatagramSocket because DatagramSocket doesn't expose this functionality, contrary to a DatagramChannel.
We could avoid having to copy the user's buffer by using gathering writes: effectively passing to the socket NIO ByteBuffers containing:
1: Src and dest address plus flags, plus possibly size
2: The marshalled headers
3: The buffer passed to JGroups by the user
We can obtain a gathering-write channel as follows:
ByteBuffer[] buffers; // contains the 3 byte buffers above
DatagramSocket sock;
DatagramChannel ch=sock.getChannel();
ch.write(buffers, 0, length); // length is the number of bytes of the total marshalled message
This is supported by a GatheringByteChannel.
I don't think there's currently a need to do scattered reads, but this needs to get investigated more. Also investigate whether MulticastSockets support gathering writes (whether they expose the correct DatagramChannel).
--
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
13 years, 1 month