[JBoss JIRA] (WFLY-3028) It should be possible to initialize Filters on deployment rather than on first use
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3028?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3028:
------------------------------
Component/s: (was: EE)
> It should be possible to initialize Filters on deployment rather than on first use
> ----------------------------------------------------------------------------------
>
> Key: WFLY-3028
> URL: https://issues.jboss.org/browse/WFLY-3028
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: Ubuntu 12.04.1 LTS 32b | JVM 1.7 |
> Reporter: Nicolas Barrera
> Assignee: David Lloyd
> Labels: servletfilter
>
> As I see it Wildfly “Lazy-Inits” Filters, and that's causing some problems in my project, here is my case:
> It happens that I have a filter chain declared in web.xml
> FilterA -> FilterB
> so that when a new request arrives FilterA is executed first and FilterB second.
> My problem is that FilterA needs FilterB to be initialized before it's filter method is executed.
> When using other web containers (tomcat/jetty) I had no problem with this scenario because filters' init method is called on server startup.
> With wildfly the init method of a Filter is not called until it receives the first request so the methods would be called in this order:
> FilterA.init, FilterA.filter, FilterB.init, FilterB.filter
> and FilterA.filter will fail because FilterB.init wasn't called earlier.
> Maybe it's ok to have certain mode where Filters are initialized lazily but I 'd like to have some configuration option that let me initialize filters on startup.
> I 've asked on stackoverflow about this problem and after a while only one person showed up and recommended me to raise a JIRA, so I assumed this was not possible in Wildfly 8.
--
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, 4 months
[JBoss JIRA] (WFLY-3028) It should be possible to initialize Filters on deployment rather than on first use
by Nicolas Barrera (JIRA)
Nicolas Barrera created WFLY-3028:
-------------------------------------
Summary: It should be possible to initialize Filters on deployment rather than on first use
Key: WFLY-3028
URL: https://issues.jboss.org/browse/WFLY-3028
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: EE, Web (Undertow)
Affects Versions: 8.0.0.CR1
Environment: Ubuntu 12.04.1 LTS 32b | JVM 1.7 |
Reporter: Nicolas Barrera
Assignee: David Lloyd
As I see it Wildfly “Lazy-Inits” Filters, and that's causing some problems in my project, here is my case:
It happens that I have a filter chain declared in web.xml
FilterA -> FilterB
So that when a new request arrives FilterA is executed first and FilterB second.
My problem is that FilterA needs FilterB to be initialized before it's filter method is executed.
When using other web containers (tomcat/jetty) I had no problem with this scenario because filters' init method is called on server startup.
With wildfly the init method of a Filter is not called until it receives the first request so the methods would be called in this order:
FilterA.init, FilterA.filter, FilterB.init, FilterB.filter
and FilterA.filter will fail because FilterB.init wasn't called earlier.
Maybe it's ok to have certain mode where Filters are initialized lazily but I 'd like to have some configuration option that let me initialize filters on startup.
I 've asked on stackoverflow about this problem and after a while only one person showed up and recommended me to raise a JIRA, so I assumed this was not possible in Wildfly 8.
--
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, 4 months
[JBoss JIRA] (WFLY-3028) It should be possible to initialize Filters on deployment rather than on first use
by Nicolas Barrera (JIRA)
[ https://issues.jboss.org/browse/WFLY-3028?page=com.atlassian.jira.plugin.... ]
Nicolas Barrera updated WFLY-3028:
----------------------------------
Description:
As I see it Wildfly “Lazy-Inits” Filters, and that's causing some problems in my project, here is my case:
It happens that I have a filter chain declared in web.xml
FilterA -> FilterB
so that when a new request arrives FilterA is executed first and FilterB second.
My problem is that FilterA needs FilterB to be initialized before it's filter method is executed.
When using other web containers (tomcat/jetty) I had no problem with this scenario because filters' init method is called on server startup.
With wildfly the init method of a Filter is not called until it receives the first request so the methods would be called in this order:
FilterA.init, FilterA.filter, FilterB.init, FilterB.filter
and FilterA.filter will fail because FilterB.init wasn't called earlier.
Maybe it's ok to have certain mode where Filters are initialized lazily but I 'd like to have some configuration option that let me initialize filters on startup.
I 've asked on stackoverflow about this problem and after a while only one person showed up and recommended me to raise a JIRA, so I assumed this was not possible in Wildfly 8.
was:
As I see it Wildfly “Lazy-Inits” Filters, and that's causing some problems in my project, here is my case:
It happens that I have a filter chain declared in web.xml
FilterA -> FilterB
So that when a new request arrives FilterA is executed first and FilterB second.
My problem is that FilterA needs FilterB to be initialized before it's filter method is executed.
When using other web containers (tomcat/jetty) I had no problem with this scenario because filters' init method is called on server startup.
With wildfly the init method of a Filter is not called until it receives the first request so the methods would be called in this order:
FilterA.init, FilterA.filter, FilterB.init, FilterB.filter
and FilterA.filter will fail because FilterB.init wasn't called earlier.
Maybe it's ok to have certain mode where Filters are initialized lazily but I 'd like to have some configuration option that let me initialize filters on startup.
I 've asked on stackoverflow about this problem and after a while only one person showed up and recommended me to raise a JIRA, so I assumed this was not possible in Wildfly 8.
> It should be possible to initialize Filters on deployment rather than on first use
> ----------------------------------------------------------------------------------
>
> Key: WFLY-3028
> URL: https://issues.jboss.org/browse/WFLY-3028
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: EE, Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: Ubuntu 12.04.1 LTS 32b | JVM 1.7 |
> Reporter: Nicolas Barrera
> Assignee: David Lloyd
> Labels: servletfilter
>
> As I see it Wildfly “Lazy-Inits” Filters, and that's causing some problems in my project, here is my case:
> It happens that I have a filter chain declared in web.xml
> FilterA -> FilterB
> so that when a new request arrives FilterA is executed first and FilterB second.
> My problem is that FilterA needs FilterB to be initialized before it's filter method is executed.
> When using other web containers (tomcat/jetty) I had no problem with this scenario because filters' init method is called on server startup.
> With wildfly the init method of a Filter is not called until it receives the first request so the methods would be called in this order:
> FilterA.init, FilterA.filter, FilterB.init, FilterB.filter
> and FilterA.filter will fail because FilterB.init wasn't called earlier.
> Maybe it's ok to have certain mode where Filters are initialized lazily but I 'd like to have some configuration option that let me initialize filters on startup.
> I 've asked on stackoverflow about this problem and after a while only one person showed up and recommended me to raise a JIRA, so I assumed this was not possible in Wildfly 8.
--
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, 4 months
[JBoss JIRA] (JGRP-1660) LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1660?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1660:
---------------------------
Fix Version/s: (was: 3.4)
(was: 3.3.5)
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
> Key: JGRP-1660
> URL: https://issues.jboss.org/browse/JGRP-1660
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.4, 3.3.3
> Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
> Reporter: Architect SoftWeb.ISD
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: bla2.java, lock.xml, lock.xml, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)
> Object.wait(long) line: not available [native method]
> Locking$ClientLock(Object).wait() line: 485
> Locking$ClientLock.acquireTryLock(long, boolean) line: 1010
> Locking$ClientLock.tryLock() line: 896
> CENTRAL_LOCK(Locking).down(Event) line: 152
> ProtocolStack.down(Event) line: 1025
> JChannel.down(Event) line: 718
> LockService$LockImpl.tryLock() line: 102
> LockServiceStabilityTestCase$ClientImitation.run() line: 167
> Thread.run() line: 662
--
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, 4 months
[JBoss JIRA] (JGRP-1660) LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1660?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1660.
----------------------------
Resolution: Cannot Reproduce Bug
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
> Key: JGRP-1660
> URL: https://issues.jboss.org/browse/JGRP-1660
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.4, 3.3.3
> Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
> Reporter: Architect SoftWeb.ISD
> Assignee: Bela Ban
> Fix For: 3.5, 3.4, 3.3.5
>
> Attachments: bla2.java, lock.xml, lock.xml, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)
> Object.wait(long) line: not available [native method]
> Locking$ClientLock(Object).wait() line: 485
> Locking$ClientLock.acquireTryLock(long, boolean) line: 1010
> Locking$ClientLock.tryLock() line: 896
> CENTRAL_LOCK(Locking).down(Event) line: 152
> ProtocolStack.down(Event) line: 1025
> JChannel.down(Event) line: 718
> LockService$LockImpl.tryLock() line: 102
> LockServiceStabilityTestCase$ClientImitation.run() line: 167
> Thread.run() line: 662
--
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, 4 months
[JBoss JIRA] (JGRP-1660) LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1660?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1660:
--------------------------------
OK, so I ran bla2 again, with 2 processes (a couple of times), and this always ran fine.
Please provide a modified bla2, which reproduces the errors and reopen this case if you can reproduce the problem.
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
> Key: JGRP-1660
> URL: https://issues.jboss.org/browse/JGRP-1660
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.4, 3.3.3
> Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
> Reporter: Architect SoftWeb.ISD
> Assignee: Bela Ban
> Fix For: 3.3.5, 3.4, 3.5
>
> Attachments: bla2.java, lock.xml, lock.xml, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)
> Object.wait(long) line: not available [native method]
> Locking$ClientLock(Object).wait() line: 485
> Locking$ClientLock.acquireTryLock(long, boolean) line: 1010
> Locking$ClientLock.tryLock() line: 896
> CENTRAL_LOCK(Locking).down(Event) line: 152
> ProtocolStack.down(Event) line: 1025
> JChannel.down(Event) line: 718
> LockService$LockImpl.tryLock() line: 102
> LockServiceStabilityTestCase$ClientImitation.run() line: 167
> Thread.run() line: 662
--
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, 4 months
[JBoss JIRA] (JGRP-1772) Optimize marshalling and in-memory cost of strings
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1772?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1772:
--------------------------------
The code I changed would *not* benefit from {{String.intern()}} as these strings are never literals.
> Optimize marshalling and in-memory cost of strings
> --------------------------------------------------
>
> Key: JGRP-1772
> URL: https://issues.jboss.org/browse/JGRP-1772
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, we use DataOutput.writeUTF() for all sorts of strings. This is implemented inefficiently and potentially uses more than 1 byte per char.
> Add another method writeString() which converts double byte chars to single byte chars so that only ASCII is supported. This can be used by a lot of internal code which never uses chars above 128.
> For external code, such as {{JChannel.connect(String cluster_name)}}, we need to see whether this is ok. Since cluster names are mainly used to differentiate clusters, perhaps it is ok to mangle the names to chars below 128, although this would change cluster names which use multi-byte chars.
--
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, 4 months
[JBoss JIRA] (JGRP-1770) Table: null row when removing last element
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1770?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1770:
---------------------------
Description:
In Table.removeMany() when nulling the last column of a row, we don't null the entire row. The effect is that we have rows (arrays) with all columns being empty remain in memory, which wastes memory.
Note that Table.purge() actually does null entire rows, this is called by
* NAKACK2: here, method stable() triggered by STABLE calls {{Table.purge(seqno)}}, so we're nulling entire rows. This is not a problem.
* UNICAST3 *sender entries*: here, reception of an ACK(seqno) also calls {{Table.purge(seqno)}}, so this is not an issue, either
The only issue is UNICAST3 *receiver entries*: here, {{Table.purge()}} is never called; elements are only nulled, but not entire rows.
SOLUTION:
When {{Table.removeMany()}} nulls an element, if that element is the last element of a row (index = {{elements_per_row -1}}, then null the entire row.
EFFECT:
There's less memory held in memory by UNICAST3 receiver entries
was:
In Table.removeMany() when nulling the last column of a row, we don't null the entire row. The effect is that we have rows (arrays) with all columns being empty remain in memory, which wastes memory.
Note that Table.purge() actually does null entire rows, this is called by
* NAKACK2: here, method stable() triggered by STABLE calls {{Table.purge(seqno)}}, so we're nulling entire rows. This is not a problem.
* UNICAST3 *sender entries*: here, reception of an ACK(seqno) also calls {{Table.purge(seqno)}}, so this is not an issue, either
The only issue is UNICAST3 *receiver entries*: here, {{Table.purge()}} is never called; elements are only nulled, but not entire rows.
SOLUTION:
When {{Table.removeMany()}} nulls an element, if that element is tha last element of a row (index = {{elements_per_row -1}}, then null the entire row.
EFFECT:
There's less memory held in memory by UNICAST3 receiver entries
> Table: null row when removing last element
> ------------------------------------------
>
> Key: JGRP-1770
> URL: https://issues.jboss.org/browse/JGRP-1770
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> In Table.removeMany() when nulling the last column of a row, we don't null the entire row. The effect is that we have rows (arrays) with all columns being empty remain in memory, which wastes memory.
> Note that Table.purge() actually does null entire rows, this is called by
> * NAKACK2: here, method stable() triggered by STABLE calls {{Table.purge(seqno)}}, so we're nulling entire rows. This is not a problem.
> * UNICAST3 *sender entries*: here, reception of an ACK(seqno) also calls {{Table.purge(seqno)}}, so this is not an issue, either
> The only issue is UNICAST3 *receiver entries*: here, {{Table.purge()}} is never called; elements are only nulled, but not entire rows.
> SOLUTION:
> When {{Table.removeMany()}} nulls an element, if that element is the last element of a row (index = {{elements_per_row -1}}, then null the entire row.
> EFFECT:
> There's less memory held in memory by UNICAST3 receiver entries
--
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, 4 months
[JBoss JIRA] (JGRP-1716) Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1716:
---------------------------
Description:
Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
* getall: the get request is sent to single node (randomly picked owner)
* getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
h5. Suspects:
Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.
was:
Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
* getall: the get request is sent to single node (randomly picked owner)
* getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
.h5 Suspects:
Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
> Key: JGRP-1716
> URL: https://issues.jboss.org/browse/JGRP-1716
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3, 3.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Labels: dm
> Fix For: 3.4.1, 3.5
>
> Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> h5. Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.
--
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, 4 months