[JBoss JIRA] Created: (JBAS-6657) managementView.load() fails to merge ServerInfo, ThreadPool, GlobalRequestProcessor, and Host ManagedObjects
by Ian Springer (JIRA)
managementView.load() fails to merge ServerInfo, ThreadPool, GlobalRequestProcessor, and Host ManagedObjects
------------------------------------------------------------------------------------------------------------
Key: JBAS-6657
URL: https://jira.jboss.org/jira/browse/JBAS-6657
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: ProfileService
Reporter: Ian Springer
Assignee: Scott M Stark
Fix For: JBossAS-5.1.0.CR1
These are all MOs that are needed by the Embedded Console.
Here's the log output:
10:47:18,464 DEBUG [ProfileServiceFactory] About to load profile via Management View...
10:47:23,964 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
10:47:23,980 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
10:47:57,870 WARN [ManagementViewImpl] Failed to merged the following runtime ManagedObjects: {jboss.system:type=ServerInfo/jboss.system:type=ServerInfo=ManagedObject{jboss.system:type=ServerInfo}, jboss.web:name=http-127.0.0.1-8080,type=ThreadPool/=ManagedObject{jboss.web:name=http-127.0.0.1-8080,type=ThreadPool}, jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor/=ManagedObject{jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor}, jboss.web:host=127.0.0.1,type=Host/=ManagedObject{jboss.web:host=127.0.0.1,type=Host}}
10:48:00,917 DEBUG [ProfileServiceFactory] Loaded profile via Management View in 42453 milliseconds.
--
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
12 years, 7 months
[JBoss JIRA] Created: (JBAS-8140) Standard JTS-based configuration
by Brian Stansberry (JIRA)
Standard JTS-based configuration
--------------------------------
Key: JBAS-8140
URL: https://jira.jboss.org/browse/JBAS-8140
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Fix For: Unscheduled
This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
>> Would like to have a configuration with JBossTM JTS implementation
>> already installed and optimized for servers that need distributed
>> transactions. Proper transaction management is an advanced topic for
>> JBoss admins and having Redhat's expertise already configured on a
>> server is very reassuring.
--
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
12 years, 7 months
[JBoss JIRA] Created: (JBREM-552) cannot init cause of ClassCastException
by John Mazzitelli (JIRA)
cannot init cause of ClassCastException
---------------------------------------
Key: JBREM-552
URL: http://jira.jboss.com/jira/browse/JBREM-552
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.Beta2 (Boon)
Reporter: John Mazzitelli
Assigned To: Tom Elrod
Priority: Minor
Fix For: 2.0.0.CR1 (Boon)
I'm in a catch clause within InvokerRegistry and I'm getting a weird exception thrown:
java.lang.IllegalStateException: Can't overwrite cause
at java.lang.Throwable.initCause(Throwable.java:320)
at org.jboss.remoting.InvokerRegistry.loadClientInvoker(InvokerRegistry.java:447)
at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:324)
at org.jboss.remoting.Client.connect(Client.java:385)
at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.getRemotingClient(JBossRemotingRemoteCommunicator.java:470)
at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.send(JBossRemotingRemoteCommunicator.java:430)
at org.jboss.on.communications.command.client.AbstractCommandClient.invoke(AbstractCommandClient.java:167)
at org.jboss.on.communications.command.client.ClientCommandSender.send(ClientCommandSender.java:820)
at org.jboss.on.communications.command.client.ServerPollingThread.run(ServerPollingThread.java:102)
Look at line 447 and you'll see it is trying to init the cause of a ClassNotFoundException. Running in a debugger, the newly constructed exception created on 446 has a null cause. Looking then at Throwable.initCause and you'll see a null cause causes this IllegalStateException to be thrown. The cause needs to be "this", not null (I don't know why, seems like it should also look for null, but whatever - that's the way the JDK is written).
The fix is simple - use the constructor that takes a throwable as its second parameter. Not sure why initCause it being used, as opposed to this constructor.
e.g.:
new ClassNotFoundException("Can not invoke loadClientInvokerClass method on " + transportFactoryClass, e);
(notice the ", e" parameter).
There are three other instances where initCause is called on ClassNotFoundException that also need to be fixed. See the other catch clauses in here.
--
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
12 years, 7 months
[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
12 years, 7 months
[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
12 years, 7 months
[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
12 years, 7 months
[JBoss JIRA] Created: (JGRP-816) TP: avoid copying when receiving data
by Bela Ban (JIRA)
TP: avoid copying when receiving data
-------------------------------------
Key: JGRP-816
URL: https://jira.jboss.org/jira/browse/JGRP-816
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
Currently, we receive data into a byte[] buffer, e.g. from DatagramSocket.receive(), but then have to COPY buffer when passing it to a worker from the thread pool. The copy is needed because the next DatargamSocket.receive() will overwrite the contents of buffer, and if the worker thread is still unmarshalling the data from the buffer, it might read corrupt contents.
To overcome this, investigate the following:
- Every worker thread has it own buffer
- When the thread has been idle for N seconds and is removed from the pool, that buffer will be discarded
- We create DatagramChannels from the socket(s) (DatagramSocket, MulticastSocket or Socket)
- A selector is called when new data is available on the socket
- The key returned by the selector points to the right channel
- We pass the channel to a thread pool worker thread and continue with the select() loop
- The worker then reads the data into its own buffer, unmarshalls it and passed it up the stack
==> No copy of the buffer is required as the thread's buffer is available until the message has been processed (usually until message unmarshalling)
--
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
12 years, 7 months