[JBoss JIRA] (JBEE-135) JAXWS SPI Provider should use ServiceLoader within a privileged block
by Alessio Soldano (JIRA)
Alessio Soldano created JBEE-135:
------------------------------------
Summary: JAXWS SPI Provider should use ServiceLoader within a privileged block
Key: JBEE-135
URL: https://issues.jboss.org/browse/JBEE-135
Project: JBoss JavaEE Spec APIs
Issue Type: Bug
Components: jboss-jaxws-api
Reporter: Alessio Soldano
Assignee: Alessio Soldano
The JAXWS SPI Provider uses ServiceLoader to look for user specified provider implementations. The search is performed using the current TCCL.
When iterating on the ServiceLoader results, read permission on the relevant jar is required. It looks correct to run in a privileged block there, also considering that the user would need a permission for setting/changing the TCCL.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1725) Update The Wildfly High Availability Guide
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-1725?page=com.atlassian.jira.plugin.... ]
Scott Marlow edited comment on WFLY-1725 at 7/19/13 4:30 PM:
-------------------------------------------------------------
We did make changes in Hibernate to allow serialization/deserializaton but I wouldn't call that "Hibernate level clustering". We should definitely talk about how we can cluster EJB session beans that have an extended persistence context and the requirements (e.g. stateful session bean must be serializable). I can help with this :)
In the part about migration from AS 5.x, we might want to cover *what* applications that directly use http://docs.jboss.org/jbossas/javadoc/4.0.1-sp1/cluster/org/jboss/ha/fram..., should instead use for their clustered rpc calls.
was (Author: smarlow):
We did make changes in Hibernate to allow serialization/deserializaton but I wouldn't call that "Hibernate level clustering". We should definitely talk about how we can cluster EJB session beans that have an extended persistence context and the requirements (e.g. stateful session bean must be serializable).
In the part about migration from AS 5.x, we might want to cover *what* applications that directly use http://docs.jboss.org/jbossas/javadoc/4.0.1-sp1/cluster/org/jboss/ha/fram..., should instead use for their clustered rpc calls.
> Update The Wildfly High Availability Guide
> -------------------------------------------
>
> Key: WFLY-1725
> URL: https://issues.jboss.org/browse/WFLY-1725
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha3
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 8.0.0.Beta1
>
>
> The main source of clustering-related documentation for a Wildfly user is the High Availability Guide in the Wildfly 8 documentation on docs.jboss.org.
> Update this document into a quality document which will aid the user's understanding of new features and configuration in Wildfly 8 clustering.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1725) Update The Wildfly High Availability Guide
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-1725?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-1725:
------------------------------------
We did make changes in Hibernate to allow serialization/deserializaton but I wouldn't call that "Hibernate level clustering". We should definitely talk about how we can cluster EJB session beans that have an extended persistence context and the requirements (e.g. stateful session bean must be serializable).
In the part about migration from AS 5.x, we might want to cover *what* applications that directly use http://docs.jboss.org/jbossas/javadoc/4.0.1-sp1/cluster/org/jboss/ha/fram..., should instead use for their clustered rpc calls.
> Update The Wildfly High Availability Guide
> -------------------------------------------
>
> Key: WFLY-1725
> URL: https://issues.jboss.org/browse/WFLY-1725
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha3
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 8.0.0.Beta1
>
>
> The main source of clustering-related documentation for a Wildfly user is the High Availability Guide in the Wildfly 8 documentation on docs.jboss.org.
> Update this document into a quality document which will aid the user's understanding of new features and configuration in Wildfly 8 clustering.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-878) Message-Driven Beans doesn't support DeliveryActive activation config property
by Kyle Lape (JIRA)
[ https://issues.jboss.org/browse/WFLY-878?page=com.atlassian.jira.plugin.s... ]
Kyle Lape updated WFLY-878:
---------------------------
Comment: was deleted
(was: Kyle Lape <klape(a)redhat.com> made a comment on [bug 981341|https://bugzilla.redhat.com/show_bug.cgi?id=981341]
>From what I can tell the JMX/MBean method of starting/stopping MDB delivery will never be implemented. The fix provided via WFLY-878 does include new CLI operations to start/stop delivery of messages to individual MDBs, though, so perhaps the name of the BZ should be updated.)
> Message-Driven Beans doesn't support DeliveryActive activation config property
> ------------------------------------------------------------------------------
>
> Key: WFLY-878
> URL: https://issues.jboss.org/browse/WFLY-878
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB, JMS
> Environment: Windows 64 bit
> Reporter: Prasad Deshpande
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.Alpha3
>
>
> I get this warning on AS7.1.1 console, seems that ActivationConfigProperty DeliveryActive is not implemented by hornetq-ra, could we please have it as earlier JMS implementation of JMS had it & application that were using it will fail with AS7 now..?
> 16:04:30,794 WARN [org.jboss.ejb3] (MSC service thread 1-16) JBAS014105: ActivationConfigProperty DeliveryActive will be ignored since it is not allowed by resource adapter: hornetq-ra
> Thanks,
> Prasad
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1725) Update The Wildfly High Availability Guide
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1725?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-1725 at 7/19/13 3:54 PM:
--------------------------------------------------------------------
I think the only thing we really need to agree on is what is in and what is not in with regard to content for the High Availability Guide.
For example, in the EAP docs (https://access.redhat.com/site/documentation/JBoss_Enterprise_Application...), the coverage of content is broken down into separate guides, and each guide has its own specific coverage:
* administration & configuration guide (starting/stopping/managing/deploying/configuring)
* api documentation (javadoc for all classes)
* development guide (key technologies: maven build/CDI/Hibernate/Web server/JTA/EJB/Clustering)
* installation guide (download/install/start/stop/upgrade)
* migration guide (migrate app from 5.1 to 6/migration changes/debugging migration problems)
* security guide (everything about configuring security)
Of course, we don't need this level of comprehensiveness in a project guide.
was (Author: rachmato):
I think the only thing we really need to agree on is what is in and what is not in with regard to content for the High Availability Guide.
For example, in the EAP docs (https://access.redhat.com/site/documentation/JBoss_Enterprise_Application...), the coverage of content is broken down into separate guides, and each guide has its own specific coverage:
* administration & configuration guide (starting/stopping/managing/deploying/configuring)
* api documentation (javadoc for all classes)
* development guide (key technologies: maven build/CDI/Hibernate/Web server/JTA/EJB/Clustering)
* installation guide (download/install/start/stop/upgrade)
* migration guide (migrate app from 5.1 to 6/migration changes/debugging migration problems)
* security guide (everything about configuring security)
Of course, we don't need this level of comprehensiveness.
My proposal would be like a section breakdown like this:
* introdction (brief overview of all features provided and how they relate to each other as a unified clustering subsystem)
* changes since AS7 (undertow, refactoring of apis/modules)
* individual subsystems and their configuration
** jgroups
** infinispan
** ejb
** undertow
** mod cluster
* functional areas (notes on configuring them, some developer related issues)
** web session clustering
** ejb clustering
** Hibernate 2LC
** load balancing
* modularity and class loading for app developers
> Update The Wildfly High Availability Guide
> -------------------------------------------
>
> Key: WFLY-1725
> URL: https://issues.jboss.org/browse/WFLY-1725
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha3
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 8.0.0.Beta1
>
>
> The main source of clustering-related documentation for a Wildfly user is the High Availability Guide in the Wildfly 8 documentation on docs.jboss.org.
> Update this document into a quality document which will aid the user's understanding of new features and configuration in Wildfly 8 clustering.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1725) Update The Wildfly High Availability Guide
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1725?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-1725:
-------------------------------------------
My proposal would be like a section breakdown like this:
* introdction (brief overview of all features provided and how they relate to each other as a unified clustering subsystem)
* changes since AS7 (undertow, refactoring of apis/modules)
* individual subsystems and their configuration
** jgroups
** infinispan
** ejb
** undertow
** mod cluster
* functional areas (notes on configuring them, some developer related issues)
** web session clustering
** ejb clustering
** Hibernate 2LC
** load balancing
* modularity and class loading for app developers
> Update The Wildfly High Availability Guide
> -------------------------------------------
>
> Key: WFLY-1725
> URL: https://issues.jboss.org/browse/WFLY-1725
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha3
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 8.0.0.Beta1
>
>
> The main source of clustering-related documentation for a Wildfly user is the High Availability Guide in the Wildfly 8 documentation on docs.jboss.org.
> Update this document into a quality document which will aid the user's understanding of new features and configuration in Wildfly 8 clustering.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (JGRP-1663) TimeScheduler3 could spawn too many threads
by Igor Mazur (JIRA)
[ https://issues.jboss.org/browse/JGRP-1663?page=com.atlassian.jira.plugin.... ]
Igor Mazur commented on JGRP-1663:
----------------------------------
We have quite big cluster with several datacenters and connection between datacenters sometimes fall. And between datacenters we use TCP.
It is probably first time when we got such error. Below a piece of thread dump:
Timer temp thread-19917,global,_index-subscriber tid=20526 [WAITING] [DAEMON]
java.util.concurrent.locks.ReentrantLock.lockInterruptibly()
org.jgroups.blocks.TCPConnectionMap$Mapper.getConnection(Address)
org.jgroups.blocks.TCPConnectionMap.send(Address, byte[], int, int)
org.jgroups.protocols.TCP.send(Address, byte[], int, int)
org.jgroups.protocols.BasicTCP.sendUnicast(PhysicalAddress, byte[], int, int)
org.jgroups.protocols.TP.sendToSingleMember(Address, byte[], int, int)
org.jgroups.protocols.TP.doSend(Buffer, Address, boolean)
org.jgroups.protocols.TP.send(Message, Address, boolean)
org.jgroups.protocols.TP.down(Event)
org.jgroups.protocols.Discovery$1.run()
org.jgroups.util.TimeScheduler3$Task.run()
java.lang.Thread.run()
Timer temp thread-19918,global,_index-subscriber tid=20527 [WAITING] [DAEMON]
java.util.concurrent.locks.ReentrantLock.lockInterruptibly()
org.jgroups.blocks.TCPConnectionMap$Mapper.getConnection(Address)
org.jgroups.blocks.TCPConnectionMap.send(Address, byte[], int, int)
org.jgroups.protocols.TCP.send(Address, byte[], int, int)
org.jgroups.protocols.BasicTCP.sendUnicast(PhysicalAddress, byte[], int, int)
org.jgroups.protocols.TP.sendToSingleMember(Address, byte[], int, int)
org.jgroups.protocols.TP.doSend(Buffer, Address, boolean)
org.jgroups.protocols.TP.send(Message, Address, boolean)
org.jgroups.protocols.TP.down(Event)
org.jgroups.protocols.Discovery$1.run()
org.jgroups.util.TimeScheduler3$Task.run()
java.lang.Thread.run()
> TimeScheduler3 could spawn too many threads
> -------------------------------------------
>
> Key: JGRP-1663
> URL: https://issues.jboss.org/browse/JGRP-1663
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.3
> Reporter: Igor Mazur
> Assignee: Bela Ban
> Priority: Optional
> Fix For: 3.4
>
>
> With default timer thread pool settings this code could spawn thousands of threads:
> protected void submitToPool(final Task entry) {
> try {
> pool.execute(entry);
> }
> catch(RejectedExecutionException rejected) { // only thrown if rejection policy is "abort"
> Thread thread=timer_thread_factory != null?
> timer_thread_factory.newThread(entry, "Timer temp thread")
> : new Thread(entry, "Timer temp thread");
> thread.start();
> }
> }
> On my environment I got 19000 threads.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1725) Update The Wildfly High Availability Guide
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1725?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-1725 at 7/19/13 3:53 PM:
--------------------------------------------------------------------
Some other aspects:
I think adequate framing of sections is important together with well defined and ordered subsections (i.e. introduction and overview, followed by sections with more specific detail)
I also think that consistency of presentation across sections is important, as we move through
* different subsystems
* different collections of functionality
So, for example, touch on the same classes of points in each section (e.g. new features, configuration detail, example)
By the way, for an excellent example, I look to the ISPN docs.
was (Author: rachmato):
Some other aspects:
I think adequate framing of sections is important together with well defined and ordered subsections (i.e. introduction and overview, followed by sections with more specific detail)
I also think that consistency of presentation across sections is important, as we move through
- different subsystems
- different collections of functionality
So, for example, touch on the same classes of points in each section (e.g. new features, configuration detail, example)
For an excellent example, I look to the ISPN docs.
> Update The Wildfly High Availability Guide
> -------------------------------------------
>
> Key: WFLY-1725
> URL: https://issues.jboss.org/browse/WFLY-1725
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha3
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 8.0.0.Beta1
>
>
> The main source of clustering-related documentation for a Wildfly user is the High Availability Guide in the Wildfly 8 documentation on docs.jboss.org.
> Update this document into a quality document which will aid the user's understanding of new features and configuration in Wildfly 8 clustering.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1725) Update The Wildfly High Availability Guide
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1725?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-1725 at 7/19/13 3:51 PM:
--------------------------------------------------------------------
We have a number of sources of documentation for AS clustering over recent versions:
- old but comprehensive clustering guides from legacy versions (AS 4, AS 5), reference from the JBoss Clustering community project documentation
- comprehensive clustering guides in EAP product documentation written by the docs team
- rather less comprehensive High Availability Guides for AS7 and Wildfly community documentation
The aim here is to update the project High Availability Guide documentation in a way that makes sense and is useful to users of clustering features.
What should be the relationship between the comprehensive EAP product documentation and the Wildfly High Availability Guide project documentation? Some thoughts:
* the project documentation should concentrate on changes and new features of clustering, while at the same time providing a reasonable overview
* it should act as a source of upstream input for the subsequent EAP documentation, when required
* it should not aim to be comprehensive in the same way that the EAP documentation is; rather, be directed to experienced users who just need the minimal instruction to get a feature working
However, despite the fact that it may be less comprehensive, it must be well organized and well presented, with adequate framing of how covered topics related to each other.
was (Author: rachmato):
We have a number of sources of documentation for AS clustering over recent versions:
- old but comprehensive clustering guides from legacy versions (AS 4, AS 5), reference from the JBoss Clustering community project documentation
- comprehensive clustering guides in EAP product documentation written by the docs team
- rather less comprehensive High Availability Guides for AS7 and Wildfly community documentation
The aim here is to update the project documentation in a way that makes sense and is useful to users of clustering features.
What should be the relationship between the comprehensive EAP product documentation and the Wildfly High Availability Guide project documentation? Some thoughts:
- the project documentation should concentrate on changes and new features of clustering, while at the same time providing a reasonable overview
- it should act as a source of upstream input for the subsequent EAP documentation, when required
- it should not aim to be comprehensive in the same way that the EAP documentation is; rather, be directed to experienced users who just need the minimal instruction to get a feature working
However, despite the fact that it may be less comprehensive, it must be well organized and well presented, with adequate framing of how covered topics related to each other.
> Update The Wildfly High Availability Guide
> -------------------------------------------
>
> Key: WFLY-1725
> URL: https://issues.jboss.org/browse/WFLY-1725
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha3
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 8.0.0.Beta1
>
>
> The main source of clustering-related documentation for a Wildfly user is the High Availability Guide in the Wildfly 8 documentation on docs.jboss.org.
> Update this document into a quality document which will aid the user's understanding of new features and configuration in Wildfly 8 clustering.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months